Synced Passkeys Under NIST SP 800-63B-4 - What Amazon Cognito and IAM Identity Center Let You Set

First Published: 2026-11-09
Last Updated: 2026-11-09

NIST SP 800-63B-4 addresses two distinct parties regarding syncable authenticators. Synced passkeys are a prime example of these syncable authenticators. The first party involves the infrastructure that securely stores keys and distributes them to different devices (the "sync fabric"). The NIST conformance criteria v0.1 set the Target of the requirements for this side to CSP. According to the definition in 63B-4, a CSP is the entity that registers authenticators to a user's account, and the Verifier is one of the roles of the CSP. This article interprets the requirements for this side as pertaining to the sync fabric (Inference), without determining whether the accepting organization qualifies as a CSP. The second party receives and validates authentication results, and the subjects in the main text for this party are the Verifier and agencies.

Organizations that accept passkeys within AWS fall under the second party. When using Amazon Cognito user pools or IAM Identity Center, these organizations do not configure encryption for the sync fabric or require Multi-Factor Authentication (MFA) when accessing it. These are not configurable options within Amazon Cognito or IAM Identity Center. The responsibilities of the receiving side center on two SHALL statements: requesting user verification (UV) and confirming the UV in the response, and treating an authenticator without UV as a single-factor cryptographic authenticator.

This article analyzes §3.1.7.4, the AAL3 section, and Appendix B of NIST SP 800-63B-4, and the NIST conformance criteria v0.1, separating requirements based on the responsible party, the strength of the requirement, and the Authentication Assurance Level (AAL). It then aligns these requirements with the configuration options available in Amazon Cognito user pools and IAM Identity Center. The results are categorized into three groups: configurations that directly correspond to the requirements, configurations that are visible but cannot be controlled, and configurations that are not found on the AWS side. Having a corresponding configuration is not a conformance determination. NIST does not provide certification against the conformance criteria.

This article distinguishes between what the documentation states, what is not found in the documentation, and any discrepancies between different documentation sources. The information presented in this article was verified as of November 8, 2026.

This article is not a detailed explanation of how passkeys work, nor is it a step-by-step configuration guide. Pricing information is not included.

Related articles on this site:

1. Scope and Assumptions
2. How to Read the Tables
3. What Is Final and What Is an Initial Release
4. Categorizing by Responsible Party
5. AAL Lines
6. In Amazon Cognito User Pools
7. In IAM Identity Center
8. Candidates When No Setting Matches
9. Where the Sources Disagree and What They Do Not Say
10. What This Setup Showed
11. Failure Modes
12. Frequently Asked Questions about Synced Passkeys Under NIST SP 800-63B-4
13. Summary
14. References

1. Scope and Assumptions

This chapter will first define the intended audience, the scope of this article, the relevant source materials, and the terminology used. The following twelve points will outline the conclusions.

NIST SP 800-63B-4 states that syncable authenticators SHALL NOT be used at AAL3, because syncing requires the private key to be exportable. Regarding AAL2, it states that authentication may be supported under the requirements outlined in Appendix B. The word "may" in this sentence is in lowercase, and according to the definition in 63B-4, it does not represent a normative requirement (Chapter 5).
The requirements in Appendix B, Section B.2 (such as encryption of the sync fabric, access control, and MFA equivalent to AAL2), are assigned by the conformance criteria v0.1 to the CSP. These are not settings configured by the receiving side in AWS. While Section B.2 does not explicitly mention the term "CSP," the assignment is indicated in the "Target" field of the conformance criteria (Section 4.1).
The receiving side's SHALL requirements are to indicate that UV is preferred and confirm the UV in the response (IMPR-1), and to treat the authenticator as a single-factor cryptographic authenticator if there is no UV (IMPR-2). The conformance criteria set the Target of both to Verifier (Section 4.2).
The requirement to evaluate usage patterns and determine access policies (IMPR-3) has "Agencies" as the subject in the main text, while the conformance criteria assign this to the CSP. This article treats this as a point where the sources disagree (Sources disagree) and does not definitively state it as an obligation for the receiving side (Section 4.3).
Policies that use the Backup Eligible (BE) and Backup State (BS) flags are MAY. Conditioning acceptance on the BS flag in public-facing applications is SHOULD NOT. The conformance criteria v0.1 collect SHALL statements and do not include any statements regarding BE or BS (Section 4.4).
The conformance criteria are the initial version (v0.1). On October 6, 2026, the CSRC page announced that the Implementation Resource Hub was available, and the hub includes v0.1. The metadata for OSCAL was dated September 30, 2026. On November 8, 2026, the page for Revision 4 of 800-63-4 still showed the conformance criteria as Coming Soon (Chapter 3).
In Amazon Cognito, UserVerification can be set to required or preferred. If no value is specified, it defaults to preferred. With preferred, authenticators that do not support UV may still be successfully registered and authenticated (Section 6.2).
In Amazon Cognito, setting FactorConfiguration to MULTI_FACTOR_WITH_USER_VERIFICATION ensures that passkeys with UV meet the MFA requirements. If no configuration is specified, or if SINGLE_FACTOR is selected, the passkey is considered a single authentication factor (Section 6.3).
Amazon Cognito explicitly states that it currently does not support enforcing attestation. The response from ListWebAuthnCredentials does not include BE, BS, or AAGUID. There is no operation listed in the API's operations that allows administrators to list individual user passkeys. The administrator's AdminGetUserAuthFactors operation returns whether WEB_AUTHN is available to the user (Sections 6.4 and 6.5).
IAM Identity Center accepts FIDO authenticators for MFA and notes that passkeys may be either bound to a device or syncable. No setting was found that distinguishes syncable passkeys, nor a setting that requires UV (Chapter 7).
IAM Identity Center's MFA is not compatible with external Identity Providers (IdPs). When using an external IdP, that external IdP manages the MFA configuration (Section 7.1).
In the configuration described in Chapter 10, when UserVerification is set to required, Amazon Cognito decides by the UV flag in each response. Even if a key was registered without UV, a sign-in with UV was successful. When MFA is required and FactorConfiguration is set to MULTI_FACTOR_WITH_USER_VERIFICATION, even if UserVerification remains set to preferred, the sign-in request becomes required (with one unexplained exception; Section 10.5). Setting SINGLE_FACTOR while MFA was required was rejected. All of these are single observations.

1.1 Intended Audience

This article is intended for the following audiences:

Developers designing solutions that accept passkeys, utilizing Amazon Cognito User Pools or IAM Identity Center for their company's services or internal sign-in processes.
Individuals responsible for compliance and procurement, who need to determine which requirements fall within their organization's obligations and which settings within AWS can address those requirements, particularly in relation to NIST SP 800-63B-4.
Individuals responsible for aligning internal policies or client requirements that reference AAL (Authentication Assurance Level) with appropriate AWS configurations.

This article assumes that readers are considering the following points, and each will be verified through the material presented:

NIST prohibits synced passkeys.
MFA for entering the sync fabric is configured by the receiving side.
In Amazon Cognito, the preferred setting verifies UV.
Public-facing services should look at BS and reject synced passkeys.
Compliance with version 0.1 of the conformance criteria should enable NIST certification.

1.2 What This Article Covers and What It Does Not

This article addresses the syncable authenticator requirements in NIST SP 800-63B-4 (§3.1.7.4, AAL3 section, Appendix B, sections B.2 and B.3) and their normative strength, and the relevant IDs and the status of conformance criteria v0.1. It also covers the categorization of responsible parties, the line at each AAL, the WebAuthnConfiguration (including UserVerification, FactorConfiguration, and RelyingPartyId) and response elements of ListWebAuthnCredentials within Amazon Cognito user pools, as well as the handling of attestation. Furthermore, it covers the MFA configuration options within IAM Identity Center and limitations related to external Identity Providers (IdPs).

This article does not address the following.

