Phishing-resistant MFA adoption still hinges on identity design

At a glance

What this is: This is a practitioner guide arguing that phishing-resistant MFA is the practical path to reducing phishing exposure, with CBA and FIDO passkeys framed as the two true unphishable options.

Why it matters: It matters because authentication decisions affect human IAM today and shape how organisations build consistent controls across employee access, machine access, and future identity programmes.

By the numbers:

• 49% of respondents said phishing is the most likely attack to happen.
• 64% of respondents said fear of change is the top reason for holding onto passwords and non-phishing-resistant MFA.
• Only 5.7% of organisations have full visibility into their service accounts.

👉 Read Axiad's guide to adopting phishing-resistant MFA

Context

Phishing-resistant MFA is authentication that removes the reusable secret or human approval step that attackers typically exploit. The core governance problem is not just user friction, but the persistence of weaker authentication choices inside broader IAM programmes, especially where organisations defer change because existing sign-in patterns feel familiar.

For IAM teams, this is a human identity control today with downstream implications for lifecycle governance across the enterprise. The article’s central point is that phishing resistance is less a product choice than an operating model shift, because it requires category-based rollout, policy mapping, and employee readiness rather than a single technology swap.

Key questions

Q: How should security teams roll out phishing-resistant MFA without disrupting users?

A: Start with high-risk user groups, define assurance levels by role, and support the rollout with clear onboarding and recovery processes. The objective is not a broad flag day. It is to reduce the strongest attack paths first while maintaining enough interoperability for existing IAM systems to keep operating.

Q: Why do passwords and conventional MFA still create phishing risk?

A: Passwords can be stolen, and many MFA methods still rely on users approving prompts or entering codes that can be captured in real time. Phishing-resistant MFA removes that human handoff by using certificate-based authentication or FIDO passkeys, which deny attackers a reusable secret to harvest.

Q: What do organisations get wrong when they treat phishing resistance as a technology project?

A: They focus on the authentication method and ignore the rollout model, support process, and fallback paths. That creates pockets of weak assurance, inconsistent user experience, and recovery flows that attackers can target when the primary control is unavailable.

Q: How can IAM teams tell whether phishing-resistant MFA is actually improving security?

A: Look for reduced reliance on reusable secrets, fewer successful credential phishing incidents, and consistent enforcement across all major sign-in paths. If the strongest control is limited to a small group or a single application, the programme is still partial, not mature.

Technical breakdown

Certificate-based authentication and FIDO passkeys as true phishing resistance

The article distinguishes true phishing-resistant MFA from methods that still depend on a human entering a code, approving a prompt, or reusing a password. Certificate-based authentication uses PKI-backed certificates to prove possession without exposing a shared secret, while FIDO passkeys rely on asymmetric cryptography and device-bound credentials. In both cases, the authentication factor is not something a user can hand over in a phishing page. That is why these methods change the attacker’s available path rather than just making the path harder.

Practical implication: treat any method that still asks a user to reveal or approve a secret as phishing-resistant only in marketing terms, not in governance terms.

Why deployment planning matters more than the label

Adoption fails when teams assume phishing resistance is a switch rather than a staged identity change. The article points to category mapping, high-risk user prioritisation, and employee preparation because authentication controls intersect with directory design, help desk workflows, device readiness, and exception handling. In other words, the technical control may be sound, but the rollout architecture determines whether the programme is usable at scale. That is a governance problem as much as an IAM one.

Practical implication: define rollout cohorts, support processes, and fallback rules before expanding phishing-resistant MFA beyond a pilot group.

Overlaying phishing-resistant MFA on existing IAM stacks

The article argues that organisations do not need to replace every IAM system to get phishing resistance. Modern deployments can sit alongside existing access architecture, which matters in environments with multiple directories, legacy apps, and mixed user populations. That approach reduces migration pressure, but it also increases the need for policy consistency, because the control must work across all the places users authenticate. The real design question is whether the authentication layer can standardise assurance without forcing a rip-and-replace programme.

Practical implication: inventory where authentication happens, then align assurance levels across those systems instead of hardening only the newest portal.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Phishing-resistant MFA is a human identity control, but its governance value extends beyond login hardening. The article is correct to frame phishing resistance as a way to remove the weak link created by human approval and password reuse. For identity teams, that means the issue is not only authentication assurance but whether the IAM programme can sustain a consistent assurance model across departments, devices, and exception paths. Practitioners should treat phishing resistance as an authentication governance decision, not a one-off deployment.

The named concept here is authentication assurance fragmentation. Organisations that keep passwords, legacy MFA, and phishing-resistant MFA in parallel create different assurance levels for different entry points, which weakens enterprise policy consistency. That fragmentation is especially visible in large environments with multiple IAM systems and mixed user populations. The practical conclusion is that teams must stop treating each sign-in method as a separate control island and start governing assurance as a portfolio.

