What is the difference between a security key and a multi-device passkey?

A security key stores a WebAuthn or FIDO credential on dedicated hardware, so access depends on possession of that device. A multi-device passkey is copyable and can be synchronised across devices through a platform account and password manager. The first favours stronger binding and simpler trust assumptions, while the second favours convenience and easier recovery.

Why the Trust Model Changes

A security key and a multi-device passkey both satisfy WebAuthn, but they do so with different trust and recovery assumptions. The distinction matters because the authenticator model determines whether the credential stays bound to one physical item or can be replicated through an ecosystem account and password manager. That affects theft resistance, account recovery, portability, and how much the organisation must trust the surrounding platform.

For practitioners, the key question is not which option is “more modern”, but which failure mode is acceptable. A hardware-bound key reduces the number of places a usable credential can exist, while a synchronised passkey reduces lockout risk and makes recovery much easier. In practice, teams often discover the operational tradeoff only after a user loses access, rather than during design.

How the Two Models Behave Day to Day

A security key typically lives as a dedicated authenticator, such as a USB, NFC, or similar hardware device. The private key material is meant to remain on that device, so successful use depends on possessing the token at sign-in time. This is attractive when you want a narrow attack surface and clear physical control over the authenticator.

A multi-device passkey is designed for usability first. The credential can be synchronised across trusted devices, usually through a platform account and password manager, so a user can authenticate from a new phone or laptop without re-enrolling a new hardware token. That improves resilience against device loss, but it also broadens the trust boundary to include account recovery, cloud sync, and the protections around the user’s device ecosystem.

Security key, strongest when you need a single, non-copyable possession factor.
Multi-device passkey, strongest when you need recovery, portability, and lower user friction.
Both still rely on phishing-resistant WebAuthn flows, but the operational risk is not identical.

That difference becomes material when administrators expect one registration decision to cover both strong authentication and disaster recovery, because the two credentials do not fail in the same way.

Common Variations and Edge Cases

Tighter authentication often increases operational overhead, so organisations have to balance assurance against supportability. The practical answer can vary by user population, device ownership model, and account recovery process.

Shared workstations, regulated environments, and high-value administrative accounts often favour a hardware key because the organisation wants the credential to remain tied to one tangible authenticator. Consumer-facing or hybrid environments often favour multi-device passkeys because users will otherwise fall back to weaker recovery paths when they lose a phone or laptop.

One useful way to think about the choice is this: if compromise of the platform account or password manager would meaningfully weaken your sign-in assurance, the synchronised model deserves more scrutiny. If the bigger risk is users abandoning strong authentication after a device loss, the multi-device model may be the better operational fit.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8, NIST CSF 2.0 and NIST SP 800-63 set the technical controls, while ISO/IEC 42001:2023 define the regulatory obligations.

Framework	Control / Reference	Relevance
CIS Controls v8	6 — Access Control Management	Controls access enforcement and strong authentication choices
Recommendation — Apply CIS Control 6 to require the authenticator type that matches your access-risk profile.
NIST CSF 2.0	PR.AA — Identity Management, Authentication and Access Control	Covers authentication strength and access control decisions for sign-in methods
Recommendation — Align passkey and security-key policy to PR.AA to match authentication strength with the required trust boundary.
NIST SP 800-63	AAL — Authenticator Assurance Level	Directly distinguishes assurance levels across authenticators and recovery models
Recommendation — Map each sign-in method to the required AAL and avoid mixing recovery convenience with assurance requirements.
ISO/IEC 42001:2023	A.3 — Internal organization	Relevant where platform-managed passkeys are governed as part of identity and account policy
Recommendation — Define ownership and recovery rules for platform-managed passkeys within AI-enabled or digital identity governance programs.

Practitioner Guidance

What to verify: Confirm whether your policy is optimising for anti-cloning, account recovery, or user convenience. Those goals do not always point to the same authenticator type, and treating them as interchangeable leads to poor deployments.

Decision rule: Use a security key where the credential must remain physically bound to one device and recovery can be tightly managed. Use a multi-device passkey where availability and user continuity matter more, but only if the surrounding platform account protections are strong enough to carry that trust.

Common mistake: Assuming all passkeys provide the same security posture. The authenticator class changes whether the main risk is loss of possession or broader ecosystem compromise.

Practitioner takeaway: Choose the authenticator based on the failure you can tolerate, not the login experience you prefer, because the security difference is really about where trust, recovery, and copyability are allowed to live.