What do organisations get wrong when they say they have MFA everywhere?

Why This Matters for Security Teams

“MFA everywhere” is only meaningful if the factors are resistant to phishing, token replay, and social engineering. Security teams often report broad coverage while still relying on SMS, push prompts that can be fatigue-approved, or recovery paths that bypass the stronger factor entirely. NIST guidance in the NIST Cybersecurity Framework 2.0 pushes organisations to measure control effectiveness, not just deployment counts.

This matters because identity attacks usually target the weakest recovery or enrollment path, not the primary login flow. NHI Mgmt Group research shows that 79% of organisations have experienced secrets leaks, and 77% of those incidents caused tangible damage, which is a reminder that identity assurance failures compound quickly across humans and machines alike. The same pattern appears in incidents such as the Microsoft Midnight Blizzard breach, where identity and access weaknesses became operationally significant. In practice, many security teams discover that “MFA everywhere” meant “MFA somewhere,” after a real phishing campaign or account takeover has already exposed the gap.

How It Works in Practice

The practical mistake is treating MFA as a checkbox instead of a risk control. A mature programme distinguishes between nominal MFA and phishing-resistant authentication, then validates whether the factor can be bypassed through fallback workflows. Stronger approaches prefer hardware-bound or cryptographically bound methods, while weaker approaches depend on user judgment or mobile carrier trust. Current guidance suggests separating enrollment, primary authentication, step-up authentication, and recovery because each has different assurance requirements.

Teams should test the full identity journey, not just the login page. That includes:

• Whether a push approval can be abused through fatigue or prompt bombing.
• Whether SMS is still permitted for high-risk users or privileged access.
• Whether help desk recovery can reset a factor without strong identity proofing.
• Whether service accounts and API keys are being counted as “covered” when they are not human MFA at all.

For machine identities, the right question is usually not “Do they have MFA?” but “Are secrets short-lived, scoped, and rotated?” NHI Mgmt Group’s Ultimate Guide to NHI notes that 97% of NHIs carry excessive privileges, which means access assurance must be paired with least privilege, rotation, and offboarding discipline. Identity control quality improves when mapped against NIST Cybersecurity Framework 2.0 outcomes rather than marketing terms. These controls tend to break down in environments with legacy directories, outsourced help desks, and shared admin accounts because fallback access becomes the easiest path around the strongest factor.

Common Variations and Edge Cases

Tighter MFA controls often increase support burden, so organisations must balance user friction against real assurance. Not every workflow needs the same factor strength, and best practice is evolving on where passwordless, push, and hardware-bound methods should be mandatory versus optional. That tradeoff is especially visible in privileged access, remote access, and customer-facing recovery flows.

One common edge case is a technically strong MFA method paired with weak exception handling. For example, an account can be configured for phishing-resistant login but still be reset through email-based recovery or a permissive service desk script. Another gap appears when reporting counts every enrolled account as “protected,” even though dormant accounts, break-glass accounts, and shared credentials remain outside the control. NHI Mgmt Group’s research also shows that only 5.7% of organisations have full visibility into their service accounts, which means many teams cannot even tell whether machine identities are included in their MFA claims. The better metric is not coverage alone, but coverage plus resistance to bypass, recovery abuse, and privilege escalation.

Related resources from NHI Mgmt Group

• What do organisations get wrong about MFA recovery?
• What do teams get wrong about FIDO2 and MFA?
• What do organisations get wrong when they secure AI only at the model layer?
• What do organisations get wrong when they let AI assistants handle privacy lookups?