The registration and authentication flow for WebAuthn, the meaning of the bits for UP, UV, BE, and BS, the fact that BE is determined at creation and remains unchanged, while BS can change, a general discussion on whether to validate attestation, and account recovery design. This site's Passkeys and WebAuthn in Practice covers this topic. This article does not compare the strengths and weaknesses of synced passkeys and device-bound passkeys.
The timeframe for token lifetime and re-authentication. This site's NIST IR 8587 Mapped to AWS Controls covers this.
The steps for configuring IAM Identity Center. This site's AWS IAM Identity Center Complete Setup Guide covers this.
Amazon Cognito's feature plans and managed login. This site's Amazon Cognito Federation Complete Implementation Guide covers this.
When Amazon Cognito passkeys became available. This site's AWS History and Timeline regarding Amazon Cognito covers this.
NIST SP 800-63A (identity proofing) and SP 800-63C (federation), federal procurement and FedRAMP procedures, comparison with other Identity Providers (IdPs), and pricing.
MFA for IAM root users and IAM users. The IAM passkey page states that AWS supports both synced passkeys and device-bound passkeys, but IAM is a different service from the IAM Identity Center covered in this article.
Topics covered in other articles in the same series. An article covering the type of sub in OpenID Connect and the AWS receivers that use it as a key is When sub Changes on Every Sign-In. An article covering the history of OAuth standards is OAuth Standards History and Timeline.

1.3 Date of Review and Materials Reviewed

This article was written after reviewing the following materials on November 8, 2026. The body text uses the English names given in parentheses.

Reviewed the main content of NIST SP 800-63B-4 (63B-4 text), including the AAL3 section, §3.1.7.4, Appendix B, the Notations section, and the Change Log.
The page containing only Appendix B of NIST SP 800-63B-4 (Appendix B page).
The NIST SP 800-63 Revision 4 resource hub (Implementation Resource Hub).
The criteria page for the Implementation Resource Hub (criteria page).
The OSCAL JSON for the Implementation Resource Hub, version 0.1 (OSCAL catalog).
The authenticator examples page (authenticator examples page) and the FAQ page (hub FAQ) for the Implementation Resource Hub.
The Revision 4 page on pages.nist.gov (Revision 4 page).
The CSRC page for NIST SP 800-63B-4 (CSRC page).
The W3C Web Authentication Level 3 recommendation (WebAuthn Level 3).
The authentication flows page in the Amazon Cognito Developer Guide (authentication flows page). Reviewed the section on passkeys.
Reviewed the following pages in the Amazon Cognito User Pools API Reference: WebAuthnConfigurationType, SetUserPoolMfaConfig, GetUserPoolMfaConfig, ListWebAuthnCredentials, WebAuthnCredentialDescription, SetUserMFAPreference, WebAuthnMfaSettingsType, and AdminGetUserAuthFactors, as well as the list of operations (actions list). In the main text, these are referenced along with the names of operations and data types.
Reviewed the following pages in the AWS IAM Identity Center User Guide: MFA types (MFA types page), configure MFA (configure MFA page), directory user MFA (directory MFA page), prompt users for MFA (prompt users page), choose MFA types (choose MFA types page), and device enforcement (device enforcement page).
The Identity Center features page for AWS (Identity Center features page).
The page on assigning passkeys in the AWS Identity and Access Management User Guide (IAM passkey page).

The AWS pages do not use NIST's AAL terms (in the copies of the AWS pages in Section 1.3, the term AAL appeared zero times). This article presents a comparison of AWS configurations and NIST documentation; it does not reflect the content of the AWS pages themselves.

1.4 Terms, and Different Things with the Same Spelling

This article will consistently use the following terms:

Syncable Authenticator: A term used by NIST, referring to a cryptographic authenticator that can replicate its security credentials to another device. Section 3.1.7.4 of the 63B-4 text states that replication typically occurs through a "sync fabric."
Synced Passkey: A passkey that is a representative example of a syncable authenticator. This is the term used in the title of this article.
Device-bound passkey: A passkey that does not allow its key to be extracted to a device outside of the one it was created on. This term is used on the IAM Identity Center MFA types page.
Sync Fabric: A term used by NIST, referring to a mechanism that stores authentication keys in the cloud and distributes them to other devices. This term will be used in this article without translation.
CSP (Credential Service Provider): A term used by NIST, referring to the entity that manages and associates authenticators with users. In this article, it appears as a value in the "Target" field of the conformance criteria v0.1.
Verifier: A term used by NIST, referring to the entity that validates the output of an authenticator. This article uses the same spelling as the "Target" field value in conformance criteria v0.1.
RP (Relying Party): The entity that relies on the result of authentication. This is also a term used in WebAuthn. Section B.3 discusses federal agencies acting as RPs.
Agencies: The subject of the sentence in the NIST documents. While this article considers organizations that adhere to NIST standards, regardless of whether they are federal agencies, the original subject of the sentence in the NIST documents will not be altered.
Receiving side: A term used in this article, not a term from the sources. It refers to the entity that accepts passkeys and validates the results of authentication. It corresponds to NIST's Verifier and RP.
UV, UP, BE, BS: Flags within WebAuthn that represent authenticator data. They stand for User Verified, User Present, Backup Eligible, and Backup State. The meaning of these flags is explained in Chapters 5 and 6 of Passkeys and WebAuthn in Practice.
Single-factor cryptographic authenticator and multi-factor cryptographic authenticator: Terms used by NIST. This article uses them for the distinction that an authenticator with UV can be treated as multi-factor.
Conformance Criteria: A document in the Implementation Resource Hub that compiles the requirements of SP 800-63-4. In this article, it refers specifically to version v0.1.

BE indicates whether the credential can be synced, and BS indicates whether it has been synced. This article does not combine them into a single term and uses the spellings BE and BS.

2. How to Read the Tables

This chapter defines the columns in the tables presented in this article, as well as the way to describe the state of the sources, and how this article writes normative terms. The columns of the summary table in Chapter 8 are used consistently across three articles in the same series.

2.1 Table Columns

The summary table in Section 8.4 has the following seven columns:

Requirement or Behavior: The requirement (a NIST statement) or the behavior of an AWS service in the row.
Who Must Act (Spec): The entity responsible for fulfilling the requirement. This article lists the subject of the NIST text. If the Target field in the conformance criteria v0.1 differs from the subject of the NIST text, both are listed.
AWS Receiver: The AWS service involved in the row. For rows that are not settings on the receiving side in AWS, this column has —.
What You Can Set: The configuration or value that corresponds to the requirement. The existence of a corresponding configuration does not constitute a determination of conformance.
What You Cannot Set: Configurations explicitly stated as not supported in the documentation, and configurations for which descriptions are not found. The cell states which one it is, with the terms in Section 2.2.
Where It Is Written: The source of the information in the row.
Source State: The state of the documentation, written with the terms in Section 2.2.

The tables in Sections 4.6 (table of responsible parties), 5.5 (table by AAL level), 6.7 (table for Amazon Cognito), and 7.6 (table for IAM Identity Center) use columns specific to this article. Each section explains its columns.

2.2 Terms for the State of the Sources

This article uses eight terms to describe the state of the documentation. The tables also use these English terms.

Stated: The documentation contains a statement regarding the matter.
Stated as not supported: The documentation explicitly states that the matter is not supported or cannot be used.
Documentation does not list: While a list or table exists, the specific item is not included. This does not necessarily indicate that the matter is unsupported or unavailable.
Not recorded (stated): The documentation states that the information is not included in logs or records.
No statement found: Despite searching using different search terms and examining different categories of documentation (as described in Section 1.3), no relevant statement could be found. This does not necessarily indicate that the matter is absent or does not occur.
Sources disagree: The documentation from two different sources provides conflicting statements regarding the same matter. This includes cases where the statements directly contradict each other, as well as cases where the scope, strength, or subject matter differs, and the text does not settle which one applies. This article presents both statements and their sources without designating either as incorrect.
Inference: This is an inference made by this article, and is not a statement found in any of the documentation. This article says in the same sentence that it is an inference.
Observation: This is based on observations made during testing (as described in Chapter 10) and is not a commitment made by the documentation. This article will not override statements found in the documentation with observations.

This article distinguishes between "Stated as not supported" and "No statement found." The former refers to a statement in the documentation, while the latter indicates that this article was unable to find a relevant statement.

2.3 How This Article Writes Normative Terms

The Notations section of the 63B-4 text defines normative terms as follows.

Specific terms in CAPITALS represent normative requirements. When these same terms are not in CAPITALS, the term does not represent a normative requirement.

This article will retain the original capitalization of the terms SHALL, SHALL NOT, SHOULD, SHOULD NOT, and MAY, without translation. When rephrasing requirements, the original terms will be included in parentheses. Terms such as "should" or "may" written in lowercase in the original text will not be treated as normative terms and will be retained in their original lowercase form.

