By NHI Mgmt Group Editorial TeamBased on Axiad: “Phishing-Resistant Authentication for Everyone” (September 16, 2025)

TL;DR: Legacy MFA is increasingly vulnerable to phishing and MFA fatigue, and Axiad argues that government mandates and modern use cases now justify a pragmatic phishing-resistant approach built around certificate-based authentication and FIDO support. The real issue is not whether stronger MFA exists, but whether identity programmes can support mixed authenticator paths without creating new operational silos.


At a glance

What this is: This is a guidance piece arguing that phishing-resistant MFA is no longer optional for modern identity programmes, with certificate-based authentication and FIDO presented as the practical path forward.

Why it matters: It matters because IAM teams have to support stronger authentication without fragmenting user experience, governance, or rollout across different user groups and use cases.


Context

Phishing-resistant MFA is an authentication model that reduces the value of stolen credentials by binding sign-in to stronger factors such as certificates or FIDO keys rather than reusable secrets. In this article, the central identity problem is not simply stronger login security, but how identity programmes operationalise that control across mixed user populations without creating parallel authentication estates.

The governance gap is practical: many organisations still need one authentication posture for browsers, another for desktop logins, and another for regulated or high-risk users. That makes phishing-resistant MFA an IAM programme design issue, not just a technical control choice, because the rollout has to fit workforce roles, device constraints, and ongoing operations.


Key questions

Q: How should financial institutions roll out phishing-resistant MFA without breaking legacy systems?

A: Start by segmenting access paths instead of treating the workforce as one login population. Protect VPN, admin, and high-risk financial workflows first, then add brokered or adapter-based controls for legacy applications that cannot natively support passwordless sign-in. The goal is consistent assurance across every path, not a uniform UI.

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 breaks when organisations try to use ordinary authenticators for phishing-resistant access at scale?

A: Ordinary authenticators often fail in high-risk environments because they may not cover the full range of privileged, shared, or constrained use cases. That creates gaps in phishing resistance, recovery, and policy enforcement. Teams then end up with inconsistent access methods, weak fallback paths, and a passwordless program that works for some users but not for the enterprise.

Q: How should security teams choose between FIDO and certificate-based authentication?

A: Security teams should choose by identity type, environment maturity, and lifecycle control. FIDO fits phishing-resistant human login, while certificate-based authentication fits environments that already rely on PKI for users, devices, or workloads. The right answer is often both, with each method mapped to the use case it governs best.


Technical breakdown

Why phishing-resistant MFA changes the authentication model

Phishing-resistant MFA changes the threat economics by removing the shared secret pattern that phishing and MFA fatigue attacks exploit. Rather than asking users to approve a login or enter a code that can be replayed, the authentication event is anchored to a trusted device, certificate, or hardware-backed credential. In practice, that shifts emphasis from password recovery and push approval workflows to authenticator issuance, device binding, and trust in the local proofing path. The important point is not that all MFA is equal, but that some authenticators remain replayable while others are materially harder to phish.

Practical implication: treat phishing resistance as a distinct control class, not a cosmetic upgrade to existing MFA.

Why certificate-based authentication and FIDO often need to coexist

The article’s core operational insight is that no single phishing-resistant method covers every enterprise use case. Certificate-based authentication is better suited where desktop or machine login constraints make FIDO impractical, while FIDO is often more usable for browser-centric access such as Microsoft 365. That is a governance problem because authenticator choice becomes a policy decision tied to role, endpoint, and application context. Mixed authenticator support is therefore not a temporary compromise, but a realistic architecture for large environments with different risk tiers and device realities.

Practical implication: design policy that maps authenticators to use cases instead of forcing a universal method.

How phased rollout and lifecycle operations keep phishing resistance governable

A phishing-resistant programme fails if it is treated as a one-time deployment. The article emphasises user grouping, rollout tracking, credential renewal, and communication cadences because authenticator change creates operational churn. That means governance has to include enrolment, provisioning, renewal, and expiry as first-class identity processes. The deeper lesson is that authentication assurance is only sustainable when lifecycle operations are visible and controlled, otherwise stronger factors become another island of unmanaged access.

Practical implication: build enrolment, renewal, and expiry workflows into the authentication programme from day one.


Threat narrative

Attacker objective: The attacker wants to obtain authenticated access that can be reused against business systems despite the presence of MFA.

  1. Entry occurs through phishing or MFA fatigue when an attacker coerces a user into approving or completing a sign-in flow.
  2. Credential harvesting succeeds when the attack relies on reusable factors such as passwords, one-time codes, or push approvals that can be replayed or bypassed.
  3. Escalation follows when the attacker uses the captured authentication to reach cloud applications, desktop sessions, or privileged business systems.
  4. Impact is account compromise with access to sensitive systems and data, especially where the organisation has not moved to phishing-resistant authentication.

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 an identity governance baseline, not a niche hardening choice. Once phishing and MFA fatigue become routine attack paths, programmes that still treat push approval or SMS-style second factors as sufficient are governing to yesterday’s threat model. The control question is no longer whether MFA exists, but whether the factor can be replayed, coerced, or inherited through weak recovery paths. Practitioners should treat authenticator strength as a policy boundary, not a user preference.

