What is the difference between a FIDO2 security key and a passkey?

A FIDO2 security key is a physical authenticator that stores credentials on the device and requires possession to sign in. A passkey is a FIDO2 credential that lives on a phone, computer, or password manager and can sync across devices. Both support phishing resistant authentication, but they serve different operational and usability needs.

Why This Matters for Security Teams

The distinction between a fido2 security key and a passkey matters because authentication design now affects phishing resistance, recovery workflows, device trust, and help desk exposure. A security key anchors the credential to a physical device, while a passkey is typically stored in a platform or password manager and may sync across endpoints. That difference changes how teams think about lifecycle control, loss recovery, and who can approve sign-in events.

For practitioners, the operational question is not which option is “more secure” in the abstract, but which one fits the risk profile of the workload and the user population. NIST’s NIST SP 800-63 Digital Identity Guidelines treats phishing-resistant authenticators as a major step up from passwords, but it does not eliminate the need to manage enrollment, recovery, and device binding carefully. In NHI Management Group’s Ultimate Guide to NHIs, the broader lesson is the same: identity controls fail when organisations confuse strong authentication with complete governance.

In practice, many security teams discover the weakness only after a lost-device recovery path, sync issue, or account takeover has already created an exception process that bypasses the original control.

How It Works in Practice

A FIDO2 security key is a hardware authenticator that holds its private key on the device and signs a challenge only when the user can physically present it, often with a PIN or biometric unlock depending on the model and policy. A passkey uses the same FIDO2/WebAuthn cryptographic model, but the credential is stored in a phone, laptop, or password manager and may be synchronized through an ecosystem account. The authentication ceremony is similar; the deployment model is not.

That deployment difference drives most of the tradeoffs. Security keys are commonly chosen for high-assurance roles, shared kiosks, regulated access, or users who need a credential that does not depend on cloud sync. Passkeys are usually preferred where user experience and recovery matter more, especially for large populations that need frictionless login across devices. The current guidance suggests treating passkeys as phishing-resistant authenticators, but not as a blanket replacement for every high-risk use case.

Operationally, teams should decide:

• Whether the credential must remain bound to a single physical token or may follow the user across trusted devices.
• How lost-device recovery is handled, including step-up verification and fallback methods.
• Whether device attestation, PIN policy, or biometric unlock is required for certain applications.
• How enrollment, revocation, and backup enrollment are logged and reviewed.

For identity programs that also govern machine access, the lesson extends beyond humans. Phishing-resistant controls are only one layer; NHI Management Group’s research on The State of Non-Human Identity Security shows that visibility and rotation failures still drive compromise even when the access front door is improved. These controls tend to break down when organisations allow synced passkeys to become the only recovery path in environments with shared devices, weak endpoint assurance, or inconsistent account recovery governance.

Common Variations and Edge Cases

Tighter authentication usually increases user support overhead, so organisations need to balance phishing resistance against recovery complexity and device diversity. That tradeoff becomes most visible in mixed fleets, contractor populations, and regulated environments where not every endpoint is equally managed.

There is no universal standard for this yet, but current guidance suggests three common patterns. First, some organisations mandate security keys for administrators and privileged access while allowing passkeys for general workforce sign-in. Second, some prefer passkeys for day-to-day access and reserve security keys as a recovery or break-glass method. Third, some require both, using a passkey for convenience and a hardware key for step-up authentication on sensitive systems.

Edge cases worth planning for include:

• Shared workstations, where synced passkeys can create ambiguity about device trust.
• BYOD programs, where endpoint governance may be weaker than the authentication method itself.
• Air-gapped or heavily restricted environments, where platform sync is unavailable or undesirable.
• Users with multiple browsers or operating systems, where portability expectations differ.

Best practice is evolving toward risk-based selection rather than one universal authenticator standard. The practical test is whether the organisation can still prove who authenticated, on what device, under what policy, and with what recovery path. If that cannot be answered cleanly, the control is not finished, even if the login screen says “passkey” or “security key.”

Related resources from NHI Mgmt Group

• What is the difference between role-based access and API key governance for NHI security?
• What is the difference between API-key security and hardware-bound identity for AI agents?
• What is the difference between FIDO2 and WebAuthn for security teams?
• What is the difference between a standalone security key and a managed MFA platform?