This article will indicate in the same sentence which page each statement comes from. Even when discussing the same subject matter, statements from the 63B-4 text will be treated separately from those in conformance criteria v0.1. Statements in the OSCAL catalog of the conformance criteria may have different phrasing than those in the 63B-4 text (see Section 9.1). This article quotes the 63B-4 text, simply adding the corresponding ID from the conformance criteria.

3. What Is Final and What Is an Initial Release

This chapter distinguishes between the finalized versions and initial releases of the NIST documents referenced in this article.

3.1 SP 800-63B-4 and Appendix B

According to the CSRC page, SP 800-63B-4 was published in July 2025, replacing the version of SP 800-63B dated March 2, 2020. The Change Log for SP 800-63B-4 states the following regarding syncable authenticators.

Section 3.1.7.4 and Appendix B: Adds requirements for syncable authenticators

Appendix B is the appendix on syncable authenticators, and it opens with the following sentence. The Appendix B page has the same sentence.

This appendix is normative.

The passage from Appendix B referenced in this article consists of normative text in the appendix. Section B.2 addresses the cloning of authentication keys, while Section B.3 outlines implementation requirements.

3.2 Conformance Criteria v0.1

The criteria page describes the version of the conformance criteria as follows:

This page provides an initial release, version 0.1, of the conformance criteria for NIST Special Publication 800-63-4 Digital Identity Guidelines.

The same page states that NIST does not provide certification for the conformance criteria, as follows:

NIST does not conduct certification or conformity assessment against these criteria.

The conformance criteria collect normative requirements and control measures. The criteria page states that it includes SHOULD and MAY statements only in the following cases.

Recommendations (SHOULD statements) and implementation options (MAY statements) are only included where they result in further normative requirements resulting from the selection of a recommended or optional control.

In the OSCAL catalog metadata, version is 0.1 and last-modified is 2026-09-30T13:10:04Z. A Planning Note from the CSRC page, dated October 6, 2026, announces that the Implementation Resource Hub is available.

The Implementation Resource Hub for SP 800-63-4 is now available!

This announcement does not explicitly name the conformance criteria. This article does not state that October 6, 2026, is the publication date for the conformance criteria. Instead, this article describes a situation where, on October 6, 2026, the CSRC page announced the publication of a hub, and that hub contains version 0.1. There are two dates to consider: the date in the OSCAL metadata and the date of the hub announcement.

Version 0.1 is the initial release, and this article does not treat it as a final version. The IDs for the conformance criteria (e.g., CAK-5, IMPR-1) refer to the IDs for version 0.1.

3.3 Display of Two Hubs

In addition to the Implementation Resource Hub, the pages.nist.gov website also features a Revision 4 page. This page still shows the conformance criteria as Coming Soon on November 8, 2026, and states that implementation materials will be released shortly. This article uses the Implementation Resource Hub, which has conformance criteria v0.1, as the source, and lists the display on the Revision 4 page as a point where the sources disagree in Section 9.1.

3.4 WebAuthn Level 3

B.3 states the following as a preface to the flag requirements:

The following requirements apply to WebAuthn Level 3 flags:

W3C's WebAuthn Level 3 was published as a W3C Recommendation on August 25, 2026. This article treats WebAuthn Level 3 as the current recommendation and refers to it at /TR/webauthn-3/. The definitions of the BE and BS flags are found in WebAuthn Level 3, and this article delegates the explanation of those definitions to Passkeys and WebAuthn in Practice.

4. Categorizing by Responsible Party

This chapter categorizes the requirements outlined in Appendix B based on who is responsible for fulfilling them. Figure 1 illustrates this categorization.

4.1 Sync Fabric Requirements

Section B.2 addresses requirements related to key generation, storage in the sync fabric, private-key operations on devices, access to the sync fabric, documentation, and user interfaces. For example, the text regarding Multi-Factor Authentication (MFA) when entering the sync fabric reads:

User access to authentication keys in the sync fabric SHALL be protected by AAL2-equivalent MFA

The subject of this statement refers to a user's access to a key in the sync fabric. The subject matter in the main body of Section B.2 includes keys, authentication transactions, user access, requirements, authenticators, and devices. The term CSP does not appear in the main body of Section B.2. The association with CSP is defined in the Target field of conformance criteria v0.1. In the OSCAL catalog, the Targets for CAK-1 through CAK-5 and CAK-7 through CAK-10 are designated as "CSP," while the Target for CAK-6 is designated as "CSP/Verifier."

The AAL2-equivalent MFA for CAK-5 is the strength of authentication required when entering the sync fabric. It is not the AAL of the receiving application. Organizations using services like Amazon Cognito User Pools or IAM Identity Center do not configure MFA for users entering the users' sync fabric. As an inference of this article (Inference), what the receiving side can do about CAK-5 lies not in settings, but in the policy on which sync fabric keys to accept (see Section 4.3).

CAK-6 requires that the requirements for using syncable authenticators be documented and communicated (SHALL). The Target is "CSP/Verifier," and of CAK-1 through CAK-10, only CAK-6 is also associated with the receiving side.

CAK-7 states that authenticators SHOULD provide a screen where users can view their syncable keys, and that the screen SHALL NOT display the key itself. CAK-7 includes a SHOULD statement, but it is included in the conformance criteria because of the SHALL NOT part (Inference).

CAK-8 through CAK-10 define requirements for federal enterprise authentication keys. The guidance in the OSCAL catalog indicates that these three requirements are specifically applicable to federal enterprise use cases.

4.2 Requirements on the Receiving Side

B.3 describes how to handle WebAuthn flags. The UV statement is as follows:

Verifiers SHALL indicate that UV is preferred and SHALL inspect responses to confirm the value of the UV flag.

This statement contains two "SHALL" requirements. The first is to indicate that UV is preferred, and the second is to examine the response and verify the value of the UV flag. In conformance criteria v0.1, under IMPR-1 (B.3 A), the Target is the Verifier.

The following sentence in the same paragraph describes how to handle the case where there is no UV.

If the user is not verified, agencies SHALL treat the authenticator as a single-factor cryptographic authenticator.

The subject of this statement is "agencies." In conformance criteria v0.1, under IMPR-2 (B.3 B), the Target is the Verifier. While the subject and Target in this statement differ, both refer to the receiving side; therefore, this article does not consider this a discrepancy.

Regarding the UV flag, B.3 states that it indicates whether the authenticator can be treated as a multi-factor cryptographic authenticator. With a UV, the authenticator can be treated as multi-factor; without one, it is treated as single-factor, and this distinction connects to the AAL levels described in Chapter 5.

4.3 A Requirement with Conflicting Assignments

The latter part of Section B.3 describes a process for determining policy based on flag and attestation information.

Agencies SHALL evaluate the use cases for syncable authenticators and determine the appropriate access policy decisions that they intend to make based on the returned information.

The subject of this sentence is "Agencies." In conformance criteria v0.1, this requirement (IMPR-3, B.3 C) is assigned to CSP. However, the text of B.3 is written for agencies acting as RPs, while the conformance criteria assign this requirement to CSP. Because the text does not settle which applies, this article treats this as a point where the sources disagree (Sources disagree). This article does not definitively state that this requirement is an obligation for the receiving organization, nor does it definitively state that it is an obligation for CSP.

As an inference of this article (Inference), when the receiving organization determines this policy, the configuration of Amazon Cognito and IAM Identity Center would serve as input for that policy, but it is not the policy itself.

4.4 SHOULD and MAY Statements

In addition to SHALL statements, B.3 has statements using SHOULD, SHOULD NOT, and MAY. The UP statement uses SHOULD.

Verifiers SHOULD confirm that the User Present flag has been set.

The BE statement uses MAY.

Verifiers MAY use this flag to establish policies that restrict the use of syncable authenticators.

The BS statements follow MAY with SHOULD NOT.

Verifiers MAY use this flag to establish restrictions on authenticators that are synced to other devices.

Agencies SHOULD NOT condition acceptance based on this flag for public-facing applications due to user experience concerns.

Setting restrictions with BS is MAY for the Verifier. However, in public-facing applications, agencies SHOULD NOT condition acceptance on BS. The term SHOULD NOT, as defined in the Notations section of the 63B-4 text, indicates that something is discouraged but not prohibited.

Regarding attestation, Section B.3 has three statements.

For federal enterprise use cases, agencies SHOULD implement attestation capabilities based on the functionality offered by their platform providers.

RPs SHOULD use attestation to determine the level of confidence they have in a syncable authenticator when attestations are available.

The unavailability of attestations SHOULD NOT block the use of syncable authenticators for broad public-facing applications.

