Are passkeys replacing multi-factor authentication (MFA)?

What passkeys change, and what they do not

Passkeys shift the sign-in model from shared secrets to asymmetric cryptography plus local user verification. That is why they are usually more resistant to phishing, relay attacks and credential reuse than passwords or one-time codes. The important nuance is that this improves the authentication method, but it does not eliminate the need to think about recovery, device loss, privileged access and step-up checks for sensitive actions.

In practice, many organisations adopt passkeys as one strong factor or as the preferred primary factor inside an MFA programme rather than as a wholesale replacement for every second factor pattern. That framing matters because the security outcome depends on how the passkey is enrolled, whether it is device-bound or synchronised, and what happens when the user cannot access the enrolled device. Passwordless and Passkeys Guide explains the rollout and recovery trade-offs in more detail.

Where passkeys fit in an MFA strategy

MFA is a strategy, not one product. A passkey can satisfy a strong authentication requirement, but the broader control objective is still to reduce account takeover risk across enrolment, sign-in, recovery and high-risk transactions. That means organisations often keep additional controls around the passkey itself, such as reauthentication for admin actions, conditional access, fraud detection and stronger recovery workflows.

Passkeys are also not identical to every form of MFA. Some deployments function as phishing-resistant multi-factor authentication because they combine something you have, the device or authenticator, with something you are or know, such as biometrics or a local PIN. Others are best understood as passwordless single-step sign-in with local user verification. The operational question is not whether the label says MFA, but whether the overall sign-in path gives you phishing resistance, strong recovery and acceptable assurance for the risk of the protected action. MFA Guide is useful when comparing passkeys with SMS, authenticator apps and other methods.

For workforce sign-in, the strongest deployments usually combine passkeys with federation, session controls and step-up authentication for privileged or unusual activity. That reduces reliance on OTP prompts, which remain vulnerable to fatigue, relay and social engineering. Workforce Identity Security Guide covers those control layers together rather than treating passkeys as a standalone fix.

What to check before treating passkeys as a replacement

First, confirm what the organisation is actually trying to replace. If the target is SMS codes or push approvals, passkeys are usually a clear upgrade. If the target is a broader MFA posture that already includes strong phishing-resistant methods, passkeys may be a replacement for a weaker factor, not for the whole assurance model.

Second, check recovery and fallback paths. A strong passkey deployment can still be undermined by weak account recovery, help desk reset processes, or legacy fallback methods that are easier to phish than the passkey itself. Third, verify whether the policy distinguishes between everyday sign-in and high-risk operations. It is common to allow passkey sign-in for access, but still require step-up checks for password changes, payout approvals, admin changes or sensitive data export.

For organisations standardising on modern authentication, versioned guidance matters. NIST’s digital identity guidance is a practical reference point for phishing-resistant authentication and assurance decisions, especially when you need to decide whether a passkey is sufficient on its own or needs to sit inside a broader MFA design. NIST SP 800-63 Digital Identity Guidelines is the external baseline most teams use for that question.

Risk and Threat Considerations

Passkeys reduce several common attack paths, but they do not remove account recovery abuse, device compromise, session theft or poor fallback design. The risk shifts from password guessing and OTP phishing toward trust in the enrolled device, the recovery workflow and the controls that protect privileged or high-impact actions.

Failure mechanism: Attackers often bypass strong sign-in by targeting the weaker surrounding process, such as help desk resets, lost-device recovery, synced account access, stolen sessions or exceptions for urgent access. If those paths remain soft, the passkey itself becomes only one layer in a larger compromise path.

Impact: A successful bypass can still lead to account takeover, fraudulent approvals, administrative misuse or lateral movement into other connected systems. That is why the real measure of success is not whether passkeys are deployed, but whether they materially shrink the attack surface compared with the controls they replaced.

Practitioner Guidance

What to prioritise: Treat passkeys first as a phishing-resistance upgrade, then test whether your recovery and exception handling preserve that gain. If recovery can be social-engineered more easily than the original factor, the deployment is not yet mature enough to replace your existing MFA assumptions.

What to verify: Confirm which users and actions can rely on passkeys alone, which still require step-up authentication, and which fallback methods remain enabled. Review whether admin accounts, high-risk transactions and support workflows are governed differently from ordinary user sign-in.

Practitioner takeaway: Passkeys usually replace weaker MFA methods before they replace MFA as a strategy, so the decisive question is whether the surrounding recovery and step-up controls are as strong as the passkey itself.

Related resources from NHI Mgmt Group

• How should security teams choose between 2-factor authentication, multi-factor authentication, and adaptive MFA for remote and hybrid access?
• What is the difference between phishing-resistant MFA and conventional multi-factor authentication in cloud security?
• What is the difference between multi-factor authentication and phishing-resistant MFA in a DORA context?
• Why is it crucial to adopt new authentication methods in MCP usage?