TL;DR: Legacy MFA is increasingly vulnerable to phishing and MFA fatigue, and Axiad argues organisations should adopt a pragmatic, grouped rollout that combines certificate-based authentication and FIDO for different user populations, while aligning with the White House OMB zero-trust memo and NIST AAL3 expectations. The practical issue is no longer whether phishing-resistant MFA is needed, but how to deploy it without creating new operational silos.
At a glance
What this is: This is a pragmatic rollout model for phishing-resistant MFA that prioritises user grouping, certificate-based authentication, and FIDO to replace weaker legacy MFA patterns.
Why it matters: It matters because IAM teams need to deploy phishing-resistant authentication without creating unmanaged silos, inconsistent assurance levels, or stalled adoption across different user populations.
Context
Phishing-resistant MFA is not a single control choice. It is a deployment and governance problem in which the assurance level, authenticator type, and user population have to be matched deliberately. The article argues that legacy MFA is no longer enough on its own because phishing and MFA fatigue have made password-based second factors predictable attack targets.
For identity programmes, the question is how to roll out stronger authentication without forcing every user into the same path at once. That makes this an IAM and identity lifecycle topic as much as an authentication topic: teams need to group users, map assurance to role and risk, and keep the rollout operationally manageable.
Key questions
Q: What should teams do when phishing-resistant MFA is in place but fraud still occurs?
A: Teams should inspect the identity journey around the MFA control, especially recovery, enrolment, help desk intervention, and account takeover escalation. Fraud after strong MFA often means the attacker bypassed the login control entirely. The right response is to treat the incident as a lifecycle failure, not just an MFA failure.
Q: Why do legacy MFA methods still leave organisations exposed to phishing?
A: Legacy MFA often depends on transferable factors such as SMS codes or push approvals, which attackers can intercept through SIM swapping or man-in-the-middle techniques. Those methods may add friction, but they do not eliminate the phishing pathway. Security teams should judge MFA by resistance to replay and interception, not by whether a second factor exists.
Q: What do teams get wrong about phishing-resistant MFA?
A: They often measure success by the presence of a strong factor instead of the absence of weaker bypasses. A deployment can include passkeys and still be vulnerable if users can fall back to OTP, push approval, or password reset. Governance should focus on reachable paths, not just enrolled methods.
Q: Why do organisations still need certificate-based authentication when FIDO exists?
A: Because FIDO is not designed to cover every identity context. Certificate-based authentication still matters for device identity, workload authentication, and environments that depend on PKI and certificate lifecycle control. In practice, CBA fills gaps where user-centric passwordless methods do not reach, especially across managed endpoints and integrated enterprise platforms.
Technical breakdown
Why legacy MFA fails under modern phishing pressure
Legacy MFA often assumes that adding a second step materially changes attacker effort, but phishing kits and fatigue attacks have reduced that margin. If the second factor can be relayed, coerced, or approved through nuisance prompts, the control no longer resists the actual attack path. Phishing-resistant MFA changes the trust model by binding authentication to a cryptographic possession factor or a hardware-backed authenticator rather than a reusable secret or easily replayed challenge. That is why the article treats certificate-based authentication and FIDO as complementary rather than interchangeable.
Practical implication: Use assurance level, not tradition, to decide which populations can still rely on legacy MFA and which need phishing-resistant methods.
Why grouped rollout beats universal rollout
The article’s core operational point is that not all users need the same authentication method on day one, and not all users can be migrated the same way. Grouping users by role and risk allows teams to map baseline, knowledge, compliance, IT and security, and executive populations to different assurance patterns. This avoids the trap of over-engineering low-risk access while under-serving high-risk access. It also creates a practical sequence for change management, because adoption, support, and device readiness differ sharply between groups.
Practical implication: Build rollout cohorts by role and risk so assurance can be increased without turning authentication modernisation into a single enterprise-wide disruption.
How certificate-based authentication and FIDO fit together
Certificate-based authentication is a PKI-backed method that uses digital certificates to prove identity, while FIDO uses phishing-resistant authenticator standards designed to stop credential replay and phishing capture. The article’s architecture point is that some use cases need one, some need the other, and some need both. MacOS desktop logon and Microsoft 365 access are given as examples of where method choice depends on platform support and user workflow. A pragmatic programme therefore treats these as interoperable options inside a common authentication platform, not as rival doctrines.
Practical implication: Design the authentication stack so CBA and FIDO can coexist under one governance model instead of forcing a single method across every access path.
Threat narrative
Attacker objective: The attacker wants durable account access that survives password changes and gives them a path into business systems through trust in weak MFA.
- Entry begins when users are phished or fatigued into approving a login that should not have succeeded.
- Credential access succeeds when the attacker captures or bypasses the legacy MFA step rather than defeating the primary password alone.
- Impact follows when the attacker can reuse that access against cloud services, applications, or administrative workflows that still trust the weaker authentication flow.
Breaches seen in the wild
- 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 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Phishing-resistant MFA is now a governance sequencing problem, not a technology preference. The article is right to move the discussion away from whether phishing-resistant authentication is needed and toward how to deploy it across real user populations. The hard part is not the control itself but the operational model that lets different groups move at different speeds without lowering assurance. Practitioners should treat rollout design as part of identity governance, not an afterthought.
Role-based authentication tiers are the most practical bridge between urgency and adoption. Large organisations do not fail because they lack a better authenticator; they fail because they try to apply one assurance pattern to every user and every device. Grouping users by baseline, knowledge, compliance, IT and security, and executive risk creates a defensible way to prioritise migration. The result is less friction for low-risk access and stronger controls where exposure is concentrated.
Phishing-resistant MFA breaks the assumption that second-factor strength can be added later without redesigning the access model. Legacy MFA programmes were designed for a world where the second step could be layered onto existing flows and still preserve security. That assumption fails when phishing kits, MFA fatigue, and platform constraints force different authenticators for different environments and workflows. The implication is that authentication architecture has to be planned as a portfolio, not a single control.
Certificate-based authentication and FIDO should be governed as complementary control paths. The article’s strongest operational insight is that desktop, cloud, and application access do not share the same authentication constraints. A control model that only standardises on one method will create exceptions, shadow processes, or user workarounds. Practitioners should therefore design for control equivalence across methods, not method uniformity.
Communication and lifecycle operations are the difference between a rollout and a stalled pilot. The article correctly treats user communication, status tracking, and credential renewal as part of the authentication programme itself. That is where many deployments lose momentum: they solve the cryptography but not the change-management and credential lifecycle work. The practitioner takeaway is that authentication modernisation succeeds when governance, user experience, and operations are managed together.
From our research library:
- Roughly 1 in 3 phishing payloads are delivered outside email, through channels such as social media, search ads and messaging apps.
What this signals
Phishing-resistant MFA only works when the rollout model is as deliberate as the cryptography. Teams should expect the hardest problems to sit in authentication governance, user segmentation, and exception handling rather than in the authenticator itself. A programme that cannot map cohorts, lifecycle steps, and support ownership will stall before it improves assurance.
Authentication modernisation is a control portfolio problem. Organisations need to treat certificate-based authentication, FIDO, and existing IAM flows as coordinated paths under one governance model. That is the only way to prevent one-size-fits-all deployment from creating operational silos or weak fallback routes.
For practitioners
- Define user risk cohorts Group end users by role and exposure before selecting authenticators so baseline, knowledge, compliance, IT and security, and executive populations can follow different assurance paths.
- Map assurance to use case Assign certificate-based authentication, FIDO, or a combined path to each cohort based on the systems they access and the devices they use most often.
- Run authentication as a lifecycle programme Track rollout status, renewals, and expiry handling so credentials move cleanly from old methods to new ones without creating unmanaged overlap.
- Build a user communication cadence Tell users why the change is happening, what benefit they get, and when they should expect each phase so support demand does not spike unpredictably.
Key takeaways
- Phishing-resistant MFA is now a practical rollout challenge, not a theoretical control choice, because legacy MFA is increasingly exposed to phishing and fatigue attacks.
- The strongest deployment pattern is to group users by risk and map different authenticator strengths to different populations rather than forcing a single method everywhere.
- A workable programme has to join authentication design, communication, renewal handling, and rollout tracking if it is going to improve assurance without creating new operational friction.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63, NIST CSF 2.0, NIST SP 800-53 Rev 5, OWASP ASVS and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | SP 800-63B — Authentication | The article centres on phishing-resistant authentication and assurance levels. |
| Recommendation — Map user cohorts to the appropriate authentication assurance requirements in SP 800-63B. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The rollout depends on matching authentication strength to user access risk. |
| Recommendation — Align authentication controls to access risk and user entitlement criticality under PR.AA-05. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | The post focuses on authenticating enterprise users with stronger methods. |
| Recommendation — Apply IA-2 to strengthen organisational user authentication with phishing-resistant methods. | ||
| OWASP ASVS | V6 — Authentication | The article discusses authentication assurance and stronger login methods. |
| Recommendation — Use V6 to verify that authentication flows resist phishing and MFA bypass. | ||
| CIS Controls v8 | CIS-5 — Account Management | The rollout requires lifecycle handling for user groups and credentials. |
| Recommendation — Use CIS-5 to manage account enrolment, transition, and credential retirement during rollout. | ||
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.
- Certificate-based authentication: A method of proving identity using a cryptographic certificate and the associated private key rather than a reusable password. In identity programmes, it raises the bar for theft and replay because the secret is bound to lifecycle, issuance, and revocation control.
- FIDO2: FIDO2 is a passwordless authentication standard that uses public-key cryptography instead of shared secrets. A service stores the public key while the authenticator keeps the private key, allowing users to prove possession without sending reusable credentials over the network.
- Authentication Assurance: The degree of confidence that an identity has been verified to the intended standard before access is granted. For MFA, assurance depends on the whole enforcement chain, including session handling, retry policy, and telemetry, not merely the presence of a code prompt.
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 building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 8, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org