Mixed authenticator support is the real enterprise problem. The article is right to surface certificate-based authentication and FIDO together because most organisations cannot collapse all use cases into one factor path. MacOS, cloud apps, regulated functions, and browser-based workflows do not present the same constraints, so governance has to decide where each authenticator is acceptable and how exceptions are managed. The practical conclusion is that authentication architecture must be segmented by use case without becoming fragmented by accident.

Phishing resistance fails when lifecycle operations are weak. A strong authenticator does not help if enrolment, renewal, and expiry are poorly governed or left to ad hoc operations. The moment credentials are issued without clear ownership and revocation discipline, the programme creates its own residual risk. Identity teams should treat issuance, rotation, and deprovisioning of authenticators as part of the access model, not as support work outside governance.

Phishing-resistant authentication exposes the gap between policy intent and endpoint reality. The article’s use-case examples show that many organisations still assume a single authenticator can cover every endpoint and application equally. That assumption breaks when desktop login, cloud access, and regulated workflows each require different trust signals. The implication is that identity governance has to be endpoint-aware, application-aware, and role-aware at the same time.

Phishing-resistant MFA should be measured by rollout coverage, not by policy adoption. A written mandate does not tell you whether high-risk populations have actually moved off replayable factors. The useful governance signal is which user groups, applications, and endpoints are genuinely protected by phishing-resistant authenticators and which still depend on legacy methods. Practitioners should judge the programme by coverage of the riskiest access paths, not by the existence of a policy document.

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

Mixed authenticator governance will become a standard IAM design problem. Most organisations will not converge on one phishing-resistant method everywhere, so the programme challenge is to manage coexistence without creating uncontrolled exceptions. That means policy, enrolment, and retirement rules matter as much as the authenticator itself.

Phishing resistance exposes hidden lifecycle debt in identity programmes. If credentials can be issued, renewed, and retired cleanly, the control scales. If those processes are manual or inconsistent, the authentication layer becomes another place where governance gaps persist.

Role-based rollout is the only practical way to move off replayable factors. High-risk users, sensitive systems, and constrained endpoints should define the sequencing, not a generic enterprise target date.


For practitioners

  • Map user groups to authenticator classes Separate baseline, knowledge, compliance, IT and security, and executive users so each group gets an authentication method that matches its risk and device context.
  • Support both certificate-based authentication and FIDO Design the IAM stack so certificate-based authentication covers desktop or endpoint-constrained use cases while FIDO remains available where browser-based access fits better.
  • Treat authenticator lifecycle as governance Track enrolment, renewal, expiry, and replacement as controlled identity processes, not as informal support tasks.
  • Prioritise high-risk access paths first Roll out phishing-resistant authentication to the groups and systems that carry the most exposure, such as finance, IT, security, and executive access.
  • Communicate rollout changes to end users Set a communication cadence that explains why authentication is changing, what users should expect, and when legacy methods will be retired.

Key takeaways

  • Legacy MFA remains vulnerable wherever attackers can coerce or replay the factor, which is why phishing-resistant authentication is becoming the practical baseline.
  • The article’s central operational point is that certificate-based authentication and FIDO both have a place, because no single method fits every endpoint and workload.
  • IAM teams should govern phishing-resistant MFA as a lifecycle programme, with rollout, renewal, expiry, and user communication built into the operating model.

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, NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Non-Human Identity Top 10NHI-04 — Insecure AuthenticationThe article centres on stronger authentication to resist phishing and replay.
NHI-10 — Human Use of NHIThe post discusses people authenticating with certificates and FIDO credentials.
Recommendation — Use phishing-resistant factors to replace replayable authentication paths for high-risk access. Govern human-facing authenticators so end users cannot bypass approved phishing-resistant paths.
NIST SP 800-53 Rev 5IA-5 — Authenticator ManagementAuthenticator issuance, renewal, and expiry are central to the rollout model described.
IA-2 — Identification and Authentication (Organizational Users)The article is about workforce authentication for enterprise users.
Recommendation — Apply authenticator management controls to issuance, rotation, renewal, and retirement workflows. Require stronger authentication for organisational users accessing sensitive systems and applications.
NIST CSF 2.0PR.AA-05 — Access Permissions, Entitlements and AuthorizationsThe programme ties authentication strength to role-based access decisions.
Recommendation — Align access authorisation with authenticator strength and user risk classification.
NIST Zero Trust (SP 800-207)Identity verification and authentication — Identity verification and authenticationPhishing-resistant MFA supports continuous trust decisions in Zero Trust architectures.
Recommendation — Anchor zero trust access decisions on phishing-resistant authentication signals.

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.
  • FIDO Authentication: A passwordless authentication method that uses asymmetric cryptography instead of shared secrets. The authenticator keeps the private key and proves possession through a challenge-response flow, which reduces phishing and replay risk because nothing reusable is transmitted across services.
  • Authenticator Lifecycle Management: Authenticator lifecycle management is the governance of a credential from issuance to renewal, replacement, and retirement. For human identity programmes, it ensures that keys, smart cards, and certificates stay tied to the right user and are removed when the user, role, or device is no longer trusted.

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.
NHIMG Editorial Note
Published by the NHIMG editorial team on June 12, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org