Phishing resistance and certificate-based authentication in zero trust

At a glance

What this is: This article argues that phishing-resistant authentication, especially certificate-based authentication, is a zero-trust control choice because common MFA methods can still be phished and 84% of employees interacted with a phishing email in CISA data cited by Axiad.

Why it matters: IAM teams should treat phishing resistance as an authentication design requirement, not a branding label, because weak MFA can preserve the very attack paths zero trust is meant to close.

By the numbers:

• 84% of employees interacted with a phishing email, according to CISA data cited by Axiad.

Context

Phishing resistance is an identity control problem, not just an awareness problem. When authentication methods can be replayed, relayed, or tricked through social engineering, the control boundary still depends on user behaviour rather than cryptographic proof.

The article ties that weakness to zero trust, where every user, machine, and digital interaction must be continuously authenticated. In that model, certificate-based authentication matters because it shifts verification to public and private key trust rather than shared secrets or push approvals.

Axiad also frames the issue through national cybersecurity strategy and CISA guidance, but the governance lesson is broader. MFA is not a single control class, and programmes that treat SMS, OTP, push, and phishing-resistant methods as equivalent will misread their real exposure.

Key questions

Q: How should security teams prioritise phishing-resistant authentication in a zero trust programme?

A: Security teams should treat phishing-resistant authentication as a foundational control, not a niche enhancement. The practical goal is to reduce reliance on reusable secrets and password-based MFA, then extend stronger methods such as hardware-backed credentials across users, devices, and high-risk workflows. In zero trust programmes, that shift supports continuous verification, limits credential replay, and makes identity assurance more resilient.

Q: When does strong MFA still leave identity risk too high?

A: Strong MFA still leaves risk too high when recovery and revocation paths are weak. If help-desk reset, fallback verification, or token revocation can be manipulated, an attacker can bypass the primary factor through the operational edge of the identity process. Recovery design must be treated as part of authentication security.

Q: What signs show that an authentication programme is not truly phishing resistant?

A: Look for shared secrets, OTP dependence, push fatigue risks, and exceptions for privileged users. If the strongest methods are not required on the most sensitive paths, the programme is likely describing resilience it does not actually enforce.

Q: Should organisations prioritise continuous authentication over more MFA?

A: Yes, when the main risk is post-authentication attack, session theft, or privilege abuse after login. More MFA can reduce some account takeover risk, but it does not solve the trust window that remains open after authentication. Continuous authentication is the stronger choice when sessions, tokens, and machine identities drive operational risk.

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.
• Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.

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 an authentication assurance problem, not a user-behaviour problem: The control failure starts when programmes treat any second factor as equivalent protection. SMS, OTP, and push approvals can still be phished, relayed, or socially engineered, so the real question is whether the method cryptographically binds the authentication event to the intended device and origin. Practitioners should evaluate assurance by attack resistance, not by MFA label.

Certificate-based authentication changes the trust boundary in a way shared secrets cannot: Asymmetric cryptography and certificate chains let verification happen without exposing a reusable secret to the attacker. That matters because phishing succeeds by capturing something the attacker can replay later, whereas certificate-backed proof is anchored to the approved credential material and device context. The practitioner implication is to distinguish phishing-resistant methods from merely convenient ones.

Zero trust fails when authentication policy overstates its own strength: The article reflects a broader governance issue where programmes claim continuous verification but still allow weak methods in high-risk paths. That creates a false sense of coverage, especially when human users, remote workers, and hybrid endpoints all remain in scope. Identity teams should map method strength to access criticality instead of applying one authentication standard everywhere.

Phishing resistance and certificate-based authentication define a zero-trust boundary that many IAM programmes have not operationalised: The article's core concept is the phishing-resistant trust boundary, where access decisions depend on cryptographic proof rather than user-visible prompts. This is the point at which IAM, device trust, and certificate lifecycle governance converge. Practitioners should treat that boundary as a programme design choice, not a feature toggle.

Policy silence on phishing does not reduce the control requirement: Even when strategy documents fail to name phishing explicitly, the underlying identity risk remains unchanged. The absence of policy attention can distort investment priorities, but it does not change the attack path. Security leaders should build their own control logic around the threat as it actually behaves, not as it is politically named.

What this signals

Phishing-resistant authentication should be treated as a policy boundary, not a deployment preference: Once an organisation decides that some access paths demand stronger proof, the remaining question is which users, devices, and applications fall inside that boundary. That is an IAM architecture decision, not a communications campaign.

Certificate-backed proof and device-bound verification matter because they reduce reliance on user-visible challenge prompts, which is where many phishing attacks succeed. The control question is whether identity assurance survives adversary-in-the-middle conditions, not whether users were trained to notice suspicious mail.

Teams that still classify SMS, OTP, and push as equivalent to phishing-resistant methods will overstate their zero-trust maturity. The practical signal to watch is whether privileged and remote access paths have been explicitly remapped to stronger authentication methods.

For practitioners

• Replace phishable MFA on high-risk access paths Move administrative, financial, and privileged workflows to phishing-resistant methods such as certificate-based authentication or hardware-bound FIDO flows. Reserve weaker factors only for low-risk scenarios where the impact of session compromise is limited.
• Inventory authentication methods by assurance level Map SMS, OTP, push, FIDO, and certificate-based methods to specific user groups and applications, then identify where the current factor still permits phishing relay or social engineering.
• Tie zero trust policy to method resistance Define which access paths require cryptographic proof, device binding, and continuous re-verification, then remove any method that cannot meet the assurance target for that path.
• Review certificate trust and revocation governance Ensure certificate authority trust chains, issuance rules, and revocation processes are aligned so compromised or stale credentials cannot persist beyond their intended use.

Key takeaways

• Phishing-resistant authentication is about resisting replay and relay attacks, not simply adding a second step to login.
• The article links the issue to real exposure, citing CISA data that 84% of employees interacted with a phishing email.
• Certificate-based authentication matters because it binds trust to cryptographic proof and device context, which is harder for attackers to steal or reuse.

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.
• Zero Trust Authentication: Zero Trust Authentication is an approach that never assumes a user, device, or workload is trustworthy just because it is inside a network. It requires each sign-in or access request to be verified with strong identity signals, context, and policy checks, then continuously re-evaluated as risk changes.
• Phishing-Relay Attack: An attack in which a victim's authentication exchange is captured and forwarded so the attacker can use the resulting session or proof. This is why prompt-based and code-based methods can remain risky even when they are technically multi-factor.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.