The first is SHOULD for federal enterprise use cases. The second is SHOULD for situations where attestation can be utilized. The third is that in broad public-facing applications, the unavailability of attestations should not prevent the use of syncable authenticators (SHOULD NOT). This article places the description of Amazon Cognito attestation from Section 6.4 in the same row of the table, together with these three statements.

The v0.1 conformance criteria have no statements of their own on UP, BE, BS, and attestation; IMPR-3 mentions flags and attestation only as the basis for policy decisions (Section 9.1). The OSCAL catalog contains zero entries for the terms "Backup Eligible," "Backup State," and "User Present." As described on the criteria page, v0.1 collects SHALL statements, while the statements on these items in the 63B-4 text are categorized as either SHOULD or MAY. B.2 also has two SHOULD statements that are not in v0.1: the keys SHOULD be encrypted using a method that employs a user-controlled secret, and, for federal enterprise use, authenticators that generate authentication keys SHOULD support attestation features.

4.5 Scope of the Statements

The introductory sentence of B.3 states its audience as follows:

federal agencies acting as RPs should understand and interrogate

The word "should" is written in lowercase, and in the definition of the 63B-4 text, it does not represent a normative requirement. Instead, the introductory sentence in B.3 describes the flags that federal agencies, acting as RPs, should understand and investigate as part of implementing solutions that align with the AAL2 guidelines. The subjects of the individual requirements are Verifiers and agencies.

This article is intended for RPs that use NIST as a benchmark, but it does not state that organizations that are not federal agencies have NIST obligations. The reasons why non-federal organizations might utilize NIST requirements are determined by their own regulations and contracts.

4.6 Table of Responsible Parties

The following table lists the requirements for syncable authenticators, aligning them with the subjects in the 63B-4 text, the Targets in conformance criteria v0.1, and categorized by the strength of the norm. A "—" in the Criteria ID column indicates that the criterion is not included in conformance criteria v0.1.

Requirement	Subject in the 63B-4 Text	Target in Criteria v0.1	Strength	Scope	Criteria ID
Generate keys using an approved cryptographic method.	keys	`CSP`	SHALL	Syncable authenticators	CAK-1
Store keys in the sync fabric only in an encrypted format.	keys	`CSP`	SHALL	Syncable authenticators	CAK-2
Perform private-key operations on the device.	Authentication transaction	`CSP`	SHALL	Syncable authenticators	CAK-3
Protect keys in the sync fabric with access control.	keys	`CSP`	SHALL	Syncable authenticators	CAK-4
Protect access to keys in the sync fabric with MFA equivalent to AAL2.	User access	`CSP`	SHALL	Syncable authenticators	CAK-5
Document and communicate requirements.	Requirements	`CSP/Verifier`	SHALL	Syncable authenticators	CAK-6
Provide a screen that allows visibility of syncable keys, but do not display the keys themselves.	Authenticator, screen	`CSP`	SHOULD, SHALL NOT	Syncable authenticators	CAK-7
Sync fabrics for federal enterprise keys, device management, and agency-managed accounts.	Keys, device, access	`CSP`	SHALL	Federal enterprise use only	CAK-8 to CAK-10
Indicate UV as preferred and verify the response UV.	Verifiers	`Verifier`	SHALL	WebAuthn Level 3 flags	IMPR-1
If UV is unavailable, treat as single-factor cryptographic authenticator.	agencies	`Verifier`	SHALL	WebAuthn Level 3 flags	IMPR-2
Evaluate usage and establish access policies.	Agencies	`CSP`	SHALL	Syncable authenticators	IMPR-3
Verify that UP is set.	Verifiers	—	SHOULD	WebAuthn Level 3 flags	—
Establish a policy to restrict the use of syncable authenticators using BE.	Verifiers	—	MAY	WebAuthn Level 3 flags	—
Apply restrictions using BS. Do not condition acceptance on BS in public-facing applications.	Verifiers, Agencies	—	MAY, SHOULD NOT	WebAuthn Level 3 flags	—
Utilize attestation (federal enterprise use cases; RPs when available). Do not prevent usage due to the unavailability of attestations in broad public-facing applications.	agencies, RPs	—	SHOULD, SHOULD NOT	Attestation	—
Do not use syncable authenticators at AAL3.	Syncable authenticators	`CSP`	SHALL NOT	AAL3	AAL3AVR-7

In the IMPR-3 row of this table, the subject in the text and the Target disagree (Section 4.3). This table does not indicate which rows apply to each organization.

5. AAL Lines

This chapter describes how syncable authenticators are handled on a per-AAL basis. The timeframes for each AAL (the re-authentication interval) are addressed in this site's NIST IR 8587 Mapped to AWS Controls.

5.1 AAL3

The AAL3 section of the 63B-4 text states that the AAL3 cryptographic authenticator requires a hardware-protected, isolated environment, and continues as follows:

syncable authenticators SHALL NOT be used at AAL3.

The first part of the same sentence explains that syncable authenticators require the private key to be exportable. The end of Section B.2 states that similar protocols that store keys in a non-exportable manner and meet the other AAL3 requirements may be used. The word "may" in this sentence is presented in lowercase. The AAL3 section also states that the AAL3 cryptographic authenticator must (SHALL) have a non-exportable private key. In conformance criteria v0.1, the prohibition related to AAL3 is specified in AAL3AVR-7 (2.3.2 H), with the Target being CSP. The OSCAL catalog describes the evaluation method as follows: this requirement is met by authenticators that comply with AAL3AVR-3 (non-exportable keys). AAL3AVR-7 is not one of the sync fabric requirements in B.2; it concerns which authenticators are used at AAL3. Whether the accepting organization qualifies as a CSP for this requirement is not determined in this article (Chapter 1).

5.2 AAL2

Appendix B, Section B.2, concludes with the following regarding AAL2 and AAL3:

Authentication at AAL2 may be supported subject to the above requirements. However, syncing violates the non-exportability requirements of AAL3.

In this sentence, "may" is in lowercase. This article treats this sentence not as "MAY," but rather as an explanation that authentication in AAL2 can be supported under the requirements outlined in Section B.2.

The section on AAL2 in the 63B-4 text states that AAL2 authentication must utilize either a multi-factor authenticator or a combination of two distinct authentication factors (SHALL). An example of a multi-factor authenticator is a multi-factor cryptographic authenticator. When combining two single-factor authenticators, one must be a physical authenticator and the other must be a password or biometric comparison (SHALL). Examples of physical authenticators include single-factor cryptographic authentication.

According to IMPR-2, syncable authenticators without user verification (UV) are treated as single-factor cryptographic authenticators. The Example in Appendix B states that, without user verification, the verifier prompts for an additional authentication factor as part of the transaction. As an inference of this article (Inference), to use UV-less passkeys in AAL2, they must be paired in a configuration that aligns with the combination outlined in the AAL2 section (a physical authenticator and a password or biometric comparison). The table on the authenticator examples page lists UV-less passkeys (Passkeys without user verification) as an example of a single-factor cryptographic authenticator, and lists FIDO2 passkeys with user verification as an example of a multi-factor cryptographic authenticator.

5.3 AAL1

The AAL1 section of the 63B-4 text defines the authentication types that can be used within AAL1, including single-factor and multi-factor cryptographic authentication. Appendix B, within what this article read, contains no statement regarding syncable authenticators at AAL1 (No statement found). As an inference of this article (Inference), no restriction on the use of syncable authenticators within AAL1 was found in the NIST pages in Section 1.3.

5.4 MFA Equivalent to AAL2 Is Not the AAL of the Receiving Side

The MFA equivalent to AAL2 in CAK-5 functions as authentication when entering the sync fabric (see Section 4.1). It is a different matter from an application authenticating using AAL2. This article does not place the AAL2 used by CAK-5 and the AAL2 described in Section 5.2 in the same column of the same table.

5.5 Table by AAL Level

The following table lists, for each AAL level, the handling of syncable authenticators and scenarios without UV, as well as the Amazon Cognito and IAM Identity Center settings involved. Details regarding these settings are provided in Chapters 6 and 7. This table does not specify which settings satisfy which AAL levels. Figure 2 arranges the NIST statements by AAL and adds the related Amazon Cognito settings and the items not tied to an AAL.

