What do teams get wrong about phishing-resistant MFA?

Why This Matters for Security Teams

Teams usually get phishing-resistant MFA wrong by treating it as a product attribute instead of a control outcome. A passkey can be phishing-resistant and still leave the account reachable through weaker paths such as SMS recovery, OTP fallback, help desk reset, or push approval. That is why guidance from the NIST Cybersecurity Framework 2.0 matters here: identity controls only work when the full authentication pathway is governed, not just the primary factor. The same issue appears in NHI programs, where Microsoft Midnight Blizzard breach shows how one compromised path can defeat a broader security posture. The practical mistake is assuming enrollment equals enforcement. Security teams may celebrate passkey adoption while leaving account recovery, admin override, or legacy protocols untouched. Attackers do not need to break the strongest method if they can route around it. In practice, many security teams encounter phishing-resistant MFA failures only after an account takeover has already succeeded through a weaker fallback path, rather than through intentional validation of every reachable path.

How It Works in Practice

Phishing-resistant MFA should be evaluated as a decision graph: every branch that can authenticate, recover, or override a session must be inspected. Strong methods such as passkeys, FIDO2 security keys, or certificate-based authentication reduce phishing exposure, but only if passwords, OTP, and push-based approval are removed or tightly constrained. Current guidance suggests that the weakest reachable method defines the effective assurance level, not the strongest enrolled one. Operationally, teams should inventory:

• Primary sign-in methods, including legacy password flows.
• Recovery channels, such as email reset, SMS codes, or call-centre verification.
• Administrative bypasses, break-glass accounts, and tenant-level overrides.
• Session reauthentication rules and step-up triggers for sensitive actions.

This is also where identity governance overlaps with broader Zero Trust practice. The NIST view of continuous verification aligns with the need to remove standing trust, while NHI research highlights how much risk hides in overlooked pathways. For example, the concentration of identity risk in non-human systems is evident in the Microsoft Midnight Blizzard breach analysis, where control gaps mattered more than the nominal presence of authentication. The operational lesson is to test the actual reachable path with the same rigour as the primary sign-in, using policy reviews, red-team simulations, and help-desk process checks alongside technical settings. These controls tend to break down when recovery is outsourced to loosely verified support workflows because the account can be re-entered through social engineering rather than factor compromise.

Common Variations and Edge Cases

Tighter MFA controls often increase support load, user friction, and exception handling, so organisations have to balance reduced attack surface against operational continuity. That tradeoff is real, but current guidance suggests the answer is not to preserve weak methods indefinitely. The safer pattern is to use temporary migration windows, tightly governed break-glass access, and step-up approval for rare edge cases rather than broad fallback methods. One common edge case is shared or high-impact administrator access. Even with phishing-resistant MFA, admins may still be exposed if help-desk staff can reset credentials too easily or if legacy protocols remain enabled for specific apps. Another edge case is device loss or authenticators bound to a single platform. If recovery is too restrictive, users are pushed back toward insecure workarounds, which defeats the purpose of the control. The same lesson appears in NHI governance, where weak secrets handling and excessive privileges can undo otherwise sound authentication design. NHI Mgmt Group research on the Microsoft Midnight Blizzard breach reinforces that resilient identity security depends on removing fallback abuse paths, not just deploying a stronger front door. For teams trying to align policy with broader control frameworks, NIST Cybersecurity Framework 2.0 remains a useful reference point for governance and continuous improvement, especially where exceptions and recovery processes are involved.

Related resources from NHI Mgmt Group

• What do security teams get wrong about authentication platform selection?
• What do security teams get wrong about session tokens and MFA?
• What do teams get wrong about MFA alerting?
• What do security teams get wrong about MFA in identity attacks?