TL;DR: Basic MFA methods are being bypassed through Adversary-in-the-Middle proxy attacks, MFA fatigue, and social engineering, while phishing-resistant MFA uses cryptography and domain binding to stop credential interception, according to Versasec. The governance issue is no longer whether MFA exists, but whether it can survive real phishing conditions and lifecycle scale.
At a glance
What this is: This is an analysis of why basic MFA no longer holds up against modern phishing, and why phishing-resistant methods change the authentication model by removing shared secrets and binding login to the legitimate domain.
Why it matters: IAM teams need to treat phishing resistance as an authentication design choice and a lifecycle problem, not just a stronger login prompt, because deployment, revocation, reset and auditability determine whether the control works at enterprise scale.
By the numbers:
- The U.S. federal government has required phishing-resistant MFA across its agencies since OMB Memorandum M-22-09.
Context
Phishing-resistant MFA is authentication that prevents a user from successfully completing login on a deceptive site because the authenticator verifies the real origin of the request. The article's central claim is that basic MFA, especially shared-secret based methods, no longer withstands modern phishing conditions.
For IAM, PAM and identity governance teams, the issue is not simply whether MFA is enabled. The operational question is whether the authentication method survives AiTM interception, push fatigue and offboarding at scale without creating a new administrative bottleneck.
Key questions
Q: What breaks when risk-based authentication still relies on OTPs and push approvals?
A: The control breaks when it assumes factor completion equals identity verification. OTPs, push prompts, and security questions can be phished, intercepted, or coerced, so the attacker only needs to defeat the factor event, not prove legitimate identity. In high-risk flows, that leaves the organisation with stronger friction but not stronger assurance.
Q: Why do phishing-resistant authenticators lower the risk of adversary-in-the-middle attacks?
A: Phishing-resistant authenticators lower AiTM risk because they cryptographically bind the response to the registered origin. A lookalike domain can capture a password or OTP, but it cannot make a hardware-bound authenticator sign a challenge for a different site. That origin binding blocks credential relay, which is the core mechanism AiTM kits depend on to steal valid sessions.
Q: What signals show that MFA is not actually phishing-resistant?
A: Look for SMS, OTP, push approvals, and broad exception use on high-value accounts. If users can approve login from a fraudulent prompt, if help desk resets re-enable weak factors, or if administrators still rely on shared-secret methods, the programme is not resistant enough to withstand modern phishing.
Q: How should organisations govern phishing-resistant authentication at scale?
A: Treat phishing-resistant authentication as a lifecycle programme, not a one-time factor choice. Organisations need control over issuance, renewal, recovery, and revocation, plus clear ownership across IAM, IGA, and device teams. If fallback paths remain weak, strong credentials will still be bypassed through reset workflows and exception handling.
Technical breakdown
Why shared-secret MFA fails against AiTM phishing
Traditional MFA still depends on a transferable secret, such as an OTP delivered by text or generated by an app. In an Adversary-in-the-Middle attack, the attacker positions a proxy between the user and the real service, captures the OTP or prompt response, and relays it in real time. That makes the second factor reusable long enough for session creation. The weakness is not the login screen alone. It is the fact that the factor can be intercepted and replayed because it is not cryptographically bound to the genuine origin of the request.
Practical implication: Treat OTP-based MFA as vulnerable to real-time phishing unless the method is cryptographically origin-bound.
How FIDO2 and PKI stop credential interception
Phishing-resistant MFA changes the trust model by eliminating shared secrets and using public key cryptography. With FIDO2/WebAuthn, the authenticator signs a challenge only for the verified domain, so a look-alike site cannot produce a valid response. With certificate-based authentication, the credential lives in hardware and the user never types a reusable secret into the page. In both cases, the phishing page can still collect user input, but it cannot manufacture a valid authentication event. The control fails closed against domain spoofing rather than relying on user vigilance.
Practical implication: Use domain-bound authenticators where the threat model includes look-alike portals and proxy phishing.
Why lifecycle management becomes part of the authentication control
Hardware-backed MFA is only as strong as its issuance, reset, replacement and revocation process. Large deployments introduce new failure points: secure token delivery, remote PIN reset, lost key replacement and immediate certificate revocation on offboarding. If those processes are fragmented, the organization may have strong cryptography but weak operational control over who still holds a valid credential. In practice, the authentication stack and the credential lifecycle are now one governance surface. A control that cannot be revoked quickly or audited centrally is not complete at enterprise scale.
Practical implication: Govern phishing-resistant MFA as a lifecycle control, not a one-time enrollment project.
Threat narrative
Attacker objective: The attacker wants a valid authenticated session that bypasses basic MFA and grants access as the user.
- Entry begins when a user is steered to a look-alike login page or pushed into a deceptive approval flow.
- Credential access succeeds when the attacker captures an OTP or prompt-based approval and relays it to the real service in real time.
- Escalation follows when the attacker uses the replayed authentication to obtain a valid session on the target account.
- Impact is account takeover, with the attacker able to access protected applications and data as the legitimate user.
Breaches seen in the wild
- Twilio 0ktapus breach 2022: SMS phishing of employees exposed 209 Twilio customers and 1,900 Signal users, part of the 0ktapus campaign against 130+ firms.
- Microsoft Midnight Blizzard breach: Midnight Blizzard (APT29) exploited legacy test account without MFA to breach Microsoft.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Shared-secret MFA is the broken assumption: Basic MFA was designed for a world where the second factor stayed with the user long enough to prove presence. AiTM proxies and prompt bombing break that assumption because the factor is now relayable and phishable at the moment of use. The implication is that login assurance can no longer be measured by factor count alone.
Phishing resistance shifts security from user discipline to cryptographic proof: Once the authenticator binds the response to the genuine domain, the security outcome no longer depends on whether the user spots a clone site. That is a structural change in identity assurance, not just a stronger prompt. IAM teams should read this as a move from behavioural trust to verifiable origin trust.
Credential lifecycle is now part of MFA governance: The article correctly links strong authentication to issuance, reset, replacement and offboarding. That makes MFA governance overlap with identity lifecycle management, because a hardware token or certificate is only trustworthy if its ownership, state and revocation path stay current. The practical conclusion is that authentication and lifecycle controls must be designed together.
Ephemeral login trust debt: Organisations accumulate risk when they treat every successful login as a durable proof of identity even though the proof may have come from a phishable, relayable factor. That debt becomes visible when the control works in demos but fails in real phishing conditions. Practitioners should evaluate authentication by its resistance to interception, not by the convenience of the enrollment flow.
Regulatory pressure is now aligned with the threat model: The article's references to U.S. federal requirements and CISA guidance show that policy is catching up with what attackers already exploit. That matters because identity programmes often adopt controls only after a compliance trigger, yet the real driver here is attacker capability. Teams should expect phishing-resistant MFA to move from optional hardening to baseline expectation.
From our research library:
- Across one million observed logins, 1 in 4 were password-based rather than SSO, 2 in 5 were not protected by MFA and 1 in 5 used a weak, breached or reused password.
What this signals
Phishing-resistant MFA is no longer just an authentication choice: it is the point where login security, device-bound credentials and lifecycle governance intersect. If the credential can be reset, replaced or revoked slowly, the control is weaker than its cryptography suggests.
Basic MFA creates an assurance gap the moment an attacker can relay a factor: the programme must therefore move its control point from factor possession to domain-bound proof of origin. That shift matters for both cloud applications and legacy systems that still depend on shared secrets.
For practitioners
- Replace phishable second factors Prioritise FIDO2/WebAuthn or certificate-based authentication for high-risk applications, especially where AiTM and push fatigue are realistic threats.
- Centralise credential issuance and revocation Tie token issuance, PIN reset, replacement and offboarding to a single governance process so valid credentials cannot outlive user status changes.
- Test real phishing conditions Validate whether login controls still hold when users are routed through a look-alike domain, a proxy or a fake approval prompt.
- Audit offboarding for hardware credentials Verify that smart cards, security keys and certificates are revoked immediately when a user leaves or a device is lost.
- Measure helpdesk burden before rollout Estimate the operational load of secure resets and replacements before expanding phishing-resistant MFA across the enterprise.
Key takeaways
- Basic MFA still fails when attackers can intercept or relay the second factor, so the control boundary matters more than the number of factors deployed.
- Phishing-resistant MFA changes the trust model by binding authentication to the legitimate domain and removing reusable secrets from the login flow.
- Enterprise rollout succeeds only when issuance, reset, replacement and revocation are governed as part of the same identity lifecycle.
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-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The article centres on authentication methods that can be phished or relayed. |
| NHI-07 — Long-Lived Secrets | OTP and shared-secret methods remain usable long enough to be intercepted and replayed. | |
| NHI-01 — Improper Offboarding | The article stresses immediate revocation and offboarding for certificates and tokens. | |
| Recommendation — Prioritise phishing-resistant authentication where login methods remain relayable or cloneable. Replace reusable login secrets with domain-bound, hardware-backed credentials. Tie token and certificate revocation to offboarding so credentials cannot outlive user status. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Authenticator issuance, rotation and revocation are central to the article's governance point. |
| IA-2 — Identification and Authentication (Organizational Users) | The post addresses how organizational user authentication should be strengthened against phishing. | |
| Recommendation — Use IA-5 to manage authenticator lifecycle, revocation and replacement across the enterprise. Apply strong organizational user authentication requirements where basic MFA is still in use. | ||
| CIS Controls v8 | CIS-5 — Account Management | Account and credential governance are necessary to make phishing-resistant MFA operationally sustainable. |
| Recommendation — Align account management with credential issuance and revocation workflows for MFA tokens. | ||
Key terms
- Phishing-Resistant MFA: Phishing-resistant MFA uses authentication factors that cannot be easily replayed, intercepted, or socially engineered. In regulated environments, this usually means device-bound or cryptographic methods rather than push prompts or SMS codes, because the control must hold up under realistic attack conditions.
- Domain binding: A property of an authenticator that ties the login response to the intended website or service origin. In practice, it prevents a look-alike domain from generating a valid authentication response, which is why it is central to phishing resistance.
- Credential Management: Credential management is the lifecycle discipline for creating, storing, updating, monitoring, and retiring secrets used for authentication. In identity programmes, it covers both policy and process, including how credentials are protected at rest, moved between systems, and removed when no longer needed.
- Adversary-in-the-middle Attack: An adversary-in-the-middle attack intercepts and relays authentication in real time between the user and the legitimate service. It is especially dangerous for OTPs because the attacker can capture the code while it is still valid and immediately use it to complete login.
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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on July 10, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org