AAL	Syncable Authenticator	Without UV	Amazon Cognito Settings Involved	IAM Identity Center Settings Involved	Source State
AAL1	Authentication types at AAL1 include single-factor and multi-factor cryptographic authentication. No AAL1 statement was found in Appendix B.	Treated as single-factor cryptographic authenticator (IMPR-2)	`UserVerification`, `FactorConfiguration`	MFA type, frequency of MFA requests	Stated (AAL1 types), No statement found (syncable authenticators at AAL1)
AAL2	May be supported based on the requirements outlined in B.2 (lowercase "may").	Treated as single-factor cryptographic authenticator and placed in the AAL2 combination form (Inference).	`UserVerification` set to `required`, `FactorConfiguration` set to `MULTI_FACTOR_WITH_USER_VERIFICATION`	MFA type, frequency of MFA requests, MFA device enforcement	Stated (NIST text), Inference (combination format)
AAL3	SHALL NOT be used.	—	No settings found that only accept device-bound passkeys.	No settings found that only accept device-bound passkeys.	Stated (NIST text), No statement found (AWS settings)

6. In Amazon Cognito User Pools

This chapter aligns the configuration and behavior of Amazon Cognito User Pools for passkeys with the requirements outlined in Chapter 4.

6.1 Prerequisites

According to the authentication flows page, passkeys are an opt-in feature, and are available with all feature plans except for the Lite plan. They are only supported through the choice-based authentication flow. When using managed login, Amazon Cognito handles the passkey authentication process, and applications can authenticate users from their backend using the AWS SDK and Amazon Cognito user pool APIs.

According to the same page, Amazon Cognito supports passkeys created using ES256 (-7) and RS256 (-257) algorithms. By default, users can set up any type of authenticator, such as hardware tokens, smartphones, or software authenticator apps. A user can register up to 20 passkeys, and they must sign in to the user pool at least once before they can register a passkey.

6.2 `UserVerification`

According to the WebAuthnConfigurationType page, the value of UserVerification can be either required or preferred. When set to required, users can only register and sign in using passkeys that support the User Verification (UV) feature. When set to preferred, the user pool does not require authenticators with UV, but encourages their use.

According to the authentication flows page, if a value is not specified in the API request, it defaults to preferred, and the Amazon Cognito console also selects preferred as the default. The same page describes the behavior when preferred is selected as follows:

When you set user verification to preferred, users can set up authenticators that don't have the user verification capability, and registration and authentication operations can succeed without user verification.

The setting that corresponds to the first requirement (SHALL) of IMPR-1 (indicating UV is preferred) is UserVerification. As an inference of this article (Inference), both preferred and required are values that tell the authenticator that UV is wanted, but no statement was found in the pages in Section 1.3 about what value Amazon Cognito puts in its request to the authenticator (No statement found). In the Chapter 10 setup, the userVerification in registration and sign-in requests was the same as the value of UserVerification (Observation).

Regarding the second requirement (SHALL) of IMPR-1 (verifying UV in the response), when set to required, users can only register and sign in using passkeys that support the User Verification (UV) feature. As an inference of this article (Inference), this would mean that Amazon Cognito examines the UV in the response when required is selected. However, no statement was found describing which flags Amazon Cognito examines in the response (No statement found). Furthermore, no API elements were found that return the results of UV verification for each sign-in to the receiving application (No statement found).

6.3 `FactorConfiguration`

According to the WebAuthnConfigurationType page, FactorConfiguration determines whether passkeys can be used as a multi-factor authentication (MFA) method. The possible values are SINGLE_FACTOR and MULTI_FACTOR_WITH_USER_VERIFICATION. When set to MULTI_FACTOR_WITH_USER_VERIFICATION, authentication using a passkey with user verification (UV) satisfies the MFA requirements. When set to SINGLE_FACTOR or when no configuration is specified, the passkey is considered a single authentication factor. This setting can only be enabled if the user pool is in the Essentials feature plan or higher.

The setting that corresponds to IMPR-2 (single factor when UV is not available) is FactorConfiguration. This article interprets the text on the page to mean that even when set to MULTI_FACTOR_WITH_USER_VERIFICATION, only authentication using a passkey with user verification satisfies the MFA requirements; authentication using a passkey without user verification does not.

The authentication flows page describes the relationship between passkeys and passwords as follows:

However, passkeys with user verification can satisfy MFA requirements as first-factor when you configure FactorConfiguration as MULTI_FACTOR_WITH_USER_VERIFICATION in your user pool WebAuthnConfiguration. Passkeys cannot be used as a second factor to password sign-in.

In contrast, the AdminGetUserAuthFactors page states that WEB_AUTHN can be used as either the first authentication factor or as an MFA factor, but that it can only be used as an MFA factor if passkey MFA is enabled in the user pool. The authentication flows page states that it cannot be used as the second factor for password sign-in. The two statements differ in scope. The WebAuthnMfaSettingsType page states that passkey MFA applies only when passkey is the first authentication factor, which matches the authentication flows page, but the AdminGetUserAuthFactors page does not itself define what it means by an MFA factor. Because the scope differs, this article treats this as a point where the sources disagree under the definition in Section 2.2 (Sources disagree) (see Section 9.1). In the Chapter 10 setup, Amazon Cognito rejected setting FactorConfiguration to SINGLE_FACTOR while MFA was required (Observation).

The pages in Section 1.3 do not settle whether Amazon Cognito settings can place passkeys without user verification in the AAL2 combination form (a physical authenticator and a password) (No statement found).

User-specific settings are also available. According to the WebAuthnMfaSettingsType page, enabling passkey MFA for a user requires user verification for passkey authentication and allows them to sign in with a passkey when MFA is required. To prevent lockouts, users must also enable at least one other MFA method, such as SMS, TOTP, or email. This type is a field in the requests for SetUserMFAPreference and AdminSetUserMFAPreference. According to the SetUserMFAPreference page, to enable passkey MFA for a user, the user pool's FactorConfiguration must be set to MULTI_FACTOR_WITH_USER_VERIFICATION.

6.4 Attestation

The authentication flows page describes attestation as follows:

Amazon Cognito doesn't currently support attestation enforcement.

This statement says that attestation enforcement is not supported. This article does not state that Amazon Cognito does not receive attestation. No statement regarding whether it receives attestation could be found (No statement found). In the Chapter 10 setup, the registration request had no attestation item (Observation).

When compared to the three sentences regarding attestation in Section 4.4, the NIST requirements use "SHOULD" and "SHOULD NOT," rather than "SHALL." Specifically, for broad public-facing applications, the unavailability of attestations should not prevent the use of syncable authenticators (SHOULD NOT). This article does not describe Amazon Cognito's attestation statement as a deficiency that fails to meet NIST requirements. For organizations that intend to use attestation for federal enterprise use cases, the absence of an option to enforce attestation within Amazon Cognito's configuration is a relevant factor.

6.5 `ListWebAuthnCredentials` Response

ListWebAuthnCredentials is an operation that lists the passkeys registered by a user. According to the WebAuthnCredentialDescription page, each item in the response consists of six elements: AuthenticatorAttachment, AuthenticatorTransports, CreatedAt, CredentialId, FriendlyCredentialName, and RelyingPartyId. BE, BS, and AAGUID items are not listed (Documentation does not list).

This article does not state that Amazon Cognito does not read BE or BS. No statement was found regarding whether Amazon Cognito reads BE or BS internally (No statement found). This article can only state that the response from the API does not include BE or BS fields.

The ListWebAuthnCredentials page describes the authorization required for this operation as follows:

Authorize this action with a signed-in user's access token.

According to the same page, the access token requires the aws.cognito.signin.user.admin scope, and Amazon Cognito does not evaluate IAM policies when processing requests for this operation. ListWebAuthnCredentials is an operation that can be called using the user's own access token. Among the operations in the actions list, those with "WebAuthn" or "MFA" in their names are: AdminSetUserMFAPreference, CompleteWebAuthnRegistration, DeleteWebAuthnCredential, GetUserPoolMfaConfig, ListWebAuthnCredentials, SetUserMFAPreference, SetUserPoolMfaConfig, and StartWebAuthnRegistration. Operations that allow administrators to list a user's passkeys one by one are not listed in the actions list (Documentation does not list).

The administrator has access to the AdminGetUserAuthFactors operation. This operation is authorized using IAM credentials and returns the types of authentication methods a user can use for USER_AUTH sign-in. An example of the response is ["PASSWORD", "WEB_AUTHN"]. The response fields include ConfiguredUserAuthFactors, PreferredMfaSetting, UserMFASettingList, and Username. Items for each passkey are not listed (Documentation does not list). This article does not state that user pool administrators have no way to verify passkeys.

