Why does missing MFA still lead to large breaches when organisations have other controls?

Why This Matters for Security Teams

Missing MFA rarely causes a breach by itself. The larger failure is that a single stolen credential can still map to broad access, privileged workflows, or service accounts that were never designed for interactive challenge. That is why MFA reduces entry risk, but it does not contain blast radius once an identity is already inside. NHI Management Group’s research on the 52 NHI breaches Report shows how often identity compromise becomes an enterprise-wide incident when controls are fragmented.

Security teams also underestimate how quickly attackers move after initial access. In the Microsoft Midnight Blizzard breach, identity abuse cascaded into deeper access because the compromised account still had meaningful reach. That pattern matches broader reporting on identity-driven intrusion, including Anthropic’s report on AI-orchestrated cyber espionage, where automation amplified the speed and scale of misuse. In practice, many security teams encounter the real blast radius only after the attacker has already chained access, not during the missing-MFA event itself.

How It Works in Practice

The real question is not whether MFA was enabled, but what the identity could do after authentication failed to stop the attacker. If the account can reach admin consoles, data stores, CI/CD systems, or cloud control planes, the compromise becomes a permissions problem. That is why mature programs pair MFA with least privilege, segmentation, strong session controls, and continuous access review. NHI Management Group’s 52 NHI Breaches Analysis illustrates how compromised identities often succeed because standing access is wider than teams assume.

Operationally, the controls that matter most are the ones that shrink what a stolen identity can touch:

• Use MFA for interactive human access, but do not treat it as a substitute for authorization design.
• Map privileges by system and task, then remove broad group memberships that enable lateral movement.
• Separate user access from service and automation access so one compromise does not expose both.
• Use short-lived credentials, scoped tokens, and step-up checks for sensitive actions.
• Monitor for abnormal tool chaining, privilege escalation, and access from new locations or hosts.

Current guidance from NIST CSF and Zero Trust thinking is consistent here: authenticate the user, then continuously validate the request and its context. For NHI-heavy environments, the same logic applies to workload identities, API keys, and service principals. The core operational question is whether a credential grants a single function or an entire trust chain. These controls tend to break down when legacy shared accounts and over-permissioned service identities still span multiple environments, because one stolen secret can reach too many systems too quickly.

Common Variations and Edge Cases

Tighter access control often increases operational overhead, requiring organisations to balance blast-radius reduction against developer friction and service reliability. That tradeoff is real, especially in environments with legacy applications, shared administrative tooling, or emergency break-glass accounts. Best practice is evolving, but the direction is clear: MFA should be one layer in a larger identity containment model, not the final control.

Edge cases matter. A missing MFA prompt on a low-risk account may not be catastrophic if the account is tightly scoped, heavily monitored, and unable to reach sensitive systems. Conversely, an MFA-protected account can still enable a major breach if it is over-privileged, reused across systems, or connected to automation that can pivot across infrastructure. The same concern appears in NHI governance when a secret is embedded in code, a pipeline, or a workload image. The Ultimate Guide to NHIs — Why NHI Security Matters Now and the Schneider Electric credentials breach both reinforce the same lesson: identity exposure becomes a large incident when privilege and reach are left intact.

For that reason, current guidance suggests treating MFA as an entry control, while privilege boundaries, short-lived access, and continuous monitoring determine whether an intrusion stays small or becomes enterprise-wide.

Related resources from NHI Mgmt Group

• Why do strong MFA controls still leave organisations exposed to session hijacking?
• Why do cloud breaches get worse when MFA is missing on privileged accounts?
• Why do weak identity verification controls create such large healthcare breaches?
• Why do MFA controls still leave organisations exposed to ransomware?