Prompt and context
Your team is launching passkeys. Security prefers credentials bound to one device or hardware key; product worries that users will lose access after changing devices and wants synced passkeys. Explain the threat model, recovery, assurance, enterprise control, and what the relying party can observe.
Do not treat “passkey” as one assurance level. Separate whether a credential is backup-eligible, usable across devices, governed by an enterprise, and recoverable after a lost device.
What the interviewer tests
The interviewer expects passkeys to be understood as WebAuthn public-key credentials whose backup and sync properties differ. FIDO describes synced passkeys as usable on a new device through a passkey provider, while device-bound passkeys remain on one device or security key. WebAuthn Level 3 defines backup eligibility and backup state; NIST provides guidance for syncable authenticators.
Strong answers separate user experience, account recovery, enterprise lifecycle, provider trust, and high-assurance actions. They do not equate sync with “insecure” or device binding with “no recovery required.”
30-second answer
“Both can provide phishing-resistant public-key authentication, but synced credentials improve multi-device recovery while device-bound credentials fit policies that require non-copyability and centralized hardware control. I would tier the policy: synced passkeys for ordinary sign-in, device-bound or additional hardware credentials for administrators and high-value actions. The server stores credential ID, public key, backup properties, and status, but treats those properties as policy signals rather than absolute proof. Multiple credentials, revocation, and audited recovery are required.”
Step-by-step analysis
Step 1: Define the two credential types
Synced passkeys can be encrypted and synchronized by a platform or provider to a user’s registered devices. Device-bound passkeys keep the private key on one device or hardware security key. Actual assurance depends on platform, user verification, and policy; the label alone is insufficient.
Step 2: Tier by threat and assurance
Consumer sign-in often values recovery and multiple devices. Administrators, financial approval, key management, and high-value transactions prioritize non-copyability, device management, and offboarding. Let ordinary authentication use synced credentials while sensitive actions require a device-bound credential or step-up verification.
Step 3: Understand server-side fields
A WebAuthn record includes credential ID, public key, signature-related information, and backup eligibility and state properties. Servers can use these for policy and audit, but cannot treat backup state as a complete inventory of the user’s physical devices. Core verification still checks challenge, origin, RP ID, signature, and user verification.
Step 4: Design enrollment and multiple credentials
Allow multiple credentials and show creation time, device label, and recent use. High-risk roles should register a primary and a controlled backup credential. Registering a new credential should require an existing high-assurance authentication so a stolen session cannot silently bind an attacker’s device.
Step 5: Build recovery and revocation
Losing a device-bound credential can remove access, so a second credential or stronger manual recovery is necessary. Synced credentials reduce device-switch friction but place some recovery and sync trust in the provider. Recovery should create notices, cooling periods, or approvals and support revoking old credentials.
Step 6: Handle enterprise governance
Organizations need to know which roles use which credential type, whether personal sync accounts are allowed, and how offboarding revokes access. Device management, identity-provider policy, and WebAuthn RP configuration must work together; a frontend button alone is not governance.
Step 7: Migrate progressively and preserve compatibility
Allow both types initially and measure enrollment, success, recovery, and support. Set deadlines for high-risk roles and guide ordinary users. Do not remove passwords or legacy MFA until recovery and anomaly detection are stable in the real environment.
Step 8: Verify security and experience outcomes
Security outcomes include phishing takeover, abnormal credential binding, recovery abuse, and revocation latency. Experience outcomes include sign-in success, cross-device success, enrollment completion, lost-device recovery time, and support tickets. Segment by role, platform, and region.
Trade-offs, boundaries, and information gain
Synced credentials reduce loss and device-switch cost but increase dependence on the provider, account recovery, and enterprise policy. Device-bound credentials increase non-copyability but require backup devices, issuance, inventory, and recovery operations. High assurance does not mean every user should sacrifice usability.
Backup eligibility or state helps policy decisions but is not a fully verifiable physical fact. Sync does not mean a private key is sent in plaintext; distinguish implementation guarantees from the product threat model.
Model high-quality answer
“I would risk-tier passkeys into synced and device-bound types. Both use WebAuthn public-key authentication and can resist common phishing, while synced credentials suit ordinary multi-device recovery and device-bound credentials suit administrators, key management, and high-value actions.
The server stores credential ID, public key, backup properties, and status, and verifies challenge, origin, RP ID, and user verification. Backup properties inform policy and audit but are not a complete device inventory. Support multiple credentials and require controlled backups for high-risk users. Recovery, enrollment, and revocation need notices, approval, or cooling periods. Migrate in parallel first, then use takeover, recovery, sign-in, and support metrics to increase enforcement.”
Common mistakes
- Call synced passkeys insecure. Discuss provider sync, recovery, and the enterprise threat model.
- Say device-bound credentials need no recovery. Losing the only credential locks out the user.
- Treat one backup field as the device inventory. The server cannot infer every physical copy.
- Enroll new credentials without existing authentication. A stolen session can bind an attacker device.
- Use one policy for every role. Administrators and ordinary users have different assurance needs.
- Delete passwords and legacy MFA immediately. An untested recovery path creates mass lockouts.
- Ignore offboarding and personal sync accounts. Revocation and compliance become unenforceable.
- Measure only sign-in success. Recovery, revocation, and abnormal binding are security outcomes.
Follow-up questions and answers
Are synced passkeys still phishing-resistant?
In a correctly implemented WebAuthn flow, signatures remain bound to origin and RP ID. Sync changes portability and recovery trust; it does not remove origin binding.
When must you use device-bound passkeys?
When policy requires non-copyability, the enterprise can manage hardware, and it accepts issuance and recovery cost, such as for super-admins, key management, or high-value approval. Keep a second credential.
How does the server know that a user changed devices?
Credential records, backup properties, and authentication events provide signals, but not a complete device inventory. Device-management and identity-provider logs may add evidence.
How many credentials should an account have?
Set a limit by risk and support capacity, while ensuring high-risk roles have primary and backup credentials. Every add, delete, and recovery action needs notice and audit.
Can synced credentials be used for sign-in and device-bound ones for sensitive actions?
Yes. This is a common tiered policy. Sensitive actions should request the appropriate credential again in the same session and have an explicit recovery path.