6.6 `RelyingPartyId`

According to the WebAuthnConfigurationType page, RelyingPartyId must be between 1 and 127 characters and is the authentication domain used as the RP (Relying Party) for passkeys. For user pools that have a custom domain and authenticate users through managed login or the classic hosted UI, the RP ID must be the fully qualified domain name (FQDN) of the custom domain. As stated in the authentication flows page, the RP ID can also be any domain name not included in the public suffix list. If the RP ID is changed, users will need to re-register with the new RP ID. Since the RP ID does not correspond to a row of the NIST syncable authenticator requirements, it will not be included in the summary table in Section 8.4. The design of the RP ID is discussed in Passkeys and WebAuthn in Practice.

6.7 Amazon Cognito Table

The following table aligns Amazon Cognito settings and responses with NIST statements. The Related 63B-4 Text column indicates the NIST statement relevant to that setting.

Setting or Response	Values	Default	Related 63B-4 Text	Source State
`UserVerification`	`required`, `preferred`	`preferred` (API and console)	IMPR-1	Stated
`FactorConfiguration`	`SINGLE_FACTOR`, `MULTI_FACTOR_WITH_USER_VERIFICATION`	Single authentication factor if not configured	IMPR-2, AAL2 section	Stated
Per-user passkey MFA	Enabled, Disabled	—	IMPR-2	Stated
Attestation enforcement	—	—	Three statements regarding attestation in B.3	Stated as not supported
Restrictions based on BE and BS	—	—	Statements regarding BE and BS in B.3 (MAY, SHOULD NOT)	No statement found
Allowing and rejecting by AAGUID	—	—	—	No statement found
BE, BS, and AAGUID in the response of `ListWebAuthnCredentials`	—	—	—	Documentation does not list
Operation for an administrator to list passkeys one by one	—	—	—	Documentation does not list
Response of `AdminGetUserAuthFactors`	Authentication types including `WEB_AUTHN`	—	—	Stated
Whether passkeys can be used as an MFA factor	—	—	AAL2 section	Sources disagree
Configuration to accept only device-bound passkeys	—	—	AAL3 section	No statement found

7. In IAM Identity Center

This chapter aligns the MFA (Multi-Factor Authentication) configuration within IAM Identity Center with the requirements outlined in Chapter 4.

7.1 Identity Sources That Can Use the MFA Settings

According to the configure MFA page, MFA for IAM Identity Center can be configured when the identity source is the IAM Identity Center identity store, AWS Managed Microsoft AD, or AD Connector. The same page states the following regarding external identity providers:

MFA in IAM Identity Center is currently not supported for external identity providers

According to the note on the prompt users page, when using an external identity provider, the MFA section will not be displayed, and the external identity provider, not IAM Identity Center, manages MFA configuration. The Identity Center features page states that when using a compatible SAML 2.0 identity provider as the identity source, you can enable the identity provider's MFA functionality. The settings in this chapter do not apply to organizations using external identity providers.

7.2 MFA Types

According to the MFA types page, IAM Identity Center's MFA supports FIDO2 authenticators (including built-in authenticators and security keys), virtual authenticator apps, and RADIUS-based MFA through AWS Managed Microsoft AD. A user can have up to eight MFA devices, with a maximum of two virtual authenticator apps and six FIDO authenticators.

The same page also states the following regarding passkeys:

Passkeys may be bound to the device that creates them, or they may be syncable and backed up to a cloud.

The page further notes that while FIDO-compatible devices can function within IAM Identity Center, it recommends that you test a FIDO authenticator yourself before enabling it for MFA. It also states that the most common security keys create device-bound FIDO credentials.

7.3 MFA Configuration Options

According to the prompt users page, choose MFA types page, and device enforcement page, the following options are available for MFA configuration:

Frequency of MFA requests: Every time (always-on, the default), only when the sign-in context changes (context-aware), or not at all (disabled).
MFA types: Security keys and built-in authenticators, or authenticator apps.
Handling of users without an MFA device: Require registration during sign-in (default), send a one-time password via email, deny sign-in, or allow sign-in.
Whether users can register their own MFA devices.

According to the directory MFA page, IAM Identity Center directory users initially sign in using their username and password, followed by a second factor, which can be a code, security key, or biometric authentication.

7.4 Settings Not Found

This article searched for the following configuration options in the IAM Identity Center pages:

Settings to designate UV as either required or preferred.
Settings to differentiate between syncable passkeys and device-bound passkeys.
Settings to restrict authenticators based on attestation or AAGUID.

No statement was found for any of them (No statement found). This article searched using three categories of terms: "passkey," "FIDO2," and "MFA"; "device-bound," "syncable," and "attestation"; and "backup eligible" and "AAGUID." This article does not state that IAM Identity Center is unable to reject synced passkeys. All that this article can confirm is that these settings could not be found on the pages in Section 1.3.

7.5 Relationship to the AAL2 Form in NIST

As an inference of this article (Inference), when MFA with a FIDO authenticator is required, IAM Identity Center directory users, after entering their password, perform multi-factor authentication (MFA) using that authenticator. Consequently, these users can be placed in the combination form (a physical authenticator and a password) described in the AAL2 section of the 63B-4 text. This inference is independent of whether the FIDO authenticator returns a UV (User Verification) signal. However, it is important to note that this article does not state that IAM Identity Center settings meet the requirements of AAL2. AAL2 has other requirements, and determining compliance requires an assessment by organizations using NIST standards as a benchmark.

7.6 IAM Identity Center Table

Setting	Values	Default	Related 63B-4 Text	Source State
MFA Request Frequency	always-on, context-aware, disabled	always-on	AAL2 section	Stated
MFA Type	Security keys and built-in authenticators, authenticator apps	—	AAL2 section	Stated
Handling of Users Without MFA Devices	Require registration, one-time password via email, deny sign-in, allow sign-in	Require registration	AAL2 section	Stated
Setting for Requiring UV	—	—	IMPR-1	No statement found
Setting for Distinguishing Syncable Passkeys	—	—	BE and BS statements in B.3, AAL3 section	No statement found
Restrictions Based on Attestation or AAGUID	—	—	Three statements regarding attestation in B.3	No statement found
MFA with External IdPs	—	—	—	Stated as not supported

8. Candidates When No Setting Matches

This chapter outlines candidates when no setting matching a requirement in Chapter 4 is found on the AWS side. The candidates in this chapter are all inferences of this article (Inference), and are not recommendations from AWS or NIST. This article does not determine which option is best suited for your organization.

8.1 When Accepting Synced Passkeys at AAL2

As an inference of this article (Inference), organizations that want to treat synced passkeys as multi-factor cryptographic authenticators at AAL2 within Amazon Cognito user pools can consider a configuration that sets UserVerification to required and FactorConfiguration to MULTI_FACTOR_WITH_USER_VERIFICATION. However, even with this configuration, the decisions outlined in IMPR-3 and the documentation in CAK-6 will remain outside of the configuration itself.

8.2 When Restricting Syncable Authenticators

Organizations with a policy that restricts syncable authenticators with BE (MAY), or those requiring authentication at AAL3, do not find items for that policy in the Amazon Cognito and IAM Identity Center settings (see Sections 6.7 and 7.6). As an inference of this article (Inference), there are three candidates:

Implementing WebAuthn validation directly in the application, examining BE flags and attestation data.
Delegating authentication to an external Identity Provider (IdP) that allows for authenticator restrictions, and then connecting that IdP to Amazon Cognito or IAM Identity Center. When using an external IdP with IAM Identity Center, that external IdP manages MFA configuration (see Section 7.1).
Distributing device-bound security keys from the organization. However, no setting was found in IAM Identity Center or Amazon Cognito that only accepts the keys distributed by the organization.

This article does not specify which external IdPs or products offer this particular configuration.

8.3 Documenting Established Policies

CAK-6 requires that when using syncable authenticators, the requirements are documented and communicated. The Target is CSP/Verifier. As an inference of this article (Inference), the receiving organization can document its policies, including the values configured in Chapters 6 and 7, as well as how it handles any missing configurations.

8.4 Summary Table

The following table lists the requirements for the receiving side and the corresponding requirements on the sync fabric side, for each AWS service. The columns are defined as in Section 2.1.

