Synced passkeys stop phishing for most users, but because their private keys can be copied to other devices they cannot meet NIST Authenticator Assurance Level 3 (AAL3), so some accounts need passkeys that never leave one piece of hardware. The hard part is not buying security keys. It is deciding which identities justify device-bound credentials, proving at registration that a credential really is device-bound, and keeping that guarantee through enrolment, recovery and device refresh. This guide covers that decision and its enforcement in depth: what NIST SP 800-63B-4 requires at AAL3, which WebAuthn signals a relying party can trust, how attestation and the FIDO Metadata Service fit, and how to roll out and measure an AAL3 population. It assumes the wider rollout is already planned with the Passkey Rollout Guide and is written for identity architects, IAM engineers and security leads.
Key takeaways
- Exportability is the dividing line. NIST SP 800-63B-4 states that the AAL3 authenticator must have a non-exportable private key and provide phishing resistance, and that syncable authenticators shall not be used at AAL3.
- The BE flag alone is a claim, not proof. Backup Eligibility = 0 marks a single-device credential, but only a verified attestation from a known authenticator model tells you the hardware actually behaves that way.
- Attestation is a registration control. It is checked when the credential is created; credentials registered before you enforced it stay as they are until you re-enrol them.
- Scope AAL3 to blast radius. Identity provider administrators, cloud owners, privileged access users, break-glass accounts and people who can reset others' credentials gain the most; most staff do not need it.
- Recovery sets the real assurance level. A device-bound passkey protected by a help desk that resets it over the phone is only as strong as that phone call.
What AAL3 actually requires
SP 800-63B-4 sets out AAL2 and AAL3 in section 2. The differences that matter for passkeys are summarised below, from NIST's own text.
| Requirement | AAL2 | AAL3 |
|---|---|---|
| Phishing resistance | Verifiers must offer a phishing-resistant option; federal agencies must require it for staff, contractors and partners | Required |
| Key exportability | Permitted (synced passkeys allowed) | Non-exportable private key required; syncable authenticators shall not be used |
| Key storage | No isolation requirement for exportable keys | Non-exportable keys stored in an isolated execution environment |
| Cryptographic validation | Federal procurement: FIPS 140 Level 1 | Authenticators validated at FIPS 140 Level 1 or higher overall; verifier cryptography also FIPS 140 Level 1 or higher |
| Reauthentication, overall | Should be no more than 24 hours | Shall be no more than 12 hours |
| Reauthentication, inactivity | Should be no more than 1 hour | Should be no more than 15 minutes |
Section 3.2.13 defines exportability strictly: keys count as exportable unless the authenticator generates, stores and uses them internally, and a non-exportable authenticator must prevent export of the secret to the host processor and must not be reprogrammable to allow extraction. NIST also recommends authenticators that have undergone independent security testing. In passkey terms, the authenticators that normally qualify are FIDO2 security keys and platform authenticators whose keys live in a TPM or secure element and are created as single-device credentials. A passkey held by a credential manager that syncs, or that supports export through the FIDO credential exchange formats, does not qualify, however strongly the device itself is protected. See the FIDO Credential Exchange Passkey Portability Guide for how export works.
The reauthentication rows are easy to overlook. Moving administrators to AAL3 credentials while their sessions run for a working week does not deliver AAL3. Set session lifetime and idle timeout for the AAL3 population in the identity provider and in privileged tools at the same time. For the wider standard, see the NIST SP 800-63 Digital Identity Guidelines Guide.
Deciding who needs device-bound passkeys
Device-bound credentials cost more: hardware, shipping, a spare per person, and support when keys are lost or laptops are replaced. Spend that where a single phished or stolen session causes outsized harm.
| Population | Recommended assurance | Why |
|---|---|---|
| Identity provider and directory administrators | AAL3, device-bound with attestation | Control every other account; first target in help desk and session theft attacks |
| Cloud organisation owners, PAM users, CI/CD and secrets platform admins | AAL3 | Can create or exfiltrate non-human credentials at scale |
| Break-glass accounts | AAL3, keys stored under dual control | Must work when the identity provider's conditional access or sync services do not |
| Help desk and identity operations staff | AAL3 or managed device-bound | Can reset other people's authenticators |
| Finance approvers, executives, legal | AAL2 synced in a managed provider, or device-bound by risk | Targets of fraud and social engineering more than direct account takeover |
| General workforce, customers | AAL2 synced passkeys | Phishing resistance at scale; NIST says missing attestation should not block synced passkeys in broad public-facing services |
Small organisations: two security keys per administrator and synced passkeys for everyone else captures most of the benefit with little logistics. Large and regulated organisations: define the AAL3 population as a group derived from role assignments (privileged roles, PAM eligibility), so that a person who gains an admin role is automatically pulled into the device-bound policy rather than relying on a manual list. Federal agencies should also note the SP 800-63B-4 syncable appendix, which requires federal enterprise sync fabrics and devices to be managed and prevents syncing keys to unauthorised devices, a useful AAL2 baseline for staff not in the AAL3 group.
How a relying party knows a passkey is device-bound
WebAuthn Level 3 gives the relying party three kinds of evidence at registration. Each has limits, so strong enforcement combines them.
| Signal | What it tells you | Limits |
|---|---|---|
| BE flag (bit 3 of authenticator data flags) | 0 = single-device credential that the authenticator will never allow to be backed up; 1 = multi-device credential. Set at creation and must not change | Asserted by the authenticator; without trusted attestation you are relying on the authenticator's honesty |
| BS flag (bit 4) | Whether a multi-device credential is currently backed up. BE = 0 with BS = 1 is not allowed | Changes over time; describes the past, not what a provider may do later |
| Attestation statement and AAGUID | With direct or enterprise conveyance, a signed statement chaining to the manufacturer identifies the authenticator model | The default conveyance is none; many synced providers return no attestation; it does not protect against a compromised registration page |
| Enterprise attestation | May uniquely identify the individual authenticator, so registrations can be tied to keys the organisation issued | The specification says user agents must not provide it unless the user agent or authenticator configuration permits it for that RP ID; needs provisioned keys or managed browsers |
The practical rule: require attestation: "direct" (or enterprise for issued keys) for the AAL3 group, verify the attestation chain against trusted roots, check the AAGUID against an allow list of models you have assessed as non-exportable and FIPS validated, and reject any registration where BE = 1. The specification recommends storing the most recent BE and BS values with the user account, which lets you alert if a credential later presents an impossible flag combination.
The WebAuthn attestation limitations section is worth reading in full. An attestation statement says nothing about whether the registration page itself was tampered with; a man-in-the-middle at registration can substitute both the attestation and the public key. Protect the enrolment ceremony itself: require an existing phishing-resistant sign-in or an in-person or verified identity check before a new AAL3 credential is bound. See the Hardware key attestation guide for attestation formats and the FIDO2 and WebAuthn Internals Guide for the ceremony detail.
Using the FIDO Metadata Service
The FIDO Metadata Service (MDS3) publishes a single digitally signed BLOB containing the registry of FIDO certified authenticators and their metadata statements. The FIDO Alliance describes it as public with no authorisation token required, says relying parties must validate the signature chain against the published root, and suggests downloading monthly and caching. Commercial relying parties need a licence under the Metadata Usage Terms. Use MDS to:
- Build the allow list: map each AAGUID you accept to its metadata statement, certification level and key protection characteristics.
- Revoke trust quickly: when a model's status changes for security reasons, block new registrations and plan re-enrolment for existing holders.
- Express policy in certification terms: for example "FIDO Certified at a given level or above", reviewed when your hardware estate changes.
Enforcing device-bound passkeys in practice
- Define the AAL3 group from privileged role assignments, and decide the accepted authenticator models (security keys and, where you can verify them, managed platform authenticators).
- Configure a separate passkey policy for that group in the identity provider: attestation enforced, AAGUID allow list, user verification required, synced passkeys excluded. Keep the general workforce on its own policy so that tightening one does not break the other.
- Issue two authenticators per person. WebAuthn notes that a single-device credential is not resilient to device loss and that relying parties should ensure additional authenticators or a recovery process. NIST also recommends binding multiple authenticators to support recovery.
- Enrol under supervision or from an existing phishing-resistant session. No temporary passwords or SMS codes as the bootstrap for AAL3 enrolment.
- Re-enrol existing credentials. Because attestation is checked at registration, credentials registered before enforcement stay as they were. Remove them once each user has two compliant authenticators.
- Bind sessions and timeouts. Apply the 12 hour overall and 15 minute idle limits to the AAL3 group and require step-up with the device-bound credential for privileged operations.
- Remove fallbacks. Disable password, OTP and push methods for the AAL3 group once enrolment is complete, otherwise an attacker simply chooses the weaker method. See the MFA Fatigue and Bypass Guide.
Testing and rollback: pilot with the identity team first, in report-only conditional access where the platform supports it, and keep a documented, monitored break-glass path while you remove fallbacks. Changing an AAGUID allow list is itself a change: removing a model can lock out its holders, so stage list changes and notify affected users first.
Recovery, offboarding and device refresh
Device-bound credentials make recovery the main attack path. The MGM Resorts breach is the reference case: attackers reportedly phoned the IT help desk posing as an employee and then claimed administrator access to the identity provider. A strong authenticator does not help if the desk will replace it on request.
- Lost primary key: the user signs in with the spare and registers a replacement; no help desk involvement needed.
- Both keys lost: identity proofing at a level appropriate to AAL3 (in person or supervised remote), then a short-lived, single-use enrolment code bound to a new key. Notify the user and their manager out of band.
- Device refresh: platform authenticator credentials do not move to the new laptop. Plan a second registration before the old device is wiped.
- Offboarding: delete the credential records at the relying party and identity provider, and recover issued keys; serial-number tracking is easier when you use enterprise attestation.
See the Account Recovery and Help Desk Security Guide and the Passkey account recovery guide.
Where identity fits
The AAL3 group is small, but it holds the keys to most non-human identities: the people who create cloud service principals, approve CI/CD secrets and administer the secrets manager. Pairing device-bound passkeys for these humans with short-lived workload credentials removes the most common path from one phished administrator to thousands of long-lived machine secrets. See the Break-Glass Account Guide for the accounts that sit outside normal policy.
Detection and measurement
Log, for every registration in the AAL3 group: AAGUID, attestation format and result, BE and BS flags, user verification, and who or what authorised the enrolment. Alert on:
- Registration attempts rejected for BE = 1 or a non-allowed AAGUID (a spike may mean users are being coached to register the wrong thing).
- Any sign-in by an AAL3 group member with a method other than the device-bound passkey.
- New authenticator registrations shortly after a help desk interaction or from a new location.
- An AAL3 account with only one registered authenticator.
| Metric | Target |
|---|---|
| AAL3 group members with two compliant device-bound authenticators | 100% |
| Privileged sign-ins using a non-device-bound method | 0 after enforcement date |
| Registered AAGUIDs outside the allow list in the AAL3 group | 0 |
| AAL3 sessions exceeding the 12 hour overall limit | 0 |
| Median time to replace a lost key without a password fallback | Tracked and falling |
Framework mapping
| Practice | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 |
|---|---|---|
| Phishing-resistant MFA for privileged accounts | IA-2(1) Multi-factor Authentication to Privileged Accounts, IA-2(8) Access to Accounts: Replay Resistant | PR.AA-03 |
| Authenticator issuance, replacement and spares | IA-5 Authenticator Management | PR.AA-01 |
| Hardware token based authentication | IA-5(2) Public Key-based Authentication | PR.AA-03 |
| Session limits for the AAL3 group | AC-12 Session Termination | PR.AA-05 |
| Registration and sign-in monitoring | AU-2 Event Logging | DE.CM-03 |
Common failure patterns
- Trusting BE without attestation: accepting any credential reporting BE = 0 lets an unassessed or software authenticator into the AAL3 group.
- Enforcing attestation after enrolment: the policy is switched on once most admins have registered synced passkeys, which remain valid.
- Leaving fallbacks enabled: device-bound passkeys are registered, but password plus push remains available, so attackers keep phishing the push.
- One key per person: the first lost key becomes a help desk reset with a temporary password, undoing the control.
- AAL3 credentials, AAL2 sessions: long session lifetimes and stolen session tokens bypass the strong credential entirely.
- Manual group membership: new administrators are never added to the device-bound policy.
Practitioner checklist
- Define the AAL3 population from privileged role assignments, including help desk and break-glass accounts.
- Publish an AAGUID allow list of assessed, non-exportable models, built from FIDO MDS data.
- Require direct or enterprise attestation, user verification and BE = 0 for that population.
- Issue and register two authenticators per person before removing fallbacks.
- Re-enrol credentials registered before enforcement.
- Set 12 hour overall and 15 minute idle session limits for the group.
- Write an AAL3 recovery procedure with identity proofing and no password bootstrap.
- Alert on non-passkey sign-ins and single-authenticator accounts in the group.
Standards and references
- NIST: SP 800-63B-4 Authentication and Authenticator Management
- NIST: SP 800-63B-4 Syncable Authenticators
- W3C: Web Authentication Level 3
- FIDO Alliance: FIDO Metadata Service
- NIST: SP 800-53 Rev. 5
- NIST: Cybersecurity Framework 2.0
Related NHI Mgmt Group resources: Passkey Rollout Guide · Hardware Security Keys Guide · Passkey Providers · Top 10 Passkey Deployment Mistakes