Phishing resistance and certificate-based authentication in zero trust

At a glance

What this is: The article argues that phishing resistance, especially certificate-based authentication, is essential because common MFA methods remain vulnerable and current strategy documents understate phishing risk.

Why it matters: It matters because IAM teams still have to protect human identities, machine access, and zero-trust initiatives against social engineering paths that bypass weak authentication controls.

By the numbers:

• CISA said 84% of employees interacted with a phishing email.
• The National Cybersecurity Strategy mentioned ransomware 32 times in its 39-page document.
• 84% of employees interacted with a phishing email, underscoring the scale of social engineering exposure.

👉 Read Axiad's reflection on phishing resistance and certificate-based authentication

Context

Phishing resistance is the ability to verify identity in a way that is difficult for an attacker to intercept or replay. The article’s core point is that organisations cannot treat all MFA methods as equal when phishing remains a dominant entry path into enterprise accounts and downstream ransomware events.

The identity governance problem is broader than user login friction. Human authentication, machine trust, and zero-trust policy all depend on controls that survive social engineering, credential theft, and session hijacking. If the authentication layer is weak, the rest of the access model inherits that weakness.

Key questions

Q: How should security teams implement phishing-resistant authentication in enterprise access?

A: Start with privileged users, high-value applications, and remote access paths where phishing has the highest impact. Use FIDO or certificate-based authentication for strong proof, then pair it with lifecycle controls, device binding, and revocation processes so identity assurance persists after enrolment. Strong authentication without lifecycle governance only moves the problem later in the session.

Q: Why do common MFA methods still leave organisations exposed to phishing?

A: SMS, OTP, and push factors can be intercepted, relayed, or socially engineered in real time. They raise the bar compared with passwords, but they do not reliably prove the request came from the legitimate user on a trusted device. That makes them suitable for some contexts, but not for high-risk access where replay is a realistic attack path.

Q: How do you know if phishing-resistant authentication is actually reducing risk?

A: Look for lower rates of successful account takeover, fewer help-desk resets tied to login compromise, and reduced reliance on replayable factors for privileged access. The clearest signal is whether attackers lose the ability to reuse captured credentials across systems. If access reviews still show weak factors on critical accounts, the programme is not mature enough.

Q: Who is accountable when phishing succeeds despite zero-trust controls?

A: Accountability usually spans identity, endpoint, and application teams because zero trust depends on trustworthy authentication as well as policy enforcement. If the login factor is phishable, continuous verification cannot fully compensate. Governance teams should define ownership for authentication strength, certificate lifecycle, and exception handling so gaps do not linger between teams.

Technical breakdown

Why SMS, OTP, and push MFA still fail under phishing

SMS codes, one-time passwords, and push approvals can all be relayed or tricked out of a user in real time. They improve basic assurance over passwords, but they do not prove that the login request originated on the genuine device or from the legitimate user context. That leaves an attacker room to intercept tokens, proxy sessions, or induce approval. Phishing-resistant methods reduce this exposure by binding authentication to a stronger trust anchor. Practical implication: treat conventional MFA as a baseline, not a phishing boundary.

Practical implication: move high-risk populations to phishing-resistant authentication where compromise cost is high.

How certificate-based authentication changes the trust model

Certificate-based authentication uses asymmetric cryptography and a chain of trust to validate identity without exposing reusable secrets during login. A device or server can verify the certificate locally against a trusted authority, which makes credential replay far harder than with shared secrets or one-time codes. This shifts authentication from secret disclosure to key possession and certificate validity. In identity terms, the trust surface shrinks because the verifier checks proof, not just a presented token. Practical implication: prefer certificate-backed trust where users, devices, and applications need stronger assurance.

Practical implication: align high-assurance access with certificate-backed identity rather than replayable credentials.

Why zero trust depends on phishing-resistant identity proof

Zero trust assumes that each access request must be continuously evaluated, but that evaluation only works if the initial identity signal is reliable. If an attacker can phish a user or abuse a weak MFA factor, continuous verification simply extends an untrustworthy session. Certificate-based and FIDO-style methods support zero trust because they reduce the likelihood that the initial authenticated identity is fraudulent. The article’s point is that zero trust is not a policy slogan; it depends on authentication mechanisms that resist interception and replay. Practical implication: harden the authentication layer before claiming zero-trust maturity.

Practical implication: validate whether your zero-trust design is anchored to phishing-resistant authentication.

Threat narrative

Attacker objective: The attacker aims to convert a social engineering event into trusted access that can be reused for broader compromise.

1. Entry occurs when a user is lured by phishing and discloses credentials or approves a fraudulent authentication prompt.
2. Escalation follows when the attacker reuses the captured access to reach email, SaaS, or privileged enterprise systems.
3. Impact appears as account takeover, lateral movement, and, in some cases, ransomware execution or sensitive data exposure.

Breaches seen in the wild

• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

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 resistance is now an identity governance requirement, not an authentication preference. The article reflects a recurring reality: attackers routinely exploit the weakest factor in the login chain rather than break stronger cryptography. That means authentication choice directly affects identity risk, zero-trust credibility, and downstream incident containment. Practitioners should treat phishing-resistant access as part of identity governance, not as an optional security enhancement.

Certificate-based authentication reduces credential replay, but it does not solve identity assurance by itself. Asymmetric cryptography changes the shape of the attack surface, yet governance still depends on enrolment, device binding, certificate lifecycle, and revocation discipline. If those processes are weak, the assurance gained at login can be undermined later in the lifecycle. Practitioners should evaluate the full trust chain, not just the login method.

Phishing resistance bridges human IAM and NHI governance because both depend on non-replayable proof of identity. The same governance logic that protects service accounts and machine identities applies to human authentication when adversaries harvest credentials for reuse. This is where identity strategy becomes cross-domain: weak human authentication can be the first step in a machine- or workload-facing intrusion path. Practitioners should align access assurance across human, machine, and workload identities.

Continuous verification only works when the initial identity assertion is trustworthy. Zero trust is often framed as a network or policy model, but the model collapses if the first authentication event is phishable. The operational lesson is that continuous checks cannot compensate for a fraudulent starting point. Practitioners should review whether their zero-trust programme still depends on replayable secrets at the entry layer.

Phishing-resistant identity creates a lower blast radius by removing easy reuse paths. The article points to the practical value of reducing what an attacker can steal and replay. That lowers the probability that a single user compromise turns into multi-system access. Practitioners should prioritise controls that break the reuse chain, especially for privileged and high-impact accounts.

From our research:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
• 79% of organisations have experienced secrets leaks, and 77% of those incidents resulted in tangible damage, according to Ultimate Guide to NHIs.
• For a wider control view, see 52 NHI Breaches Analysis for recurring failure patterns across identity compromise cases.

What this signals

Phishing-resistant authentication is becoming a programme boundary, not a point control. Once attackers can convert a phish into reusable access, downstream IAM measures inherit that compromise. Teams should use the NIST Cybersecurity Framework 2.0 to align identify, protect, detect, and respond activities around stronger identity proof.

Replayable authentication factors create trust debt across human and machine access. That debt shows up later in incident response, access reviews, and privileged access decisions, especially when the same identity model supports people, devices, and services. The practical signal is whether your critical paths still depend on SMS, OTP, or push approval where phishing risk is highest.

Access assurance must now be measured by resistance to credential reuse, not by MFA checkbox coverage. With 30.9% of organisations storing long-term credentials directly in code, according to the Ultimate Guide to NHIs, weak identity proof often travels well beyond the login screen. Teams should test whether authentication choices actually break the reuse chain.

For practitioners

• Prioritise phishing-resistant authentication for high-risk users Move privileged admins, finance users, remote workers, and sensitive SaaS owners to FIDO, Windows Hello for Business, or certificate-based authentication before expanding to the rest of the workforce.
• Audit where MFA still allows replayable factors Inventory SMS, OTP, and push-based methods across critical applications, then classify each as acceptable only where the business impact of account takeover is low.
• Tie certificate trust to lifecycle controls Define enrolment, renewal, revocation, and offboarding workflows so that certificate validity follows identity status instead of lingering after access should end.
• Align zero trust to authentication strength Check whether continuous verification policies assume that the initial login was trustworthy, and replace weak factors at the entry point before extending session controls.

Key takeaways

• Phishing-resistant authentication belongs in identity governance because weak login factors can turn a single social engineering event into enterprise compromise.
• Certificate-based authentication improves assurance by reducing replayable secrets, but its value depends on lifecycle discipline and revocation.
• Zero trust only works when the initial identity proof is trustworthy, so teams should replace phishable factors on the highest-risk access paths first.

Key terms

• Phishing-resistant authentication: Authentication that is designed to withstand interception, replay, and prompt-based deception. It relies on stronger proof, such as cryptographic binding or device-backed credentials, so an attacker cannot easily reuse what a user presents during login.
• Certificate-based authentication: A login method that uses digital certificates and asymmetric cryptography to prove identity without exposing reusable secrets. In practice, it depends on certificate issuance, device trust, renewal, and revocation controls that must remain aligned with identity lifecycle governance.
• Zero trust: A security model that assumes no access request is trusted by default and requires continuous verification. For identity teams, the model only holds if the initial authentication is strong enough that later policy checks are not validating a fraudulent session.
• Replayable factor: An authentication method or secret that can be captured and used again by an attacker. SMS codes, OTPs, and some push approvals can fall into this category because they do not always bind the request to a trusted device or a non-transferable proof of possession.

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.

This post draws on content published by Axiad: Fresh Take: A Brief Reflection on the National Cybersecurity Strategy. Read the original.