Requirement or Behavior	Who Must Act (Spec)	AWS Receiver	What You Can Set	What You Cannot Set	Where It Is Written	Source State
Indicate that UV is preferred (IMPR-1)	Verifiers (Target `Verifier`)	Amazon Cognito	`UserVerification` to `preferred` or `required`	Value in the request to the authenticator: No statement found	63B-4 text B.3, WebAuthnConfigurationType page	Stated
Confirm the UV in the response (IMPR-1)	Verifiers (Target `Verifier`)	Amazon Cognito	`UserVerification` to `required`	API items for returning UV results for each sign-in: No statement found	63B-4 text B.3, WebAuthnConfigurationType page	Stated, Inference
Treat as single factor if UV is not present (IMPR-2)	agencies (Target `Verifier`)	Amazon Cognito	`FactorConfiguration`	Combining a passkey without UV with a password: No statement found	63B-4 text B.3, WebAuthnConfigurationType page, authentication flows page	Stated
Indicate that UV is preferred and confirm the UV in the response (IMPR-1)	Verifiers (Target `Verifier`)	IAM Identity Center	MFA type	Settings to make UV mandatory: No statement found	63B-4 text B.3, MFA types page	No statement found
Evaluate usage and determine access policies (IMPR-3)	Agencies (Target `CSP`)	Amazon Cognito, IAM Identity Center	—	—	63B-4 text B.3, OSCAL catalog	Sources disagree
Restrict syncable authenticators with BE (MAY)	Verifiers	Amazon Cognito, IAM Identity Center	—	Restrictions based on BE: No statement found	63B-4 text B.3, actions list, MFA types page	No statement found
Do not condition acceptance on BS in public-facing applications (SHOULD NOT)	Agencies	Amazon Cognito, IAM Identity Center	—	Restrictions based on BS: No statement found	63B-4 text B.3	No statement found
Use attestation (SHOULD), do not prevent usage (SHOULD NOT)	agencies, RPs	Amazon Cognito	—	Attestation enforcement: Stated as not supported	63B-4 text B.3, authentication flows page	Stated as not supported
Use attestation (SHOULD), do not prevent usage (SHOULD NOT)	agencies, RPs	IAM Identity Center	—	Restrictions based on attestation or AAGUID: No statement found	63B-4 text B.3, MFA types page	No statement found
Do not use syncable authenticators at AAL3 (SHALL NOT)	syncable authenticators (Target `CSP`)	Amazon Cognito, IAM Identity Center	—	Settings to only accept device-bound passkeys: No statement found	63B-4 text AAL3 section, OSCAL catalog	No statement found
Protect access to sync fabric keys with MFA equivalent to AAL2 (CAK-5)	User access (Target `CSP`)	—	—	—	63B-4 text B.2, OSCAL catalog	Stated
Document requirements and communicate them (CAK-6)	Requirements (Target `CSP/Verifier`)	—	—	—	63B-4 text B.2, OSCAL catalog	Stated
MFA when using external IdPs	—	IAM Identity Center	—	MFA for IAM Identity Center: Stated as not supported	configure MFA page, prompt users page	Stated as not supported

The What You Can Set column of this table shows that a setting corresponding to the text of a requirement exists. However, it does not indicate whether that setting actually fulfills the requirement.

9. Where the Sources Disagree and What They Do Not Say

This chapter collects where the sources disagree, what they do not list, and what has no statement found in the sources of this article.

9.1 Where the Sources Disagree

Subject of IMPR-3 Obligation: The subject of the sentence in Section B.3 of the 63B-4 text is "Agencies," while the Target of IMPR-3 in the OSCAL catalog is CSP (Section 4.3).
Location of the conformance criteria: the Implementation Resource Hub includes conformance criteria v0.1, and the Revision 4 page indicates "Coming Soon" for the conformance criteria as of November 8, 2026 (Section 3.3).
Whether passkeys can be used as an MFA factor: The AdminGetUserAuthFactors page states that WEB_AUTHN can be used as an MFA factor, while the authentication flows page indicates that passkeys cannot be used as a second factor for password sign-in. The WebAuthnMfaSettingsType page states that passkey MFA applies only when passkey is the first authentication factor (Section 6.3).
Scope of the conformance criteria statements: The statement in IMPR-3 of the OSCAL catalog describes the basis for policy decisions, referencing the information returned, including flags and attestation. The sentence in Section B.3 of the 63B-4 text refers to the returned information. The statement in IMPR-1 of the OSCAL catalog refers to UV as "user verification (UV)." This article references the statements in the 63B-4 text.

9.2 What the Documentation Does Not List

Elements in the response of the ListWebAuthnCredentials operation, specifically BE, BS, and AAGUID (Section 6.5).
The operations in the Amazon Cognito actions list that individually list user passkeys using administrator credentials, and the elements in the response of AdminGetUserAuthFactors, specifically for each passkey (Section 6.5).
In conformance criteria v0.1, statements of their own on UP, BE, BS, and attestation (IMPR-3 mentions flags and attestation only as the basis for policy decisions). The criteria page states that v0.1 collects SHALL statements (Section 4.4).

9.3 Items with No Statement Found

Amazon Cognito restrictions based on BE and BS, and allowing and rejecting by AAGUID (Section 6.7)
Whether Amazon Cognito receives attestation or reads BE and BS internally (Sections 6.4 and 6.5)
The UV value that Amazon Cognito puts in its request to the authenticator, and an API item that returns the UV result for each sign-in (Section 6.2)
Configuration within Amazon Cognito that combines password with passkeys that do not have UV. (Section 6.3)
Within IAM Identity Center, settings that require UV, settings that differentiate syncable authenticators, and limitations based on attestation or AAGUID (Section 7.4)
A statement in Appendix B about syncable authenticators at AAL1 (Section 5.3)
Questions about syncable authenticators in the hub FAQ. This article searched the hub FAQ for the terms "sync," "passkey," "AAL3," "backup," and "attestation," but the entire document was not read.

9.4 Important Notes When Reading

The absence of a description does not necessarily indicate that a particular setting is unavailable. This article does not write a setting with no statement found as something that cannot be done.
AWS documentation does not use NIST's AAL terms. The AAL columns in this article are this article's own matching.
Version 0.1 of the conformance criteria is the initial release, and NIST does not provide certification for these criteria. The IDs and Targets listed in version 0.1 may change with future revisions.
Section B.3 applies specifically to federal agencies acting as RPs. For organizations that are not federal agencies, the applicability of any particular statement will be determined by their own regulations and contracts.
The values presented in Chapters 6 and 7 are based on the pages as of November 8, 2026. The observations in Chapter 10 represent a single observation.

10. What This Setup Showed

The content presented in this chapter consists of single observations and is not a commitment made by the documentation (Observation). This article does not override the documentation statements in Chapter 6 with observations.

10.1 Setup

On November 8, 2026, a single Amazon Cognito user pool was created in the us-east-1 Region. The feature plan is Essentials, and choice-based sign-in allows PASSWORD and WEB_AUTHN. A reserved domain from RFC 2606 was used for the RP ID. No domain or managed login was created, and only the Amazon Cognito user pool APIs were called from the AWS SDK. A small software authenticator was used instead of a browser, and the UP, UV, BE, and BS flags were switched. This software authenticator registers with the attestation format set to none.

10.2 Reading the Settings Back

Right after creation, the response from GetUserPoolMfaConfig was missing the WebAuthnConfiguration field. When SetUserPoolMfaConfig was called with only RelyingPartyId and UserVerification specified, the FactorConfiguration read back was SINGLE_FACTOR.

10.3 When `preferred` Is Set

The registration request returned by StartWebAuthnRegistration indicated that userVerification was set to preferred, residentKey was required, and the attestation field was absent. In WebAuthn Level 3, the default when the attestation field is omitted is none. Both an authenticator without UV and an authenticator with UV, BE, and BS set were able to register successfully. The userVerification in the sign-in request was also preferred, and tokens were issued for both authenticators. The fields in the response from ListWebAuthnCredentials were the six items described in Section 6.5, and did not include BE and BS fields. The ConfiguredUserAuthFactors in the response from AdminGetUserAuthFactors were PASSWORD and WEB_AUTHN.

10.4 When `required` Is Set

When UserVerification is set to required, the userVerification in both registration and sign-in requests became required. Sign-in responses without UV were rejected with NotAuthorizedException and User should be verified. Registration of an authenticator without UV was rejected with WebAuthnCredentialNotSupportedException and User verification is required. An authenticator with UV, BE, and BS set passed both registration and sign-in. An authenticator with UV but without BE and BS passed registration.

