TL;DR: Phishing still drives ransomware paths, yet many MFA methods remain vulnerable, and CISA says 84% of employees interacted with a phishing email, highlighting why certificate-based authentication and Zero Trust-aligned verification are gaining attention, according to Axiad and CISA. Identity programmes that stop at MFA labels miss the underlying trust model problem.
At a glance
What this is: This article argues that certificate-based authentication can shrink the identity attack surface by making phishing materially harder to exploit.
Why it matters: IAM teams need to distinguish truly phishing-resistant authentication from MFA methods that still depend on user interaction and can be socially engineered.
By the numbers:
- 84% of employees interacted with a phishing email, according to CISA data cited by Axiad.
Context
The security gap here is not authentication in general, but the trust model behind authentication. Phishing succeeds when an attacker can trick a user into approving or replaying a credentialed step that was never meant to prove possession of the real device or certificate.
For identity programmes, this is an IAM and Zero Trust question as much as a user-training question. Certificate-based authentication shifts verification toward device-bound cryptographic proof, which changes how teams think about phishing resistance, certificate lifecycle, and continuous authentication.
The article’s framing is typical of the current market discussion: organisations know MFA is not a single control, but many teams still overestimate the protection provided by methods that remain susceptible to interception or prompt fatigue.
Key questions
Q: What breaks when MFA is configured with weak, phishable factors?
A: Weak factors such as SMS codes, OTP apps, or push-based approvals can satisfy a policy checkbox while still leaving the environment open to phishing, man-in-the-middle, and push bombing attacks. That means the control may look compliant but fail under real attack conditions. Teams should test whether the factor actually binds the login to the user and target service.
A: Certificate-based authentication reduces phishing risk because authentication is tied to possession of a private key and trusted certificate rather than a reusable password. That makes credential replay and password theft less effective. It is especially useful for organisations trying to meet phishing resistant MFA expectations while improving assurance for cloud access and regulated environments.
Q: How should IAM teams decide when phishing-resistant authentication is needed?
A: Use phishing-resistant methods wherever account compromise would create material business or operational impact, especially for remote access, privileged users, and high-value applications. If a login path can unlock lateral movement, administrative action, or sensitive data, it deserves stronger authentication than phishable MFA.
Q: How do certificate-based controls fit into Zero Trust programmes?
A: They fit by improving continuous verification. Zero Trust depends on stronger evidence about the user, device, and session, and certificate-backed authentication gives practitioners a more reliable proof mechanism than prompts that a phisher can replay or manipulate.
Technical breakdown
Why some MFA methods remain phishable
SMS codes, OTPs, and mobile push approvals add a second step, but they still rely on a human responding to a challenge that an attacker can proxy or socially engineer. That makes them weaker than phishing-resistant methods because the secret or approval can be captured in transit or elicited under false pretences. Certificate-based authentication works differently: the device presents cryptographic proof tied to a trusted certificate chain, so the verifier checks possession rather than a reusable code. The security value is in reducing what the attacker can steal or replay during the authentication exchange.
Practical implication: treat MFA method choice as a control design decision, not a checkbox.
How certificate-based authentication changes the trust model
Certificate-based authentication uses asymmetric cryptography, so the private key stays on the trusted device while the server verifies the corresponding public certificate. The chain of trust is what matters operationally: certificate authority, root trust, and end-entity certificate validity all have to align for the authentication to succeed. Because the certificate can be validated locally and across systems, the credential is less exposed to phishing replay than a shared secret or one-time code. That reduces the attack surface, but only if certificate issuance, storage, and revocation are governed properly across the identity stack.
Practical implication: govern certificate issuance and revocation as part of IAM, not as a sidecar PKI task.
Where Zero Trust and phishing resistance meet
Zero Trust is about continuous verification, not one-time authentication. In practice, that means organisations need controls that verify every user, machine, and digital interaction with credentials that are hard to intercept and hard to reuse. Certificate-based authentication fits that model better than interactive MFA methods because it supports stronger proof of identity without depending on user judgement at every prompt. The key point is that phishing resistance is not an add-on feature of authentication; it is a property of how the trust chain is built and enforced.
Practical implication: align authentication architecture with Zero Trust verification requirements, not just access policy.
Threat narrative
Attacker objective: The attacker wants to obtain authenticated access that bypasses the user’s intended trust boundary and enables follow-on compromise.
- Entry begins with a phishing message that lures the user into a credentialed interaction or fake authentication flow.
- Credential harvesting occurs when the attacker captures a phishable secret, approval, or replayable response from the user.
- Escalation follows when the attacker uses the captured authentication path to access the target account and move into downstream systems.
- Impact is achieved when the attacker reaches data, ransomware staging, or other privileged actions that the stolen identity unlocks.
Breaches seen in the wild
- Co-op cyber attack 2025: Attackers linked to Scattered Spider tricked their way into a Co-op employee account and stole personal data of all 6.5 million members.
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 is now an identity architecture issue, not just an awareness issue. The article correctly separates authentication strength from the marketing language around MFA. When SMS, OTP, and push approvals remain phishable, the control objective is not simply second-factor presence but resistance to interception, replay, and social engineering. Practitioners should evaluate authentication based on the attacker’s ability to reuse what the user just proved.
Certificate-based authentication narrows the identity attack surface because it changes what is being verified. A password or code proves a user can repeat a shared secret. A certificate-backed exchange proves possession of a device-bound cryptographic credential within a chain of trust. That distinction matters for identity governance because it reduces the number of reusable artefacts an attacker can steal and forces teams to manage issuance, validity, and revocation more deliberately.
Continuous verification is the real Zero Trust linkage here. Zero Trust is not achieved by adding more prompts. It is achieved when authentication evidence is harder to phish and easier to validate across the transaction path. For IAM teams, that means phishing resistance should be treated as part of the access architecture, not a separate security awareness concern.
Phishing-resistant access controls must be governed as lifecycle controls. Certificates create their own operational risk if issuance, recovery, and revocation are weak. The control story does not end at successful login; it extends into credential governance, endpoint trust, and the conditions under which authentication material can be trusted or withdrawn. The practitioner implication is to align authentication design with identity lifecycle discipline.
Identity programmes that still equate MFA with security are carrying trust-model debt. The gap is not simply outdated tooling, but an assumption that any second step meaningfully resists phishing. That assumption breaks when the second step itself can be proxied, coerced, or replayed. The implication is that teams should re-baseline authentication policy around phishing resistance, not factor count.
What this signals
Certificate-based authentication is best understood as trust-chain governance. The important question is not whether a user completed a second step, but whether the authentication evidence can be replayed, proxied, or socially engineered. That is why IAM teams should separate phishing-resistant controls from generic MFA in policy, architecture, and reporting.
The next programme decision is where to place stronger authentication first. High-risk access paths, remote workforce flows, and privileged sessions are the places where phishable authentication creates the largest identity blast radius, so those are the first candidates for stronger device-bound verification.
For practitioners
- Define phishing resistance as a requirement Set an explicit standard for which authentication methods count as phishing-resistant in your environment, then exclude methods that still depend on shared secrets or user approvals vulnerable to proxy attacks.
- Prioritise certificate-backed authentication for high-risk access Use certificate-based authentication for employee, admin, and remote access paths where identity compromise would create outsized blast radius, especially in hybrid work scenarios.
- Review certificate lifecycle controls Check issuance, storage, renewal, and revocation processes so certificates do not become long-lived trust artefacts that outlive device or user assurance.
- Reassess Zero Trust verification points Map where your access flow still relies on user judgement rather than cryptographic proof, and move those checkpoints toward stronger device-bound verification.
Key takeaways
- Phishing-resistant authentication matters because many common MFA methods still allow attackers to intercept or replay the second factor.
- Certificate-based authentication reduces exposure by binding verification to cryptographic proof and a trusted device instead of a reusable secret.
- IAM teams should treat authentication method selection as a Zero Trust and lifecycle governance decision, not a generic MFA rollout.
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 Zero Trust (SP 800-207) and NIST SP 800-63 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 focuses on phishable authentication methods and stronger identity verification. |
| NHI-10 — Human Use of NHI | Certificate-backed credentials and device trust make human-driven authentication safer and more governable. | |
| Recommendation — Replace phishable authentication paths with methods that resist proxying, replay, and user-approval abuse. Govern certificate-backed authentication as human access material that still needs lifecycle controls. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust principles — Continuous verification | The article explicitly links stronger authentication to Zero Trust adoption and continuous verification. |
| Recommendation — Anchor access decisions in continuous verification rather than one-time login events. | ||
| NIST SP 800-63 | SP 800-63B — Authentication and lifecycle management | The discussion is fundamentally about authenticator strength and phishing-resistant authentication assurance. |
| Recommendation — Use authentication assurance guidance to separate phishable methods from phishing-resistant ones. | ||
Key terms
- Phishing-Resistant Authentication: Phishing-resistant authentication proves identity without relying on a user to approve a prompt or reveal a reusable secret. It typically binds access to a device, key, or cryptographic proof that an attacker cannot easily reuse or coerce. This approach reduces reliance on human judgment at login time.
- 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.
- Chain of trust: A chain of trust is the linked set of assurance steps that validates identity from proofing through authentication and device binding. In Derived PIV deployments, the chain must remain intact even when the credential is used on mobile, BYOD, or disconnected endpoints.
- Zero Trust Verification Boundary: The set of systems and identities that a programme actively validates before trusting access. If the boundary excludes a major cloud tenant, the programme is only partially operating as Zero Trust, even if the policy language says otherwise.
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