A useful test is whether the factor can still be replayed, relayed or socially engineered into use when the user is under active deception. If the answer is yes, the control may be compliant in appearance but weak in practice for high-risk access.
How to tell whether MFA is phishing resistant in practice
Phishing resistance is not about whether MFA exists, but whether the factor still holds up when an attacker is actively trying to capture, relay, or socially engineer it. The practical question is whether the authenticator is bound to the genuine origin, the genuine session, and the genuine user action, or whether it can be replayed like a code, proxied through a fake login, or approved under pressure.
That means agencies should separate surface compliance from real resistance. SMS codes, push approvals, and legacy OTP flows can all satisfy a checkbox while still failing against adversary-in-the-middle relay, push fatigue, or help-desk-assisted takeover. Phishing-resistant methods change the attack economics because the credential is not easily transferable to a phishing site or reused outside the legitimate authentication ceremony.
A NIST SP 800-63 Digital Identity Guidelines anchor for this test is whether the authenticator meets higher assurance expectations for origin binding and phishing resistance, rather than relying on a one-time secret that can be observed and replayed. In practice, that is why passkeys, FIDO2 security keys, and other phishing-resistant authenticators are treated differently from OTPs and push-based approvals.
What failure modes reveal weak MFA
Weak MFA usually shows up in the path the attacker takes, not in the policy language. If a user can be sent to a lookalike portal, enter a factor, and immediately hand the attacker a usable session or approval, then the factor is not resisting phishing in a meaningful sense. If a help desk can be convinced to reset, enroll, or bypass the second factor under pressure, the control is also vulnerable even when the login flow itself looks modern.
The most common failure modes are replay, relay, token theft, and approval abuse. Replay is common with OTPs. Relay is common with adversary-in-the-middle phishing, where the attacker proxies the real login in real time. Approval abuse appears with push fatigue and social engineering. Session theft matters because MFA can be satisfied once, after which stolen cookies or tokens may carry the attacker forward without needing the factor again.
For a concrete sign of this weakness, see the pattern in MFA Guide, which contrasts different MFA methods and the bypass paths that remain available to attackers. The important practitioner takeaway is that agencies should test the whole authentication path, including enrollment, recovery, and session persistence, not just the primary sign-in screen.
How agencies should validate phishing resistance
Validation should be done as an adversarial exercise. Test whether the factor can be replayed from a phishing site, relayed through a proxy, approved under user deception, or defeated through account recovery and help-desk workflows. If the method only works when the user is calm, attentive, and on the correct site, then it is probably not the right control for high-risk access.
Use realistic test cases for the accounts that matter most: administrators, privileged users, remote access, finance, and any workflow that can change security settings or move data. Agencies should also verify that the control is enforced at the right places, because legacy paths often survive beside newer sign-in methods. One weak fallback can undo a strong primary factor.
For rollout and verification, the Passwordless and Passkeys Guide is useful because it ties phishing resistance to authenticator choice, recovery design, and rollout discipline. Agencies should treat passkey or security-key adoption as a control change that must be validated against recovery, device loss, and step-up exceptions, not as a branding exercise.
Risk and Threat Considerations
Phishing-resistant MFA is often strongest at the point of login and weakest at the surrounding processes. Attackers commonly target the recovery path, the help desk, legacy sign-in methods, or session tokens after a successful login. That means a control can look strong in policy while still leaving enough exposure for account takeover or downstream privilege abuse.
Failure mechanism: The attacker either relays the authentication ceremony in real time, tricks the user into approving it, or bypasses the factor through recovery, fallback, or session theft. Once one of those paths works, the original MFA label no longer predicts actual resistance.
Impact: The agency may keep access decisions tied to an MFA status that does not meaningfully reduce phishing risk for high-value accounts, leaving administrators and sensitive workflows exposed to takeover, fraud, and lateral movement.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-63, OWASP ASVS and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Defines authenticator assurance and phishing-resistant authentication for sign-in assurance. |
| Recommendation — Use phishing-resistant authenticators and verify assurance level for high-risk access. | ||
| OWASP ASVS | V10 — OAuth and OIDC | Covers authentication flows where phishing-resistant sign-in and token handling matter. |
| Recommendation — Validate OIDC and OAuth sign-in paths for relay-resistant authentication and secure recovery. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Applies to workforce sign-in controls that must resist phishing and takeover. |
| IA-5 — Authenticator Management | Addresses authenticator lifecycle, recovery, and protection against replay or theft. | |
| Recommendation — Enforce stronger authenticators for organizational users and restrict weaker fallbacks. Rotate, protect, and recover authenticators so stolen factors cannot be reused. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Phishing-resistance failures often show up when authentication can be replayed or relayed. |
| Recommendation — Eliminate authentication paths that can be proxied, replayed, or socially engineered. | ||
Practitioner Guidance
What to verify: Confirm whether the factor is origin-bound, whether it can be relayed through a phishing proxy, and whether the recovery path is equally resistant. If the answer differs for production users and privileged users, the control should be treated as uneven rather than universally effective.
Decision rule: If a method can be replayed, relayed, or approved under deception, do not treat it as sufficient for high-risk access even if it satisfies a policy requirement. Reserve weaker methods for lower-risk use cases and step-up contexts where the blast radius is limited.
Practitioner takeaway: The right question is not “do we have MFA,” but “can an attacker still make the factor work for them under phishing conditions?” If yes, the agency should treat the control as partially effective at best and redesign the authentication path around the accounts that matter most.