Add multi-factor authentication in front of the app instead of inside it. Route all access through a gateway, jump host or authenticating reverse proxy that enforces MFA, then block every direct path to the app. The old app keeps its simple login, but only people who passed MFA can reach it.
Why it is worth the effort
OWASP's authentication guidance calls multi-factor authentication the strongest defense against most password attacks, including brute force, and recommends deploying it wherever possible. Legacy apps often have weak or shared passwords, no lockout and no support for modern identity protocols, so a front door that checks identity strongly is a large improvement for modest effort.
Three ways to put MFA in front
| Approach | How it works | Good for | Watch out for |
|---|---|---|---|
| Authenticating reverse proxy | Users sign in to the proxy with MFA, which forwards to the app | Web apps | App must trust only the proxy |
| Jump host or remote access gateway | Users connect to the host with MFA, then reach the app from it | Thick clients, admin consoles, SSH and RDP | Need to block direct routes |
| Network access broker | Per application access after identity checks | Many legacy apps in several places | Setup and ongoing management |
Steps
- List every way to reach the app. Web, thick client, API, admin console, file shares, vendor links, batch jobs.
- Pick the front door per path. A proxy for the web part, a jump host for the admin part.
- Enable MFA and named accounts at the front door. No shared users.
- Restrict the app to the front door. Firewall so the app accepts connections only from the proxy or jump host.
- Handle machine to machine access. Batch jobs and integrations cannot use MFA prompts. Give them dedicated accounts with narrow permissions, restricted source addresses and monitored use.
- Test the bypasses. Try the old URL, the old VPN profile and the old IP address directly.
- Log both layers. The front door's log shows who entered. The app's log shows what they did.
Service accounts and internal privileges
OWASP advises that accounts with internal privileges, such as access to backend, middleware or database systems, should not be able to log in through any user-facing front end. In a legacy app this often fails, because the same account is used by people and by scheduled jobs. Split them, so human logins use MFA at the front door and the job account is useless from a browser.
Gaps that defeat the design
- A second path, such as a direct VPN profile, left in place.
- The app server reachable from the whole internal network.
- Shared accounts at the front door, which break accountability.
- Emergency "break glass" accounts with no MFA and no monitoring. If you need one, vault it, alert on its use and rotate it after each use.
Record the compensating control
The control cannot be met inside the app, so the record should say: MFA enforced at this gateway, direct access blocked by these rules, tested on this date with this result. Review when the gateway, the firewall or the app changes.
Quick check
Does MFA at the gateway protect against a flaw in the app?
It limits who can reach the flaw, but it does not remove it. Anyone who passes MFA can still try to exploit it, so keep isolation and monitoring too.
What about users who must connect from a vendor network?
Give each person a named account with MFA, limit access to a time window and to the one app, and log the session.
Sources
- OWASP Authentication Cheat Sheet
- NIST SP 800-53 Rev 5 control catalog (OSCAL JSON, NIST oscal-content repository) (AC-17 Remote Access)
Last reviewed: 19 October 2026.
