MFA for Custom and Legacy Applications: Key Implementation Challenges

Adding multi-factor authentication (MFA) to a modern cloud app is usually a quick job. Adding it to a custom-built or legacy application is a very different story. These apps often can’t use modern login standards, so the second factor has to be added around them. This post walks through the main challenges teams run into - and how IamLogic solves each one.

Modern MFA relies on standards like SAML, OAuth2 and OpenID Connect (OIDC). Many older and custom apps were built before these existed, so there is simply no place to “connect” an MFA service. The traditional answer - re-writing the application - is expensive, slow and risky.

How IamLogic solves it

IamLogic adds MFA outside the application instead of inside it. For a legacy web app with a basic login page, the IamLogic browser plugin handles the sign-in: the user authenticates to IamLogic once with MFA, and the plugin then autofills the app’s username and password for them. No standard support is needed inside the app, and its login screen stays exactly as it is.

Even when logins are automated, the app’s password still lives somewhere - and browsers can leak or expose saved passwords. If that password is captured, the extra login step can be bypassed entirely.

How IamLogic solves it

IamLogic automatically rotates (changes) the password immediately after each use. So even if someone manages to grab the password from the browser, it has already expired and can’t be reused. Users don’t need to know or remember the password at all.

Challenge 3: You can’t expose the app directly to users

Some applications can’t take on any authentication logic of their own, and exposing them directly to users is a security risk. You need a way to force every user through an MFA check before they ever reach the app.

How IamLogic solves it

IamLogic places a reverse proxy in front of the application - a checkpoint that every request must pass through. Unauthenticated users are redirected to verify their identity with MFA first; only after that does the proxy forward the request to the app. The application sits in a protected zone and is never reached without a passing MFA check.

Challenge 4: Kerberos apps weren’t built for MFA

A large share of internal Windows and on-premises apps authenticate with Kerberos through Active Directory. Kerberos is fast and convenient, but it has no built-in concept of a second factor - and you can’t change how these apps work without major effort.

How IamLogic solves it

IamLogic adds push-based 2FA to Kerberos with no application changes. A lightweight interceptor agent on the domain controller watches ticket requests. When a user opens a protected app, the agent pauses the request and sends a push approval to the user’s device. Approve, and the ticket is issued and the app opens; deny, and the request is dropped.