NIST 800-63B and Passkeys: What It Allows and How to Implement It
NIST recognizes synced passkeys (syncable authenticators) as meeting AAL2, first in the April 2024 supplement to SP 800-63B and now in the SP 800-63-4 revision. AAL3 still requires a non-exportable key, which in practice means device-bound passkeys on hardware such as security keys. To implement, pick the assurance level each app needs, require phishing-resistant WebAuthn, control which authenticators are allowed, and plan account recovery so it isn't weaker than the passkey itself.
Why this matters#
Many security teams read older NIST guidance as “passkeys that sync to the cloud don’t count,” and held off on rollout. The 2024 supplement to SP 800-63B changed that by defining syncable authenticators and allowing them at Authenticator Assurance Level 2 (AAL2). That covers most workforce and customer logins. Only the highest-assurance use cases need the stricter device-bound option.
Synced vs device-bound passkeys under NIST#
| Synced passkeys | Device-bound passkeys | |
|---|---|---|
| Where the private key lives | Encrypted and synced across a user’s devices by a sync provider (for example a platform account or password manager) | Stays on one authenticator and can’t be exported (for example a FIDO2 security key) |
| Phishing resistant | Yes (WebAuthn binds the credential to the site’s origin) | Yes |
| Highest NIST level | AAL2 | AAL3, when the authenticator is hardware-based and non-exportable |
| Main trade-off | Security depends partly on the sync provider account | Loss or breakage of the device means you need a backup authenticator |
What NIST expects from syncable authenticators#
The supplement and the SP 800-63-4 revision set expectations for how synced keys are protected. The practical takeaways for implementers:
- Keys must be protected in sync. Private keys are encrypted before they leave the device, and the sync provider shouldn’t be able to use them.
- The sync account matters. Access to the sync fabric (the account that holds the synced keys) should itself be protected at a comparable assurance level.
- Know what you’re accepting. Relying parties can use WebAuthn attestation and authenticator metadata to learn more about the authenticator. Synced passkeys often provide limited attestation, so decide where that is acceptable.
- Phishing resistance is the point. WebAuthn’s origin binding is what makes passkeys resistant to credential phishing and relay, which OTP codes and push approvals are not.
Always read the current NIST text for the exact normative requirements. This page summarizes them for planning and is not a compliance determination.
Implementation checklist#
- Classify your apps by assurance level. Most workforce SaaS and customer accounts are AAL2. Privileged admin access, high-value transactions and some regulated systems may need AAL3.
- Turn on WebAuthn/passkeys in your identity provider (Microsoft Entra ID, Okta, Google Workspace, Ping and others support passkeys) rather than app by app.
- Decide which authenticators are allowed. For AAL2, synced passkeys from major platforms and managed password managers are generally fine. For AAL3 or admins, restrict to device-bound hardware keys using attestation or authenticator allow-lists.
- Require at least two authenticators per user (for example a synced passkey plus a hardware key) so a lost phone doesn’t force a weak fallback.
- Fix account recovery. Recovery by SMS or email link can undo the benefit of passkeys. Use identity re-verification or a second registered authenticator instead.
- Retire weaker factors in stages. Once passkey enrollment is high, remove SMS and voice OTP, then push-only approvals, for the populations that have moved.
- Monitor. Watch registrations of new authenticators and recovery events. These are what attackers target once phishing stops working.
Common mistakes#
- Treating all passkeys as AAL3. Synced passkeys stop at AAL2.
- Leaving password plus SMS fallback enabled for everyone, so attackers simply downgrade.
- Ignoring the sync provider account, which becomes a high-value target.
- Rolling out passkeys but keeping help-desk recovery that resets them with a phone call.
Related reading
This page is general information, not compliance or legal advice. Confirm requirements against the current NIST publication.