Mapping Passkeys to NIST AAL2 and AAL3

The NIST digital identity guidance defines authenticator assurance levels in terms of factors, replay resistance and verifier impersonation resistance. Passkeys satisfy most of those properties comfortably, and one of them contentiously. This page covers what each level asks for, where a synced credential lands, and how to produce evidence for whichever claim you make. It sits under Enterprise Policy and Compliance Controls.

Property Reference

Property Mechanism in WebAuthn Where checked
possession signature by a non-exportable private key server, on every assertion
verification of the claimant the user-verification flag server, per action
replay resistance single-use challenge with an expiry server, at consumption
verifier impersonation resistance origin binding browser, before the ceremony
hardware protection attestation plus metadata server, at enrolment

The first four are available in every deployment. The fifth requires attestation, which is what separates the AAL3 conversation from the AAL2 one.

What each level asks for The levels differ in how many factors are required and how strongly the authenticator must be protected. Three levels, and passkeys sit differently in each AAL1 single factor of any kind — a passkey exceeds this comfortably AAL2 two factors, or a single multi-factor authenticator; replay resistance AAL3 hardware-based authenticator plus verifier impersonation resistance across all levels phishing resistance is a separate property the guidance calls out

Root Cause Analysis

1. Claiming a level without checking the flag. An AAL2 claim rests on the authenticator having verified the claimant. If your server never reads the user-verification bit, the claim rests on a request option you sent rather than on anything that was checked.

2. Assuming AAL3 follows from “hardware”. The guidance asks for a hardware-based authenticator, and a synced passkey is hardware-held on each device it reaches — but the set of devices is governed by a consumer cloud account rather than by physical possession. That is the contested point, and it should be named rather than glossed.

3. Conflating phishing resistance with an assurance level. Verifier impersonation resistance is a property the guidance treats separately, and passkeys have it at every level. It is one of the strongest things you can say, and it gets lost when everything is compressed into a single level label.

4. Producing no evidence. The most common finding. The properties are satisfied; nothing records that they were checked, so the claim cannot be substantiated on demand.

Where a synced passkey lands A synced credential is a strong AAL2 candidate and struggles at AAL3 for a specific, nameable reason. The AAL3 question is about the sync boundary, not the cryptography meets, for AAL2 possession of a non-exportable key verification performed by the authenticator replay resistance from the challenge verifier impersonation resistance from origin binding contested, for AAL3 the key is hardware-held on each device but the set of devices is governed by a cloud account no attestation of the hardware no device-unique identity Which is why deployments needing AAL3 reach for attested hardware authenticators.

Step-by-Step Resolution

Step 1 — decide which level the system needs, per action rather than globally

Reading an account and moving money rarely need the same assurance, and a single global level either over-constrains the first or under-protects the second.

Step 2 — enforce user verification where the level requires it

Request it, then check the flag in the response, then record the result on the session. All three steps, or the claim is unsupported.

Step 3 — make replay resistance demonstrable

A single-use challenge with an absolute expiry, consumed atomically. The evidence is the consumption record, not the code.

Step 4 — state verifier impersonation resistance plainly

Origin binding is enforced by the browser before your code runs. The supporting evidence is a flat-zero rate of origin-mismatch events.

Step 5 — for AAL3, require attested hardware

Attestation verified against pinned roots, model resolved through metadata, and the outcome recorded per credential. Without it there is nothing to evidence a hardware claim with.

Step 6 — write the evidence queries alongside the controls

One query per property, producing the records that substantiate it. Written during build, they take hours; reconstructed under assessment, they take weeks.

Evidence for an assurance claim Each property in a level maps to a field you check and a record you keep. Four boxes per property, and the fourth is the one that gets audited property from the guidance field UV flag, origin, attestation check where it runs record what your logs hold A claim without the fourth box is a claim you can make but not demonstrate, which is the distinction an assessment turns on.

Verification and Testing

Run each evidence query against a test account and confirm it returns what an assessor would need: which credential, which verification result, which ceremony time, and which enrolment policy outcome. A query that returns a row but not the field the control depends on is not yet evidence.

Assert the negative case in your test suite: a ceremony without user verification must be refused at whichever action carries the requirement, and the refusal must be recorded with a reason code. That test is what proves the control is enforced rather than intended.

For an AAL3 claim, assert that a credential with no verified attestation cannot satisfy the higher-assurance actions. This is the check that most often turns out to be missing, because the enrolment policy records the outcome and nothing downstream reads it.

Pitfalls

1. A single global assurance level. Produces friction everywhere and protection nowhere in particular.

2. Claiming AAL3 for synced credentials. Defensible only with an argument the guidance does not obviously support; better to use attested hardware where the level is genuinely required.

3. Treating the level as a property of the credential. It is a property of the ceremony and the checks around it, and the same credential can support different claims in different contexts.

Frequently Asked Questions

Does a passkey on its own meet AAL2?

Where the authenticator verified the user, the argument is straightforward: a single multi-factor authenticator combining possession of a non-exportable key with a verification the device performed. The parts that need your attention are the ones you implement — checking the flag, enforcing single-use challenges, and recording both.

Why is AAL3 harder?

Because the level is framed around hardware-based authenticators and impersonation resistance, and a synced credential’s key material is available on any device the user’s platform account reaches. The cryptography is not the issue; the boundary around the key is. Deployments that genuinely need AAL3 generally use attested hardware authenticators, where the boundary is physical and provable.

Does phishing resistance map to a level?

It is called out as a distinct property rather than as a level, and passkeys have it inherently through origin binding. It is worth stating separately in any assessment, because it is often the strongest claim available and it is easy to lose inside a level label.

What if we cannot collect attestation?

Then you cannot evidence a hardware-protection claim, and the honest position is that the deployment supports the levels that do not require one. Attempting an AAL3 claim on unattested credentials is the kind of row an assessor will pull on first.

How should re-authentication requirements be handled?

The guidance sets expectations for how frequently a claimant must re-authenticate at each level, and the recorded ceremony time is what makes that enforceable. Comparing the session’s authentication time against a per-action maximum age is the same mechanism used for step-up, so the two requirements share an implementation.

Do the backup bits matter for an assurance claim?

They describe durability rather than assurance, so they do not feature directly. Where they are useful is in identifying which credentials are device-bound, which is the population that can support a hardware-related claim without attestation being available for everybody.

How should a mixed population be described in an assessment?

Per credential rather than per account, because the levels are properties of a ceremony rather than of a person. An estate where employees hold attested hardware keys and contractors hold synced platform passkeys supports different claims for different populations, and describing it that way is both more accurate and easier to substantiate than averaging into one statement. It also makes the remediation obvious when a gap is found: the question becomes which population needs a different credential type rather than what the whole system should be re-architected into.

What is the most common finding in this area?

Evidence rather than mechanism. Deployments almost always satisfy the properties — the challenge is single-use, the origin is bound, the flag is checked — and almost as often cannot produce a record showing that any of it happened for a particular sign-in on a particular date. Writing the evidence queries during the build, and running them once against a test account, turns the most common finding into a non-issue for the cost of an afternoon.

Related