TL;DR: Axiad says phishing resistance is now a top priority because IDSA reported 84% of organisations had an identity-related breach in the past year, with phishing the most common breach type at 59%; legacy MFA and siloed IAM leave exploitable inconsistencies.
At a glance
What this is: This is an analysis of why phishing-resistant MFA and certificate-based authentication matter, and why legacy MFA plus fragmented IAM still leaves phishing gaps open.
Why it matters: IAM teams need this because inconsistent authentication across multiple identity systems creates real exposure, especially when phishing-resistant controls are deployed unevenly across the environment.
Context
Phishing-resistant MFA is a control problem, not just an awareness problem. Legacy MFA methods can still be intercepted, replayed, or socially engineered, and fragmented IAM makes those weaknesses uneven across the environment.
The identity governance issue is consistency. When organisations run multiple IAM systems, the authentication model is only as strong as the weakest path, which means phishing resistance has to be designed across systems, not bolted onto one of them.
Key questions
Q: What breaks when phishing-resistant MFA is not in place for regulated systems?
A: When phishing-resistant MFA is missing, a single phishing message can expose authenticated access paths that regulators expect to be stronger. In NYDFS environments, that weak link can convert an email compromise into a compliance failure because the control is meant to reduce credential replay and prove access assurance on sensitive systems.
Q: Why do phishing-resistant MFA methods reduce account takeover risk more than codes or SMS?
A: They bind the credential to the legitimate domain, so a fake login page cannot capture a reusable secret. That prevents the attacker from replaying the factor on the real service, which is the key failure in most phishing campaigns. Codes and SMS may still help with friction, but they do not remove the replay problem.
Q: How can security teams tell whether their phishing-resistant MFA model is actually compliant?
A: They need to test whether the authenticators, directories, and policy services remain available without external cloud access and still support the required user and admin flows. If the control only works in connected conditions, it is not resilient enough for SOCI-style isolation requirements. Compliance depends on operational continuity, not product labels.
Q: How should IAM teams govern certificates for both users and machines?
A: They should use separate policy logic for human users, devices, servers, and service identities, even if all of them authenticate with certificates. Each class has a different lifecycle, different trust boundary, and different revocation urgency. Without that separation, a single certificate policy can create mismatched access duration and hidden standing trust.
Technical breakdown
Why legacy MFA still fails under phishing pressure
Traditional MFA adds a second factor, but not every second factor resists real-time interception. SMS codes can be diverted through SIM swapping, while man-in-the-middle phishing can capture credentials and session tokens through lookalike login pages. In both cases, the attacker exploits an authentication flow that assumes the user is presenting secrets to the legitimate service directly. That assumption breaks once the adversary can proxy the session, relay the prompt, or hijack the code channel. Practical implication: treat MFA method choice as a security design decision, not a checkbox, and retire methods that can be proxied or replayed.
Practical implication: remove phishing-prone MFA methods from high-risk access paths and prioritise authenticators that bind the session to the legitimate device or certificate.
How siloed IAM creates uneven phishing resistance
A phased or partial rollout of phishing-resistant authentication creates control gaps across identity estates. If one IAM system uses strong authentication while another still accepts weaker flows, attackers will target the weakest enrollment, recovery, or fallback path. The article’s core point is that many organisations run several IAM systems, so authentication consistency becomes a governance problem as much as a technical one. Operationally, this means legacy and modern auth methods coexist, but the user and admin experience often differs by platform, app, or operating system. Practical implication: map every authentication path, including recovery and exception handling, before claiming phishing resistance.
Practical implication: inventory every IAM path and force the same phishing-resistant standard across primary and fallback authentication journeys.
Why certificate-based authentication changes the control model
Certificate-based authentication shifts the factor from a phishable secret to a stronger credential bound to a device or hardware token. That matters because the attacker no longer only needs a password or OTP, they need the private key material or the device that holds it. The article also points out that CBA can sit across multiple IAM systems and operating systems, which matters in mixed estates where control inconsistency is the real vulnerability. CBA therefore behaves less like a point product and more like a cross-system authentication layer. Practical implication: assess whether certificate-based authentication can replace weaker methods in both user login and privileged access flows.
Practical implication: use certificate-based authentication where you need a stronger, cross-platform authentication layer that is resistant to phishing and inconsistent IAM policy.
Threat narrative
Attacker objective: Obtain authenticated access to user accounts by defeating weak or inconsistently deployed MFA controls.
- Entry begins when the attacker uses phishing, SIM swapping, or a man-in-the-middle page to intercept a user’s login flow rather than attacking the backend directly.
- Credential access occurs when the attacker captures passwords, one-time codes, or session material from a phishable MFA method.
- Impact follows when the attacker uses the captured authentication material to access the target identity system or account.
- The underlying objective is account takeover through weaknesses in the authentication path rather than exploitation of the application itself.
Breaches seen in the wild
- Microsoft Midnight Blizzard breach: Midnight Blizzard (APT29) exploited legacy test account without MFA to breach Microsoft.
- 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.
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 resistance fails as a programme if it is only partially deployed. The article’s central warning is not that MFA is obsolete, but that inconsistent MFA creates false assurance. Legacy IAM estates often mix phishable factors, modern authenticators, and recovery exceptions, which means the weakest path defines the control outcome. Practitioners should treat authentication consistency as an identity governance requirement, not an implementation detail.
Certificate-based authentication is really a consistency control in disguise. Its value is not only stronger authentication, but the ability to apply a uniform phishing-resistant model across systems, operating systems, and user groups. That matters because fragmented IAM architectures create exceptions that attackers can exploit. The practitioner takeaway is to view CBA as part of the control plane for identity standardisation, not just as a better login method.
The real gap in legacy IAM design is fallback logic. Organisations often harden the primary sign-in path while leaving password resets, alternate devices, and recovery flows exposed. Those routes become the practical bypass for phishing-resistant MFA programmes. Identity governance has to extend to every exception path, or the authentication model remains partially phishable by design.
Phishing resistance is now a cross-domain identity issue, not just a human authentication issue. The same design flaw appears wherever access depends on reusable, interceptable credentials and inconsistent policy enforcement. The field is moving toward models that align authenticator strength, lifecycle governance, and platform consistency. Practitioners should expect phishing resistance to become a baseline control expectation rather than an advanced option.
Phishing-resistant authentication gap: The article shows that the control failure is not a lack of MFA, but a lack of phishing-resistant coverage across all identity paths. That distinction matters because governance succeeds or fails at the weakest override, exception, or fallback path. Practitioners should redesign identity policy around uniform resistance, not isolated strong points.
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
Legacy authentication design is where phishing resistance usually fails. The control weakness is rarely the strongest login path. It is the backup factor, alternate device, or legacy application that still accepts something phishable, and that is where governance needs to focus first.
Phishing-resistant authentication should be treated as an estate-wide consistency problem. If one IAM path remains weaker than the others, the programme still leaves a practical takeover route open.
For practitioners
- Map every authentication path Inventory primary login, step-up, recovery, reset, and admin access flows so you can see where phishable methods still exist.
- Eliminate phishable MFA methods on sensitive access Remove SMS and other interceptable factors from privileged and high-risk user journeys before attackers can target them.
- Standardise phishing-resistant controls across IAM systems Apply the same authentication policy across legacy and modern identity platforms so one weaker system does not undermine the rest.
- Extend governance to fallback and recovery journeys Review password reset, backup device, and exception handling paths with the same rigor as the primary sign-in flow.
Key takeaways
- Phishing-resistant MFA is only as strong as the weakest identity path, and legacy recovery flows often remain the real exposure.
- Certificate-based authentication helps by replacing phishable secrets with stronger device- or certificate-bound authentication.
- IAM teams need to govern consistency across systems, not just harden one sign-in experience.
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 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 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 remain phishable or replayable. |
| NHI-08 — Environment Isolation | Mixed IAM estates create uneven control boundaries across platforms and operating systems. | |
| Recommendation — Replace phishable authenticators with phishing-resistant authentication for all sensitive identity paths. Standardise authentication policy across platforms so weaker environments cannot undercut stronger ones. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The article discusses MFA methods, recovery, and credential lifecycle management. |
| Recommendation — Manage authenticators across their full lifecycle and retire weak or interceptable methods. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Authentication consistency is part of enforcing reliable access authorisation outcomes. |
| Recommendation — Align identity access policy so authentication strength is consistent across all authorised access paths. | ||
| MITRE ATT&CK | TA0006 — Credential Access | The threat pattern is credential capture through phishing and interception. |
| Recommendation — Hunt for phishing-led credential access and prioritise controls that block code and token interception. | ||
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.
- Alternate Authentication Path: An alternate authentication path is any credential or trust relationship that can be used after the primary token is removed. Security teams miss these paths when they treat revocation as the end of the incident instead of checking for newly planted keys, app grants, or delegated sessions.
- Identity system sprawl: The condition where multiple IAM platforms, directories, or authentication stacks coexist without consistent policy enforcement. This creates uneven security outcomes because the overall control strength is determined by the least governed system, not by the strongest one deployed.
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