Device-bound and synced passkeys use the same cryptography, differently
The FIDO Alliance recognises two kinds of passkey. Device-bound passkeys never leave a single device. Synced passkeys are copied between a person's devices through a cloud service. Both follow the ceremony described in Part 1: a challenge, a signature, a key bound to one website. The difference is entirely about where the private key is allowed to exist.
Device-bound keys are the original model. The key is generated inside a chip, a security key, a smart card or a laptop's TPM, and the hardware is built so that it cannot be exported. That gives the highest assurance there is, and one hard consequence: lose the device and that passkey is gone for good. There is no recovery, by design.
Synced passkeys were the breakthrough that made passkeys practical for everyone. The key is still created and used inside secure hardware, but an encrypted copy is backed up and delivered to the person's other devices. A new phone arrives with its passkeys already on it.
What syncing protects, and what it now depends on
The major providers encrypt synced passkeys end to end. Apple says iCloud Keychain is end-to-end encrypted with keys that are not known to Apple. Google says passkeys in Google Password Manager are always end-to-end encrypted, that the private key is uploaded only in encrypted form, and that restoring them on a new device requires the screen lock of an existing one. In both designs the provider stores ciphertext it cannot read.
That is a strong design, but it moves the question. The passkey can no longer be phished, so an attacker's attention turns to the account that owns the keychain. If someone can take over that account and satisfy its recovery process, they may be able to bring the keychain, and the passkeys in it, onto a device they control.
A synced passkey is as strong as the account that protects the keychain. A device-bound passkey is as strong as the chip, and as fragile as the device.
Standards bodies reflect the same trade-off. NIST's 2025 digital identity guidelines allow syncable authenticators at Authenticator Assurance Level 2, which covers most workforce and consumer use, but not at Level 3, because AAL3 requires keys that cannot be exported.
Proving what the authenticator actually is
When a passkey is registered, the authenticator can include an attestation: a signed statement saying what make and model of authenticator created the key. Each model has an identifier, the AAGUID, and the FIDO Alliance publishes a metadata service that lets an organisation check it.
This is the lever that turns a passkey rollout into something an auditor can inspect. In Microsoft Entra ID, for example, enforcing attestation means only device-bound passkeys can register, and administrators can allow only the specific security key models they issue. Microsoft recommends security keys for highly regulated industries and users with elevated privileges.
Synced passkeys generally cannot offer the same assurance. Without attestation, Microsoft's documentation is blunt: the service cannot guarantee any attribute of a passkey, including whether it is synced or device-bound. For standard users that is usually an acceptable trade. For administrators, it usually is not.
Built into the device
Windows Hello for Business, Touch ID and Face ID, Android screen lock. Fast and familiar, but bound to that one device.
Carried by the person
USB or NFC security keys and FIDO2 smart-card badges. Works on any machine with a port or a reader.
Cross-device sign-in
A computer shows a QR code; the phone scans it and proves it is physically nearby over Bluetooth before signing.
Carried by the account
Available on every device signed in to the same provider. Portable and recoverable, but not attestable in the same way.
Matching passkeys to people, not people to passkeys
There is no single right kind of passkey for a whole organisation. The practical approach is to group people by how they work and what they can reach, then give each group the strongest option it will actually use. In Microsoft Entra ID these groups map directly onto passkey profiles, which let administrators apply different passkey rules to different groups, such as frontline staff and administrators.
Answer three short questions to see a recommendation. The table below summarises every path.
| Group | Typical choice | Why | Backup method |
|---|---|---|---|
| Privileged users | Security keys, attestation enforced | Highest assurance; provable hardware; no dependency on a consumer cloud account | Second security key |
| Standard staff, managed laptop | Device-bound platform passkey (e.g. Windows Hello for Business) | Fast, attestable, already on the device | Security key or phone passkey |
| Standard staff, low regulatory pressure | Synced passkeys | Phishing-resistant with recovery built in | Second passkey on another device |
| Shared workstations | FIDO2 badge or key with a reader | The credential follows the person between terminals | Phone via QR code, or a spare badge issued on site |
Shared workstations: when many people use the same machine
Most passkey guidance quietly assumes one person, one device. Reception desks, hospital wards, shop counters, contact centres and warehouse terminals break that assumption. A passkey bound to the shared PC would need every person enrolled on every machine, and it still would not follow them to the next terminal.
The answer is a roaming authenticator: the passkey lives on something the person carries. Microsoft's own documentation makes the point that security keys support shared device scenarios by letting people carry their credential and sign in on any supported device. The options differ mainly in speed:
| Option | How it works | At a busy desk | Fit |
|---|---|---|---|
| FIDO2 smart-card badge + NFC reader | Tap the badge on a small USB reader, type the badge PIN | A tap and a short PIN; the fastest carried option | Strong |
| Badge + tap-and-go platform | The same badge, with software that handles tap-in, tap-out and roaming sessions | Fastest in practice; widely used on clinical workstations | Strong |
| USB or NFC security key | A key on a lanyard or keyring | Similar to a badge | Good |
| Phone via QR code | Scan, unlock the phone, approve; Bluetooth proves proximity | Several steps; tiring dozens of times a shift | Fallback |
| Windows Hello on the shared PC | A passkey stored in that PC's chip | Fast once enrolled | Poor fit |
A badge tap looks trivial from the outside. Step through what actually happens inside it:
- Tap. The badge has no battery. The reader's radio field powers the chip for the moment it is in range, and near-field communication (NFC) carries the bytes.
- Windows asks the badge to sign. Using CTAP, the operating system sends a hash of the identity provider's name, a fresh challenge from the identity provider, and a requirement that the user be verified.
- The PIN. The badge asks for its PIN, which is typed on the PC. It is never sent in the clear: the two sides agree a shared key first, and the badge keeps its own counter of wrong attempts, locking itself after too many.
- The badge looks for a key for this site. If it holds none, it returns an error. The phishing wall from Part 1 is enforced inside the card itself.
- It signs. The badge signs the challenge with the private key, which never leaves the chip, and hands the signature back to Windows.
- The identity provider checks it. The signature is verified against the stored public key and a session starts. The same badge and the same PIN work on any terminal that has a reader.
Many FIDO2 cards can also carry a building access application on the same chip, so one badge opens the door and signs the person in. Whether that is possible depends on the technology your door readers use today, older 125 kHz proximity cards, HID iCLASS or Seos, or MIFARE DESFire, so that is the first question to answer before choosing a card. Manufacturers offering FIDO2 cards with physical access options include HID Global, Thales and Cryptnox.
Convenience comes out of assurance, so spend it deliberately
Fast environments push towards fewer, faster sign-ins: persistent workstation sessions, fast user switching, long session lifetimes. Each of those works by verifying the person less often. That is a legitimate design choice, but it is a trade, and it should be made with open eyes.
The badge model has a specific weak point. A tap on its own proves only possession of the card, and cards are shared, borrowed, left in readers and lent to a colleague who has forgotten theirs. The PIN is the only thing that makes the badge two factors. In a busy environment, the PIN is exactly what people are tempted to shortcut, write on the back of the card, or tell the person next to them.
On a shared workstation, the control that decides whether passkeys are secure is not the technology. It is whether people treat the PIN as personal.
Two practical rules help. Lock or end the session when the badge is removed, so a badge left behind is not an open door. And make sure staff know that every action is attributed to the badge holder, which changes how casually a card gets lent.
The rollout is decided by recovery, not by registration
Registering passkeys is the easy part. The hard questions are what happens when someone loses their only authenticator, how new starters get their first credential, and how leavers' credentials are revoked, including security keys that walk out of the door. Get those wrong and the help desk becomes a back door that bypasses everything above.
For organisations on Microsoft Entra ID there is also a deadline. From 1 September 2026, users enabled for SMS or voice codes began being enabled for passkeys and prompted to register one. From 1 February 2027, Microsoft-provided SMS and voice authentication is retired for all users except Global Administrators and external users, who follow on 1 July 2027. Shared-device populations need their own plan before then.
Part 4 · Recovery and lifecyclePasskey weaknesses: the attacks that still work, and how recovery becomes one→What to take into your rollout planning
Both kinds are phishing-resistant
Device-bound and synced passkeys differ in portability, recovery and provability, not in how they resist phishing.
Synced moves the risk to the account
End-to-end encryption protects the keys in transit and storage. The account behind the keychain becomes what to protect.
Attestation is the governance lever
Enforce it for privileged groups so only known, device-bound authenticators can register.
Shared desks need roaming credentials
Badges or keys with readers, fewer full sign-ins, and a PIN that people genuinely keep to themselves.
Which attacks do passkeys stop? Phishing, credential stuffing, breaches and replay
- FIDO Alliance, Passkeys
- Apple, About the security of passkeys
- Google, Security of passkeys in the Google Password Manager, October 2022
- Microsoft Learn, Passkeys (FIDO2) authentication method in Microsoft Entra ID
- Microsoft Learn, How to enable passkeys (FIDO2) and passkey profiles
- Microsoft Learn, Enable FIDO2 security key sign-in to Windows devices
- Microsoft Learn, Passkeys by default and retirement of Microsoft-provided SMS and voice authentication
- NIST, SP 800-63B-4, Authentication and Authenticator Management, 2025
- FIDO Alliance, Client to Authenticator Protocol (CTAP) 2.2, July 2025
- ASD, Essential Eight maturity model changes