For human IAM, rollout design is the control plane. The article’s emphasis on categorising users, mapping authentication levels, and prioritising high-risk groups reflects a broader truth about identity programmes: the hardest failure is not cryptographic, it is operational. When access paths, support readiness, and user education are not aligned, even strong authentication becomes unevenly adopted. Practitioners should expect programme success or failure to be decided by implementation sequencing.

Phishing resistance also exposes the limits of reactive authentication strategy. If an organisation waits until phishing pressure is fully visible before changing controls, it is already managing by incident rather than by architecture. That is why the article’s direction fits broader Zero Trust thinking, where assurance must be continuous and not dependent on user memory or manual approval. Practitioners should use this moment to re-evaluate how much of their access model still relies on trust in human behaviour.

Any serious MFA programme has to account for lifecycle and exception handling. Users change roles, devices age out, and recovery processes become the weak point if the organisation treats strong authentication as a front-door-only problem. The article gestures toward rollout by category, and that should be read as a lifecycle signal: enrolment, reset, recovery, and fallback all need governance. Practitioners should extend phishing-resistant policy to the full identity lifecycle, not just the first login.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
• For a broader control baseline, 52 NHI Breaches Analysis shows how weak identity visibility turns small access gaps into recurring incidents.

What this signals

Authentication modernisation is now a cross-domain governance issue. Human MFA decisions shape the same assurance discipline that later has to extend to service accounts and, increasingly, autonomous actors. Once a programme learns how to govern enrolment, recovery, and fallback without relying on shared secrets, it has a better foundation for broader identity control. Teams that still separate human and non-human identity strategy are building future inconsistency into the programme.

The practical pressure point is not whether phishing-resistant MFA exists. It is whether the organisation can sustain uniform assurance when older IAM stacks, local exceptions, and user support shortcuts all compete with policy. That is where authentication assurance fragmentation becomes visible, and that is also where security leaders should expect most deployment failures.

Phishing-resistant MFA also changes the shape of risk reporting. Instead of reporting only user adoption, teams should track where weak fallback paths remain and whether recovery processes silently reintroduce the very secrets the programme was meant to remove. The best indicator of maturity is not enrolment count but how few places still depend on recoverable secrets.

For practitioners

• Prioritise high-risk user groups first Start with administrators, finance users, executives, and anyone who can approve money movement or sensitive access. These cohorts deliver the fastest risk reduction because phishing against them creates outsized blast radius, and they are usually the most defensible place to begin change management.
• Map assurance levels to user categories Define which employee groups need certificate-based authentication, which can use passkeys, and where exceptions are allowed. Keep the mapping explicit so policy does not drift across departments or business units.
• Plan for existing IAM interoperability Document where the new authentication layer will overlay current directories, SSO flows, and legacy applications. The goal is to avoid a rip-and-replace programme while still enforcing consistent authentication across all entry points.
• Prepare users and support teams before rollout Build onboarding guidance, help desk scripts, and recovery procedures before enforcing phishing-resistant MFA. If users do not understand enrolment and reset processes, adoption stalls and workarounds reintroduce weak authentication.
• Treat fallback and recovery as governance controls Review what happens when devices are lost, users change roles, or a certificate expires. If recovery relies on a weaker path than the primary one, attackers will look for that path first.

Key takeaways

• Phishing-resistant MFA reduces exposure by removing the human step that attackers most often exploit, but the control only works when it is governed as part of the wider IAM model.
• Axiad’s survey data shows both the size of the phishing problem and the organisational resistance to change, which makes rollout design a central security issue rather than an afterthought.
• The most effective programmes prioritise high-risk users, align authentication levels to role categories, and treat fallback and recovery as part of the control, not an exception to it.

Key terms

• Phishing-resistant mfa: Phishing-resistant MFA uses authentication methods that do not depend on a user revealing a reusable secret to a fake login page. In practice, that usually means certificate-based authentication or FIDO passkeys, both of which bind the credential to the user or device in a way phishing cannot easily intercept.
• Certificate-based authentication: Certificate-based authentication proves identity with a digital certificate and private key rather than a password or OTP code. It is a mature approach for human identity assurance, especially where organisations already run PKI and want to raise assurance without exposing reusable secrets to the user.
• Fido passkey: A FIDO passkey is a phishing-resistant authenticator that uses asymmetric cryptography and device-bound credential storage to verify a user. It reduces reliance on passwords and code entry, which makes it harder for attackers to intercept credentials through impersonation or real-time phishing techniques.
• Authentication assurance: Authentication assurance is the degree of confidence that the presented identity is genuine and the sign-in event is legitimate. For human identity programmes, it depends on the strength of the method, the quality of the recovery path, and whether the control remains consistent across all access points.

Deepen your knowledge

Phishing-resistant MFA adoption is covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your organisation is moving from passwords and legacy MFA to stronger assurance, this course helps frame the governance decisions that matter most.

This post draws on content published by Axiad: How to Adopt Phishing-Resistant MFA. Read the original.