How should security teams close MFA coverage gaps across legacy and remote access systems?

Why This Matters for Security Teams

MFA coverage gaps are not just a user login problem. They are a control-plane problem that affects legacy applications, remote access, and privileged workflows that often sit outside modern identity tooling. When a VPN, RDP gateway, SSH bastion, or old web app still accepts passwords, attackers only need one weak path to bypass stronger controls elsewhere. Current guidance from the OWASP Non-Human Identity Top 10 and NIST SP 800-53 Rev 5 Security and Privacy Controls both point toward coverage, enforcement, and exception handling as operational necessities, not optional hardening.

The practical issue is that MFA can appear “deployed” while still leaving high-risk gaps untouched. Remote access tools may enforce MFA for employees but not contractors, service desks, break-glass accounts, legacy admin consoles, or fallback authentication routes. That creates a false sense of coverage and makes audit evidence misleading. NHI Management Group research on Ultimate Guide to NHIs shows how often identity controls fail at the edges, where visibility and lifecycle management are weakest. In practice, many security teams discover these gaps only after a legacy pathway is abused, rather than through intentional coverage testing.

How It Works in Practice

Effective coverage starts with an authentication path inventory, not a policy statement. Every route that can establish a session or grant privileged access should be mapped, including SSO entry points, VPNs, VDI, bastions, SSH, RDP, admin portals, emergency accounts, and vendor access. Each path should then be classified by factor strength, user population, business owner, and exception status. That classification becomes the basis for remediation priority and audit evidence.

For legacy systems, the usual pattern is to place MFA enforcement at the nearest control point the application can tolerate. That may mean a modern access proxy, an identity-aware gateway, a PAM layer, or a federated front end that absorbs the authentication burden before traffic reaches the old system. For remote access, the preferred pattern is phishing-resistant MFA on the initial trust boundary, with step-up verification for privileged actions. The goal is not only “MFA present” but “no password-only route remains for sensitive access.”

Security teams should also separate human access from non-human or shared workflows. Service accounts, automation tools, and jump-host orchestration often fail MFA because they are not human interactive sessions. For those cases, stronger controls usually come from workload identity, certificates, short-lived secrets, and tightly scoped privilege, rather than forcing MFA where it does not operationally fit. NHI Management Group’s Ultimate Guide to NHIs — Key Challenges and Risks is useful context because many “MFA gaps” are actually broader identity design failures. These controls tend to break down in mainframe, third-party remote support, and air-gapped admin environments because the system cannot natively support modern factor enforcement.

• Inventory every path, including fallbacks and break-glass routes.
• Classify by phishing resistance, owner, and exception expiry.
• Enforce MFA at the control point closest to authentication.
• Use PAM or access proxies where legacy systems cannot be changed.
• Track compensating controls for systems that cannot support MFA directly.

Common Variations and Edge Cases

Tighter MFA enforcement often increases operational friction, so organisations must balance user experience against attack resistance. That tradeoff is most visible in remote support, shared admin consoles, and outage recovery workflows, where teams are tempted to keep password-based bypasses “just in case.” Best practice is evolving, but current guidance suggests those exceptions should be rare, time-bound, approved, and continuously reviewed rather than left as permanent back doors.

One common edge case is contractor or third-party access. MFA may be enabled at the federated login screen, yet a downstream vendor portal, SSH key exchange, or legacy portal still allows direct password access. Another edge case is step-up authentication that exists in policy but not in practice because the application never calls the policy engine for privileged actions. A third is emergency access: break-glass credentials often bypass MFA by design, but they must be monitored, stored separately, and tested under strict conditions.

Teams also need to watch for false positives in coverage reporting. A system that “supports MFA” may still have service desk reset paths, alternate enrollment flows, or deprecated protocols that leave passwords active. NHI Management Group’s 52 NHI Breaches Analysis and SonicWall VPN Mass Breach via Stolen Credentials both illustrate how attackers exploit identity gaps that look minor on paper but are decisive in practice.

Related resources from NHI Mgmt Group

• How should security teams govern privileged access across cloud and legacy systems?
• Why do legacy PHP systems create security debt for IAM teams?
• How should security teams reduce exposure in remote access infrastructure?
• How should security teams run access reviews for non-human identities?