Synced Passkeys vs Hardware Security Keys

Two users can both sign in with passkeys while relying on different recovery systems. One uses a synced credential. The other uses a credential confined to a security key.

The useful question is which policy fits the account. Consider the permitted action, recovery process, and evidence your application can actually verify.

This guide builds that policy. For browser integration, start with the passkey autofill walkthrough.

Separate the credential from the device

A synced passkey can become available on several devices through its provider. A device-bound credential remains with its authenticator.

A removable hardware security key can work with several computers while retaining the same credential internally. That is different from synchronizing the credential.

Yubico's credential comparison explains the distinction between single-device and multi-device credentials.

Do not equate “phone” with “synced” or “USB device” with an approved corporate key. Labels and connection types are insufficient policy evidence.

Understand the backup flags

After verification, WebAuthn authenticator data exposes backup eligibility and backup state. These are commonly abbreviated BE and BS.

Backup eligibility remains fixed for the credential. Backup state can change.

Check your server library's field mappings before using these signals. Backup state must not stand in for backup eligibility.

These flags describe credential properties. They do not identify a manufacturer's model, prove enterprise ownership, or measure the security of a sync account.

Use the WebAuthn backup-state rules as the protocol reference.

Distinguish a touch from user verification

User presence indicates interaction with the authenticator. User verification checks a local factor, such as a PIN or biometric.

A touch alone does not establish the same result as successful user verification. Read the verified assertion result when your policy requires verification.

Yubico's user-verification explanation describes these separate signals.

Avoid promising that a service receives the user's biometric. The application receives an authentication result, not the fingerprint or face template.

Write policy by action

Consider a hypothetical SaaS product with ordinary users and a small operations team.

An ordinary user needs convenient access and reliable recovery. An operator who changes account ownership needs stronger controls and an independent recovery route.

This is a design example. It is not a universal assurance classification or a claim that all operators need identical hardware.

Do not encode policy as “if passkey, allow everything.” A successful sign-in does not authorize every business action.

Verified authentication result
  |-- user verification --> does this satisfy the action's requirement?
  |-- backup properties --> does this satisfy the credential policy?
  '-- attestation trust -> is approved-hardware evidence required?
              |
              v
Application authorization --> may this account perform this action?

Treat hardware approval as a separate decision

If your organization requires approved hardware, define how enrolment proves compliance.

Attestation can provide information about an authenticator under a configured trust policy. An AAGUID identifies an authenticator model; it does not establish trusted provenance by itself.

Decide which trust sources, authenticator models, and enrolment procedures your team will maintain. Include exceptions and replacement procedures.

Yubico's attestation guidance is a useful starting point for that additional system.

NamoID's current registration helper requests no attestation. Do not describe that default as manufacturer-enforced hardware assurance.

A general passkey service and a managed-hardware policy solve different operational problems.

Plan for losing the authenticator

A device-bound credential needs a recovery plan for device loss. Registering a second physical key can provide another route when that policy permits it.

Register the second key separately. Do not describe two registrations as copying a private key from one security key to another.

Test both credentials before relying on them. Keep them in separate locations so one incident does not remove both.

For synced credentials, review dependence on the provider's account and recovery process. Convenient synchronization changes the dependency; it does not remove it.

Use the recovery-design guide to prevent a weak fallback from bypassing the intended policy.

Keep credential removal separate from session removal

Deleting a registered credential prevents its future use at your service. It does not necessarily end sessions already created through that credential.

Define the response to a lost key. It may include credential removal, session revocation, a notification, and review of sensitive changes.

For a departing operator, remove the intended business access as well. An account can retain a working credential while losing authorization to administer a customer.

Connect these actions to your account-operations process.

Run a policy review before rollout

Download the policy worksheet. Assign an owner to each exception and recovery route.

Test a backup-state change, missing user verification, rejected enrolment, lost authenticator, and an existing session after credential removal.

Record what your server verifies and what remains a procedural assurance. Do not convert an operator's device nickname into a security claim.

Hardware testing must identify the model, firmware, client platform, and tested protocol. This article reports no physical-device benchmark.

Discuss the policy with NamoID engineers

The NamoID team can help review customer authentication, credential enrolment, recovery, and the integration work around them.

Contact our team in Slack for an early response. Describe the protected action and the evidence your policy requires. We can help identify the next implementation question.