Even if a key was registered without UV when preferred was set, the required sign-in was successful when the response had the UV flag set. In this setup, required was decided by the UV flag in each response, rather than the capabilities of the authenticator at the time of registration. As an inference of this article (Inference), the UV flag is a value returned by the authenticator, and in setups that do not use attestation, the receiving side cannot use attestation to verify where the flag comes from. The latter part of B.3 describes the IMPR-3 policy decision as based on flag and attestation information (Section 4.3).

10.5 When MFA Is Required

MFA for the user pool was made required, TOTP was enabled in the pool, and no TOTP was registered for the user. Then the FactorConfiguration was set to MULTI_FACTOR_WITH_USER_VERIFICATION, and UserVerification was set to preferred. In the repeated check, the userVerification in the sign-in request was required both in the attempt immediately after changing the settings and in three attempts after a 90-second wait. Responses without UV were rejected with User should be verified, while responses with UV resulted in token issuance. Even when UserVerification was set to required, responses without UV were rejected with the same error. In the first observation, the password sign-in resulted in an MFA_SETUP challenge.

In the first observation, only once, immediately after changing the settings, the sign-in request showed userVerification as preferred, and a token was issued for a response without UV. This result was not observed in the repeated check. The cause cannot be determined from the sources (No statement found), so this article does not describe this one instance as the behavior of Amazon Cognito.

Requests to change the FactorConfiguration to SINGLE_FACTOR while MFA remained required were rejected with an InvalidParameterException and the following message.

Cannot set WebAuthn factor configuration to SINGLE_FACTOR if MFA is required and WebAuthn is an allowed first auth factor.

10.6 What This Setup Does Not Show

The actual BE and BS values returned by passkeys on smartphones or password managers were not verified.
Registration and sign-in on managed login pages were not verified.
IAM Identity Center was not tested, because it would change organization settings.
All of these are single observations, and the results could vary depending on the Region, timing, and combination of settings.
This article does not state that this setup meets NIST requirements.

11. Failure Modes

This chapter gathers common failures from the documentation quoted in Chapters 4 through 7.

Reading preferred as a setting that confirms UV: According to the authentication flows page, using preferred may allow registration and authentication to succeed even with authenticators that do not have UV (User Verification) capabilities. To require registration and sign-in only with passkeys that have UV functionality, set it to required.
Reading FactorConfiguration as a setting that makes every passkey authentication MFA: MULTI_FACTOR_WITH_USER_VERIFICATION satisfies the MFA requirement when authenticating with passkeys that have UV (Section 6.3). The authentication flows page states that passkeys cannot be used as the second factor for password sign-in (Section 9.1).
Rejecting synced passkeys by BS in public-facing services: Section B.3 states that agencies SHOULD NOT condition acceptance on BS in public-facing applications. Setting restrictions with BS is MAY, not an obligation.
Reading the lack of attestation enforcement as a reason not to accept synced passkeys: Section B.3 states that broad public-facing applications should not prevent the use of syncable authenticators due to the unavailability of attestations (SHOULD NOT).
Looking for the sync fabric MFA (CAK-5) as a setting on the receiving side: The conformance criteria v0.1 set the Target for CAK-5 as CSP. The MFA equivalent to AAL2 for CAK-5 is not the AAL of the receiving application.
Looking for MFA settings in IAM Identity Center when using an external IdP: According to the configure MFA page, MFA in IAM Identity Center is not supported for external IdPs, and the external IdP manages the MFA settings.
Trying to meet AAL3 requirements solely through settings in Amazon Cognito or IAM Identity Center: The 63B-4 text states that syncable authenticators SHALL NOT be used at AAL3, and no setting that only accepts device-bound passkeys was found in either service.
Writing "not possible" in audit materials when no statement is found: The absence of a description does not necessarily indicate that the setting does not exist. Be sure to record the terms, pages, and dates searched.
Treating conformance criteria v0.1 as a certification standard: v0.1 is the first edition, and NIST does not provide certification against the conformance criteria.

12. Frequently Asked Questions about Synced Passkeys Under NIST SP 800-63B-4

This chapter answers questions based on the intended audience outlined in Section 1.1, using the content from Chapters 4 through 9.

Q1. Has NIST banned synced passkeys?

The only prohibition found applies to AAL3. The 63B-4 text states that syncable authenticators SHALL NOT be used at AAL3. Regarding AAL2, it states that they can be supported under the requirements outlined in Appendix B, and the word "may" in that sentence is written in lowercase, indicating it is not a normative term. No AAL1 statement was found in Appendix B (No statement found, Chapter 5).

Q2. Is the MFA for entering the sync fabric configured by the receiving side?

No, it is not. The conformance criteria v0.1 designate CSP as the Target for CAK-5 (protecting access to sync fabric keys with MFA equivalent to AAL2). The term "CSP" does not appear in Section B.2 of the 63B-4 text, and the designation is based on the Target field in the conformance criteria (Section 4.1). This article does not determine whether the accepting organization qualifies as a CSP (Chapter 1).

Q3. Does Amazon Cognito's `preferred` setting verify UV (User Verification)?

No, it does not. With the preferred setting, authenticators that do not support UV functionality may still be registered and authenticated. To require registration and sign-in only with passkeys that support UV functionality, the value is required. While the UserVerification setting corresponds to one of the SHALL requirements in IMPR-1, there is no description found regarding the values that Amazon Cognito includes in requests to the authenticator (Section 6.2).

Q4. Can Amazon Cognito reject only synced passkeys?

No such setting was found. No statement was found regarding restrictions based on BE and BS, nor regarding allowing or rejecting by AAGUID. It is explicitly stated that it does not support attestation enforcement. The fields in the response from ListWebAuthnCredentials also do not include BE and BS. This article does not state that it is impossible to reject them (Sections 6.4 and 6.5).

Q5. Can IAM Identity Center require UV?

No setting that requires UV was found. No setting that distinguishes syncable passkeys was found either. The IAM Identity Center MFA types page notes that passkeys can either be tied to a device or synchronized and backed up to the cloud (Sections 7.2 and 7.4).

Q6. Should public-facing services look at BS and reject synced passkeys?

B.3 states that agencies SHOULD NOT condition acceptance on BS in public-facing applications. Setting restrictions with BS is itself MAY for the Verifier (Section 4.4).

Q7. Does following conformance criteria v0.1 lead to NIST certification?

No. The criteria page states that NIST does not provide certification or assessment of compliance with these criteria. Version 0.1 is the initial release (Section 3.2).

Q8. Are passkeys without UV functionality unusable?

They are not unusable. According to IMPR-2, syncable authenticators without UV functionality are treated as single-factor cryptographic authenticators. AAL1 supports single-factor cryptographic authentication, while AAL2 offers the combination of a physical authenticator and a password or biometric comparison. No statement was found describing whether Amazon Cognito supports this combination (see Chapter 5, Section 6.3).

13. Summary

Before accepting synced passkeys on AWS, organizations that use NIST SP 800-63B-4 as a yardstick check the following:

They have correctly identified which NIST sections (B.2, pertaining to the "sync fabric" side, or B.3, pertaining to the receiving side) apply to their organization. They are not searching for B.2 requirements within AWS configuration options.
They have determined the required AAL. If AAL3 is required, they understand that syncable authenticators SHALL NOT be used and that no setting that accepts only device-bound passkeys was found on the AWS side.
They have decided whether to leave Amazon Cognito's UserVerification set to its default value of preferred or to set it to required. They understand that with preferred, authentication may succeed even without User Verification.
They have defined the values for Amazon Cognito's FactorConfiguration and how passkeys are handled for MFA on a per-user basis.
They understand that restrictions related to BE and BS are defined as MAY, and that conditioning acceptance on BS in public-facing applications is SHOULD NOT.
They are aware that Amazon Cognito does not currently support attestation enforcement, and that the NIST attestation requirements are presented in both SHOULD and SHOULD NOT terms.
If using an external IdP within IAM Identity Center, they understand that the external IdP holds the MFA settings.
They treat the IMPR-3 policy decision and the CAK-6 documentation as work outside the settings.
They are documenting any configuration options that could not be found, along with the search terms, pages, and dates.
They acknowledge that the conformance criteria v0.1 is a first edition, and their internal explanation states that NIST does not certify.

14. References

References:
Tech Blog with curated related content

Written by Hidekazu Konishi