MFA blind spots expose why coverage is not the same as control

At a glance

What this is: This is an analysis of why organisations that say they have MFA still leave exploitable authentication gaps across legacy, remote, and privileged access paths.

Why it matters: It matters because IAM teams cannot treat MFA as a binary checkbox when unprotected systems, phishable factors, and exception-driven access create the conditions for account takeover and lateral movement.

👉 Read Secret Double Octopus's analysis of MFA blind spots and enforcement gaps

Context

MFA coverage gaps are an identity governance problem as much as an authentication problem. If enforcement is inconsistent across SaaS, legacy applications, remote access, and privileged workflows, the control does not describe the real attack surface.

The article argues that many organisations mistake partial deployment for meaningful protection. That distinction matters for IAM, PAM, and audit teams because attackers do not need to defeat MFA everywhere, only at the weakest access path where passwords, exceptions, or non-phishing-resistant factors still exist.

Key questions

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

A: Start by mapping every authentication path, including legacy apps, VPN, RDP, SSH, endpoints, and privileged workflows. Then classify each path by factor strength, exception status, and owner. The goal is not a generic MFA mandate but a verified coverage model that shows where phishing-resistant authentication exists, where it does not, and which paths still rely on passwords.

Q: Why do organisations still get breached even when MFA is deployed?

A: Because deployment is not the same as enforcement. Breaches still happen when MFA is missing from legacy systems, weakened by phishable factors, or bypassed through exceptions and shared accounts. Attackers do not need to defeat every login path, only the one where policy is weakest and the identity boundary is least controlled.

Q: What do security teams get wrong about MFA exceptions?

A: They often treat exceptions as temporary implementation details instead of governance risks. In practice, exceptions become permanent alternate rules that are harder to audit and easier to exploit. A mature programme tracks each exception, assigns ownership, requires expiry, and measures whether the compensating control actually reduces exposure.

Q: Who is accountable when MFA is not enforced consistently?

A: Accountability usually sits with identity governance, application owners, and platform teams together, because inconsistent enforcement is rarely caused by one control owner. Security leaders should require explicit ownership for every uncovered system and every exception path. That is especially important where privileged access or regulated systems are involved.

Technical breakdown

Why MFA coverage fails in mixed estates

Modern IAM stacks often enforce MFA well in cloud applications while leaving on-prem systems, VPN entry points, and older business applications outside the same control plane. That creates a split identity model: one set of access paths is hardened, while another still depends on passwords or weak second factors. The failure is not the technology category itself, but inconsistent enforcement across environments that were never normalised into one policy and evidence model.

Practical implication: map every authentication path, not just your SSO estate, and treat uncovered legacy and remote access systems as first-order identity risk.

Why phishable MFA still leaves a viable attack path

SMS codes, OTP apps, push approvals, and password-plus-token flows all introduce a second factor, but not all second factors resist real-time interception or user fatigue attacks. If the first factor remains a reusable password and the second factor can be proxied or manipulated, the attacker’s job is reduced, not removed. From an identity standpoint, the problem is that the organisation has added friction without always adding strong proof of possession.

Practical implication: prioritise phishing-resistant methods for high-risk access paths instead of assuming any MFA variant closes the gap.

How exceptions and break-glass access become permanent exposure

Exceptions are often introduced to keep legacy applications, admin workflows, and remote support paths working, then quietly persist long after the original need has passed. Over time, that turns special handling into an alternate policy regime where enforcement is weaker, monitoring is thinner, and audit evidence is incomplete. In practice, the exception list becomes the real control boundary, which is exactly where attackers look for bypass conditions.

Practical implication: inventory every MFA exception, assign an owner, and require a documented expiry or review cycle for each one.

Threat narrative

Attacker objective: The objective is to gain legitimate-looking access through the weakest MFA boundary and convert that access into privileged control or operational disruption.

1. Entry begins when attackers target paths where passwords still front the authentication flow, especially legacy applications, remote access services, and privileged workflows with weak MFA enforcement.
2. Escalation follows when phishable factors, shared accounts, or exception-based access let the attacker operate as a legitimate user and move toward higher-value systems.
3. Impact occurs when the attacker reaches privileged access or unprotected core systems, allowing account takeover, ransomware deployment, data theft, or broader lateral movement.

Breaches seen in the wild

• MITRE ATT&CK Enterprise Matrix — MITRE ATT&CK Enterprise — adversary tactics and techniques, threat detection, attack chain mapping, credential access, lateral movement, privilege escalation.
• BeyondTrust API key breach — compromised BeyondTrust API key led to unauthorized SaaS access.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

MFA coverage is only meaningful when every access path is in scope. The article shows the core problem: organisations often assess MFA as a capability, not as a complete enforcement model. Legacy applications, remote access, shared admin workflows, and endpoint logins can all sit outside the same assurance boundary. For IAM and PAM leaders, the conclusion is simple: a partial MFA programme creates a false control surface, and attackers will always target the uncovered segment.

