How do phishing-resistant MFA, passkeys, and PKI fit together?

They are complementary rather than interchangeable. Passkeys and PKI both provide phishing-resistant authentication, but different environments may need different authenticators and recovery methods. Organisations should compare them by assurance strength, device compatibility, and recovery model, then standardise the policy layer while allowing multiple approved authenticators.

Why This Matters for Security Teams

Phishing-resistant MFA is not a single product category, and treating passkeys and PKI as interchangeable leads to brittle identity architecture. Passkeys usually improve user experience and lower phishing risk for human sign-ins, while PKI often fits managed devices, service access, and higher-assurance enterprise workflows. The security question is less “which one wins” and more “which authenticator fits which trust boundary, recovery path, and device population.” The operational stakes are visible in identity incidents such as the Microsoft Midnight Blizzard breach, where identity compromise became a broader control failure.

Current guidance suggests teams should anchor decisions in policy, not preference, and use a framework such as the NIST Cybersecurity Framework 2.0 to tie authentication strength to risk and recovery requirements. NHI Management Group’s research also shows why this matters operationally: 80% of identity breaches involved compromised non-human identities, which is a reminder that phishing-resistant human login is only one layer in a much wider identity attack surface. In practice, many security teams discover that “MFA done” still leaves them exposed when recovery, device enrollment, or privileged fallback paths are weaker than the primary login flow.

How It Works in Practice

Passkeys, PKI, and phishing-resistant MFA should be viewed as different implementation patterns for stronger authentication. Passkeys are typically based on FIDO2/WebAuthn and bind the credential to a user device, which makes phishing much harder because the secret is never typed into a login form. PKI uses certificates and private keys, often backed by hardware, to prove identity through cryptographic trust chains. Both can satisfy a phishing-resistant requirement, but they differ in portability, provisioning, lifecycle management, and recovery.

For security teams, the practical decision is to define the policy layer first and then allow approved authenticators underneath it. That means setting assurance requirements, device posture rules, and fallback expectations before choosing the tool. A workable pattern usually includes:

• Primary authentication with passkeys for users who can rely on modern devices and platform support.
• PKI for high-assurance or regulated environments where certificate lifecycle, managed endpoints, or smart cards are already established.
• Step-up controls for privileged actions, separate from everyday sign-in.
• Recovery processes that do not silently downgrade to weaker factors.

For NHI and machine-to-machine workflows, PKI often maps more naturally to workload identity than user-centric passkeys, especially when paired with short-lived credentials and explicit rotation. That is why identity architecture teams often pair user authentication guidance with NHI governance from the Ultimate Guide to NHIs and implementation standards like WebAuthn or certificate-based trust models. These controls tend to break down in mixed-device environments where legacy endpoints, shared workstations, and emergency account recovery create exceptions that bypass the strongest authenticator.

Common Variations and Edge Cases

Tighter authentication often increases operational overhead, requiring organisations to balance phishing resistance against enrollment friction, help desk load, and device compatibility. That tradeoff is real, especially when contractors, shared terminals, offline access, or regulated substations are part of the environment.

Best practice is evolving on how much standardisation is enough. Some organisations standardise on passkeys for most workforce users because they reduce phishing risk and simplify sign-in, while retaining PKI for admin access, device trust, signing, or machine identities. Others keep both because different user groups and endpoints need different recovery models. There is no universal standard for this yet, but the policy layer should remain consistent: one identity assurance policy, multiple approved authenticators, and explicit rules for when fallback is allowed.

Edge cases matter most in recovery. If a lost phone, failed certificate chain, or broken hardware token forces users into weaker bypass paths, the overall security posture collapses. That is also where identity governance intersects with broader NHI discipline: if recovery for humans is weak, recovery for automation is often weaker still. Organisations should treat authentication choice, recovery design, and lifecycle management as one control system, not separate projects.

Related resources from NHI Mgmt Group

• Should organisations prioritise phishing-resistant MFA over other identity projects?
• Why do passkeys and phishing-resistant MFA not solve fraud on their own?
• What is the difference between compliance-ready MFA and phishing-resistant MFA?
• What is the difference between push-based MFA and phishing-resistant authentication?