In the first part of our analysis, we introduced the newly published NIST supplement for passkeys. We broke down the changes and clarified positions regarding synced/syncable passkeys against NIST’s digital identity guidelines for authentication, commonly known as 800-63B. The supplement clarifies that synced passkeys across a “sync fabric” are allowed and can reach AAL2 assurance levels.
We continue analyzing the supplement in part 2, focusing on implementation considerations.
Passkey implementation considerations to meet AAL2
Passkeys are based on the W3C's WebAuthn specification, which establishes a standard for browsers and passkey managers/providers to handle the challenge-response cryptographic process during registration and verification (referred to as "sync fabric"). WebAuthn can be customized by a Relying Party (RP) using various flags. To meet AAL2 requirements, the RP must explicitly set certain flags.
To meet AAL2 standards the following flags will need to be set or interrogated
Passkeys - User Presence (UP)
The user presence flag during a WebAuthn ceremony is set when the user has interacted with the authenticator. With user presence, the intent is not to identify the user but to ensure that a user is physically present during authentication. The term authorization gesture is used in the official w3C WebAuthn specifications.
Implementation requirements for User Presence (UP)
💡 Federal agencies SHALL confirm that the User Present flag has been set. Supports Authentication Intent.
Passkeys - User Verification (UV)
The user verification flag on passkeys ensures that the user's identity is verified using an available “user verification” method. It seeks to ascertain that not only a user was present during authentication (User Presence) but also provides an assurance level that the same user who registered the passkey is initiating the verification. This is commonly implemented by authentication via biometrics, screen lock, or a PIN before the passkey is used. This adds an extra layer of security by requiring proof of the user's identity during the authentication process.
💡 Federal agencies SHALL indicate that UV is preferred, and all assertions SHALL be inspected to confirm the value of the UV flag. This indicates whether the authenticator can be treated as a multi-factor cryptographic authenticator. If the user is not verified, agencies may treat the authenticator as a single-factor cryptographic authenticator by adding an RP-specific memorized secret to the authentication event. A further extension to the WebAuthn Level 3 specification provides additional data on verification methods if agencies seek to gain context on the local authentication event.
Additional considerations
The above flags on user presence and user verification are prerequisites noted in the supplement for AAL2. Additionally, the following features of passkeys can be used to gain more insights during registration and verification ceremonies.
Backup eligibility
Indicates whether the authenticator can be synced to a different device
💡 Federal agencies MAY use this flag if they intend to establish policies restricting syncable authenticators. This flag is necessary to distinguish between authenticators that are device-bound or those that may be cloned to more than one device.
Backup state
Indicates whether an authenticator has been synced to a different device
💡 Federal agencies MAY use this flag if they intend to establish restrictions on authenticators that have been synced to other devices. However, due to user experience concerns, agencies SHOULD NOT change the acceptance of public-facing applications based on this flag. This flag MAY be used to support the restriction of syncable authenticators for specific enterprise decisions.
Enterprise attestation
Some authenticators support attestation features that can be used to determine the capabilities and manufacturer of a specific authenticator, for example, Yubikeys. It’s important to note that attestation data varies from authenticator to authenticator, and the use of attestation should be use case driven.
💡 For enterprise use cases, agencies SHOULD implement attestation capabilities based on the functionality offered by their platform providers. Preferably, this would be an enterprise attestation where the RP requests uniquely identifying information about the authenticator.
The NIST supplement adds further guidance for non-enterprise use cases, like large consumer-facing applications and websites. It calls out the regression back to weaker authenticator types like SMS OTP.
💡 Attestations SHOULD NOT be used for broad public-facing applications. Such a requirement (i.e., one that blocks some public users’ syncable authenticators if they do not support attestation) may divert users to less secure authentication options that are vulnerable to phishing, such as Short Message Service (SMS) one-time password (OTP).
Round up
The NIST supplement provides clarity on the implementation considerations when it comes to achieving AAL2 requirements. The key flags that are required are the user verification and user presence flags. It is refreshing to see that NIST considers it regressive when passkeys are configured to be too restrictive when used in broad public-facing applications.
Authsignal is a member of the FIDO alliance and is actively helping organizationsuplift their customer account security and experience by adopting passkeys. We offer a range of drop-in solutions that have been tuned for the consumer and have seen incredible results on nationwide demographics and critical customer services. Authsignal’s passkey implementations are tuned and can quickly assist in meeting assurance-level requirements.
.png)
.png)
.png)