Phishing-resistant authentication is now the dividing line between policy and protection. Password plus OTP, push approval, and SMS-based flows may satisfy a policy checkbox, but they do not deliver the same resistance to real-time adversary techniques. That is why authentication strength must be judged by bypass resistance, not by whether a second factor exists. Practitioners should read this as a signal that assurance levels, not MFA labels, are what matter in governance.

Privilege makes MFA inconsistency a blast-radius problem, not just a login problem. When shared admin accounts, break-glass workflows, or exception paths bypass stronger enforcement, the gap is no longer limited to authentication hygiene. It becomes a privilege governance issue because the most powerful identities are often the least consistently protected. Teams should treat privileged exception handling as a control failure mode in its own right.

Identity assurance must be provable, not asserted. The article’s strongest point is that saying "we have MFA" is not evidence. Auditability depends on knowing where enforcement exists, which methods are used, and where exceptions remain. That aligns directly with NIST CSF, NIST SP 800-53, and OWASP NHI thinking: if you cannot demonstrate coverage and method strength, you do not truly control the identity boundary.

Coverage gaps create identity debt that outlives the original workaround. Temporary exceptions for legacy systems often harden into permanent policy drift. Over time, that debt compounds across authentication, access review, and privileged control programmes. The practical implication is that organisations should stop treating exceptions as edge cases and start treating them as measurable governance liabilities.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities.
• That confidence gap is why teams should also revisit the Ultimate Guide to NHIs , Why NHI Security Matters Now when they are rationalising authentication coverage and exception risk.

What this signals

Coverage drift is the hidden pattern here: once a control is uneven across systems, the exception set becomes the real security perimeter. That perimeter is usually invisible until audit, incident response, or a privileged access review forces the gap into view, which is why organisations should pair coverage maps with governance evidence.

The next programme-level question is not whether MFA exists, but whether assurance is provable under change, exception, and legacy conditions. Teams that can only describe their policy in the abstract will struggle to defend it when regulators or attackers ask where enforcement actually stops.

For practitioners

• Map authentication coverage across every access path Inventory SaaS, legacy applications, VPN, RDP, SSH, endpoint login, and privileged workflows. Identify where MFA is absent, weak, or enforced differently, then reconcile those paths into one evidence model so audit and operations see the same control reality.
• Replace phishable factors on high-risk access paths Prioritise phishing-resistant authentication for admin, remote, and externally exposed systems. Keep passwords out of the primary trust decision where possible, and do not treat OTP or push approval as equivalent to device-bound proof.
• Tighten the exception lifecycle for legacy access Require an owner, expiry date, and compensating monitoring for every MFA exception. Review break-glass and shared-account workflows on a fixed cadence, and remove any exception that no longer has a documented business necessity.
• Prove enforcement before you claim coverage Build reporting that shows where MFA is enforced, which factor types are used, and where users or systems fall outside policy. Use those reports to support audit, risk acceptance, and remediation prioritisation.

Key takeaways

• MFA becomes a weak control when it is present in policy but absent at the real choke points attackers use.
• Legacy access, weak second factors, and permanent exceptions turn authentication into a patchwork rather than a control boundary.
• Security leaders need proof of coverage, not just a claim of deployment, if they want meaningful identity assurance.

Key terms

• Phishing-resistant authentication: Authentication that cannot be easily relayed, proxied, or coerced by an attacker during a live session. In practice, it relies on cryptographic proof bound to a device or platform, which materially improves assurance for privileged and remote access compared with codes or push approvals.
• Mfa exception: A documented deviation from the standard authentication policy that allows a system, user group, or access path to operate outside normal MFA enforcement. Exceptions are sometimes necessary, but if they are not owned, time-bound, and reviewed, they become permanent security gaps rather than controlled risk decisions.
• Coverage gap: A gap between where a security control is expected to apply and where it actually does apply. In identity programmes, coverage gaps often appear in legacy applications, remote access, shared accounts, and break-glass workflows, creating a false sense of assurance during audits and incidents.

What's in the full article

Secret Double Octopus's full blog post covers the operational detail this post intentionally leaves for the source:

• Detailed breakdown of legacy, VPN, RDP, SSH, and endpoint paths that commonly sit outside MFA enforcement
• Practical guidance on identifying phishing-resistant versus phishable authentication methods in mixed environments
• Examples of MFA exceptions, break-glass workflows, and policy drift patterns that create audit risk
• Coverage-first remediation priorities for teams deciding where to fix authentication gaps first

👉 The full Secret Double Octopus post expands on legacy coverage gaps, phishable methods, and exception-driven risk.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.