How Identity and Access Management Supports NIST SP 800-63-4

IAL1: Initial Authenticator Binding

Once a unique subscriber account is established for the applicant (now subscriber) in the CSP’s identity system, one or more authenticators can be associated (i.e., bound) to the subscriber’s account. To minimize the need for account recovery, CSPs SHOULD encourage subscribers to bind at least two separate means of authentication. See Sec. 5 for more information about subscriber accounts and Sec. 4.1.2.1 of [SP800-63B] for more information on binding authenticators.

• The CSP SHALL provide the ability for the applicant to bind an authenticator using one of the following methods:
• Remote enrollment of a subscriber-provided authenticator consistent with the requirements for the authenticator type, as defined in Sec. 4.1.3 of [SP800-63B]
• Distribution of a physical authenticator to a validated address
• Distribution or on-site enrollment of an authenticator
• If authenticators are bound outside of a single protected session with the user, the CSP SHALL confirm the presence of the intended subscriber through one of the following methods:
• Return of a continuation code
• Comparison against a biometric collected at the time of proofing

In practice: At lower assurance, the new hire registers a first sign-in method, such as an authenticator app, during setup, and the identity system ties it to their onboarding record.

IAL2: Initial Authenticator Binding

Once a unique subscriber account is established for the applicant (now subscriber) in the CSP’s identity system, one or more authenticators can be associated (i.e., bound) to the subscriber’s account. To minimize the need for account recovery, CSPs SHOULD encourage subscribers to bind at least two separate means of authentication. See Sec. 5 for more information about subscriber accounts and Sec. 4.1.2.1 of [SP800-63B] for more information on binding authenticators.

• The CSP SHALL provide the ability for the applicant to bind an authenticator using one of the following methods:
• Remote enrollment of a subscriber-provided authenticator consistent with the requirements for the authenticator type, as defined in Sec. 4.1.3 of [SP800-63B]
• Distribution of a physical authenticator to a validated address
• Distribution or on-site enrollment of an authenticator
• If authenticators are bound outside of a single protected session with the user, the CSP SHALL confirm the presence of the intended subscriber through one of the following methods:
• Return of a continuation code
• Comparison against a biometric collected at the time of proofing

In practice: On day one, a verified new hire receives a short-lived, single-use enrollment code and uses it to register a security key or passkey to their account.

IAL3: Initial Authenticator Binding

• The CSP SHALL distribute or enroll the subscriber’s initial authenticator during an on-site attended interaction with a proofing agent.
• If the CSP distributes or enrolls the initial authenticator outside of a single authenticated protected session with the subscriber, the CSP SHALL compare a biometric sample collected from the subscriber to the one collected at the time of proofing prior to registration of the authenticator and MAY request that the subscriber bring the identity evidence used during the proofing process to further strengthen the process of binding the authenticator to the subscriber.

In practice: For high-risk roles, a staff member hands the new hire a security key in person, and the identity system links that key to the person who was just verified.

Subscriber Account Maintenance and Updates

The CSP SHALL provide the capability for a subscriber to request that information be updated in their subscriber account. The CSP MAY provide a mechanism for subscribers to directly update non-core attributes.

With the exception of physical addresses, the CSP SHALL validate any changes to core attribute information maintained in the subscriber account. The CSP SHOULD validate a change to the subscriber’s physical address if it is considered a core attribute by the CSP.

The CSP SHALL notify the subscriber of any updates made to information in the subscriber account.

The CSP SHALL provide the capability for the subscriber to report any unauthorized access or potential compromise to information in their subscriber account.

In practice: When a person changes their name or moves to a new team, HR updates the source record and the change flows to the account through a mover workflow.

Subscriber Account Suspension or Termination

The CSP SHALL promptly suspend or terminate the subscriber account when one of the following occurs:

• The subscriber elects to terminate their subscriber account with the CSP.
• The CSP determines that the subscriber account has been compromised.
• The CSP determines that the subscriber has violated the policies or rules for participation in the CSP identity service.
• The CSP determines that the subscriber account is inactive in accordance with the policies or rules established by the CSP.
• The CSP receives notification of a subscriber’s death from an authoritative source.
• The CSP receives a legal instrument instructing it to terminate a subscriber’s account.
• The CSP ceases identity system and services operations.

The CSP SHALL notify the subscriber if their account has been suspended or terminated. Such notices SHALL include information about why the account was suspended or terminated, reactivation or renewal options, and any options for redress if the subscriber thinks the account was suspended or terminated in error.

The CSP SHALL delete all personal information from the subscriber account records following account termination in accordance with the record retention and disposal requirements, as documented in its practices statement (see Sec. 3.1).

In practice: On an employee's last day, the termination in the HR system disables the account right away; inactive accounts are also flagged and disabled after a set quiet period.

AAL1: Permitted Authenticator Types

AAL1 authentication SHALL use any of the following authentication types, which are further defined in Sec. 3:

• Password (Sec. 3.1.1): A memorizable secret typically chosen by the subscriber
• Look-up secret (Sec. 3.1.2): A secret determined by the claimant by looking up a prompted value in a list held by the subscriber
• Out-of-band device (Sec. 3.1.3): A secret sent or received through a separate communication channel with the subscriber
• Single-factor one-time password (OTP) (Sec. 3.1.4): A one-time secret obtained from a device or application held by the subscriber
• Multi-factor OTP (Sec. 3.1.5): A one-time secret obtained from a device or application held by the subscriber that requires activation by a second authentication factor
• Single-factor cryptographic authentication (Sec. 3.1.6): Proof of possession and control via an authentication protocol of a cryptographic key held by the subscriber
• Multi-factor cryptographic authentication (Sec. 3.1.7): Proof of possession and control via an authentication protocol of a cryptographic key held by the subscriber that requires activation by a second authentication factor

In practice: A policy lists which sign-in methods, such as a password or a code from an app, each application accepts at the lowest assurance level, and administrators maintain that list.

AAL1: Authenticator and Verifier Requirements

Authenticators used at AAL1 SHALL use approved cryptography. In other words, they must use approved algorithms, but the implementation need not be validated under [FIPS140].

Communication between the claimant and verifier SHALL occur via one or more authenticated protected channels.

Cryptography used by verifiers operated by or on behalf of federal agencies at AAL1 SHALL be validated to meet the requirements of [FIPS140] Level 1.

In practice: For low-risk applications, the identity provider enforces password rules, blocks repeated guesses, and requires a protected connection, all set once in one shared policy.

AAL1: Reauthentication

These guidelines provide for two types of timeouts, which are further described in Sec. 5.2:

• An overall timeout limits the duration of an authenticated session to a specified period following authentication or a previous reauthentication.
• An inactivity timeout terminates a session that has not had activity from the subscriber for a specified period.

Periodic reauthentication of subscriber sessions SHALL be performed, as described in Sec. 5.2. A definite reauthentication overall timeout SHALL be established, which SHOULD be no more than 30 days at AAL1. An inactivity timeout MAY be applied but is not required at AAL1.

In practice: For low-risk applications, a session lifetime policy sets how long someone stays signed in before the application asks them to sign in again.

AAL2: Permitted Authenticator Types

At AAL2, authentication SHALL use either a multi-factor authenticator or a combination of two separate authentication factors. A multi-factor authenticator requires two factors to execute a single authentication event, such as a cryptographically secure device with an integrated biometric sensor that is required to activate the device. Authenticator requirements are specified in Sec. 3.

When a multi-factor authenticator is used, any of the following MAY be used:

• Multi-factor out-of-band authenticator (Sec. 3.1.3.4)
• Multi-factor OTP (Sec. 3.1.5)
• Multi-factor cryptographic authentication (Sec. 3.1.7)

When a combination of two single-factor authenticators is used, the combination SHALL include one physical authenticator (i.e., “something you have”) from the following list in conjunction with either a password (Sec. 3.1.1) or a biometric comparison:

• Look-up secret (Sec. 3.1.2)
• Out-of-band device (Sec. 3.1.3)
• Single-factor OTP (Sec. 3.1.4)
• Single-factor cryptographic authentication (Sec. 3.1.6)

A biometric characteristic is not recognized as an authenticator by itself. Section 3.2.3 requires a physical authenticator to be authenticated along with a biometric comparison. The physical authenticator then serves as “something you have,” while the biometric match serves as “something you are.” When a biometric comparison is used as an activation factor for a multi-factor authenticator, the authenticator itself serves as the physical authenticator. As noted in that section, local verification of biometric factors (i.e., the use of a multi-factor authenticator with a biometric comparison as an activation factor) is preferred over central biometric factor comparison.

In practice: For most business applications, users sign in with two factors, such as a password plus an app prompt, and a phishing-resistant option such as a security key is offered.

AAL2: Authenticator and Verifier Requirements

Authenticators used at AAL2 SHALL use approved cryptography. Cryptographic authenticators procured by federal agencies SHALL be validated to meet the requirements of [FIPS140] Level 1. At least one authenticator used at AAL2 SHALL be replay-resistant, as described in Sec. 3.2.7. Authentication at AAL2 SHOULD demonstrate authentication intent from at least one authenticator, as discussed in Sec. 3.2.8.

Communication between the claimant and verifier SHALL occur via one or more authenticated protected channels.

Cryptography used by verifiers operated by or on behalf of federal agencies at AAL2 SHALL be validated to meet the requirements of [FIPS140] Level 1 unless otherwise specified.

Verifiers SHALL offer at least one phishing-resistant authentication option at AAL2, as described in Sec. 3.2.5. Federal agencies SHALL require their staff, contractors, and partners to use phishing-resistant authentication to access federal information systems. In all cases, verifiers SHOULD encourage the use of phishing-resistant authentication at AAL2 whenever practical since phishing is a significant threat vector [IC3].

In practice: The identity provider enforces MFA on business applications, offers phishing-resistant methods such as security keys, and applies the verifier settings, all managed as shared policy.

AAL2: Reauthentication

Periodic reauthentication of subscriber sessions SHALL be performed, as described in Sec. 5.2. A definite reauthentication overall timeout SHALL be established, which SHOULD be no more than 24 hours at AAL2. The inactivity timeout SHOULD be no more than 1 hour. When the inactivity timeout has occurred but the overall timeout has not yet occurred, the verifier MAY allow the subscriber to reauthenticate using only a successful password or biometric comparison in conjunction with the session secret, as described in Sec. 5.1.

In practice: A sign-in policy asks users to authenticate again after a set time, and the application or device ends idle sessions after a shorter period.

AAL3: Permitted Authenticator Types

AAL3 authentication SHALL require one of the following authenticator combinations:

• Multi-factor cryptographic authentication (Sec. 3.1.7)
• Single-factor cryptographic authentication (Sec. 3.1.6) used in conjunction with either a password (Sec. 3.1.1) or a biometric comparison

A biometric characteristic is not recognized as an authenticator by itself. Section 3.2.3 requires a physical authenticator to be authenticated along with the biometric comparison. The physical authenticator then serves as “something you have,” while the biometric match serves as “something you are.” When a biometric comparison is used as an activation factor for a multi-factor authenticator, the authenticator itself serves as the physical authenticator. As noted in that section, local verification of biometric factors (i.e., the use of a multi-factor authenticator with a biometric comparison as an activation factor) is preferred over central biometric factor comparison.

In practice: For the most sensitive applications, the policy accepts only hardware-backed keys that cannot be copied, and users register a security key to get in.

AAL3: Authenticator and Verifier Requirements

Authenticators used at AAL3 SHALL use approved cryptography. Communication between the claimant and verifier SHALL occur via one or more authenticated protected channels. The cryptographic authenticator used at AAL3 SHALL have a non-exportable private key and SHALL provide phishing resistance, as described in Sec. 3.2.5. The cryptographic authentication protocol SHALL be replay-resistant, as described in Sec. 3.2.7. All authentication and reauthentication processes at AAL3 SHALL demonstrate authentication intent from at least one authenticator, as described in Sec. 3.2.8. Cryptographic authenticators used at AAL3 SHALL use public-key cryptography to protect the authentication secrets from compromise of the verifier.

Single-factor and multi-factor authenticators used at AAL3 SHALL be validated to meet the requirements of [FIPS140] Level 1 or higher overall. As described in Sec. 3.2.12, cryptographic authenticators used at AAL3 are required to provide a hardware-protected, isolated environment to prevent authentication keys from being leaked or extracted. Since syncable authenticators (described in Appendix B) require the private key to be exportable, syncable authenticators SHALL NOT be used at AAL3.

Cryptography used by verifiers at AAL3 SHALL be validated at [FIPS140] Level 1 or higher.

Hardware-based authenticators and verifiers at AAL3 SHOULD resist relevant side-channel (e.g., timing and power-consumption analysis) attacks.

In practice: At the highest assurance level, administrators configure hardware or platform-bound keys, set which authenticator models are accepted, and tune the verifier settings in the identity provider.

AAL3: Reauthentication

Periodic reauthentication of subscriber sessions SHALL be performed, as described in Sec. 5.2. At AAL3, the overall timeout for reauthentication SHALL be no more than 12 hours. The inactivity timeout SHOULD be no more than 15 minutes. Unlike AAL2, AAL3 reauthentication requirements are the same as for initial authentication at AAL3.

In practice: For the most sensitive applications, sign-in is required again within a short overall limit, and the application or device ends a session that sits idle.

Password Authenticators

Passwords SHALL either be chosen by the subscriber or assigned randomly by the CSP.

If the CSP disallows a chosen password because it is on a blocklist of commonly used, expected, or compromised values (see Sec. 3.1.1.2), the subscriber SHALL be required to choose a different password. Other composition requirements for passwords SHALL NOT be imposed. A rationale for this is presented in Appendix A, Strength of Passwords.

In practice: Users choose their own passwords, or the system assigns random ones, and identity settings plus a self-service reset page guide how passwords are created and changed.

Password Verifiers

The following requirements apply to passwords.

• Verifiers and CSPs SHALL require passwords that are used as a single-factor authentication mechanism to be a minimum of 15 characters in length. Verifiers and CSPs MAY allow passwords that are only used as part of multi-factor authentication processes to be shorter but SHALL require them to be a minimum of eight characters in length.
• Verifiers and CSPs SHOULD permit a maximum password length of at least 64 characters.
• Verifiers and CSPs SHOULD accept all printing ASCII [RFC20] characters and the space character in passwords.
• Verifiers and CSPs SHOULD accept Unicode [ISO/ISC 10646] characters in passwords. Each Unicode code point SHALL be counted as a single character when evaluating password length.
• Verifiers and CSPs SHALL NOT impose other composition rules (e.g., requiring mixtures of different character types) for passwords.
• Verifiers and CSPs SHALL NOT require subscribers to change passwords periodically. However, verifiers SHALL force a change if there is evidence that the authenticator has been compromised.
• Verifiers and CSPs SHALL NOT permit the subscriber to store a hint (e.g., a reminder of how the password was created) that is accessible to an unauthenticated claimant.
• Verifiers and CSPs SHALL NOT prompt subscribers to use knowledge-based authentication (KBA) (e.g., “What was the name of your first pet?”) or security questions when choosing passwords.
• Verifiers SHALL request the password to be provided in full (not a subset of it) and SHALL verify the entire submitted password (e.g., not truncate it).

In practice: Identity provider settings require a minimum length and block commonly used passwords, without forced symbol rules or routine changes.

Out-of-Band Authenticators

The out-of-band authenticator SHALL establish a separate channel with the verifier to retrieve the out-of-band secret or authentication request. This channel is considered to be out-of-band with respect to the primary communication channel (even if it terminates on the same device), provided that the device does not leak information from one channel to the other without the claimant’s participation.

The out-of-band device SHOULD be uniquely addressable by the verifier. Communication over the secondary channel SHALL use approved encryption unless sent via the public switched telephone network (PSTN). For additional authenticator requirements that are specific to using the PSTN for out-of-band authentication, see Sec. 3.1.3.3.

Email SHALL NOT be used for out-of-band authentication because it may be vulnerable to:

• Access using only a password
• Interception in transit or at intermediate mail servers
• Rerouting attacks, such as those caused by Domain Name System (DNS) spoofing

Confirmation codes that are sent to validate email addresses or are issued as recovery codes (see Sec. 4.2.1.2) are not authentication processes and not affected by the above prohibition.

The out-of-band authenticator SHALL uniquely authenticate itself in one of the following ways when communicating with the verifier:

• Using approved cryptography, establish a mutually authenticated protected channel (e.g., client-authenticated transport layer security (TLS) [RFC8446]) with the verifier. Communication between the out-of-band authenticator and the verifier MAY use a trusted intermediary service to which each authenticates. The key used to establish the channel SHALL be provisioned in a mutually authenticated session during authenticator binding, as described in Sec. 4.1.

In practice: Users receive a push prompt or number-matching request on a registered phone, and the identity provider sends it over a separate channel from the sign-in itself.

Out-of-Band Verifiers

The verifier waits for an authenticated protected channel to be established with the out-of-band authenticator and verifies its identifying key. The verifier SHALL NOT store the identifying key itself but SHALL use a verification method (e.g., an approved hash function or proof of possession of the identifying key) to uniquely identify the authenticator. Once authenticated, the verifier transmits the authentication secret to the authenticator. The connection with the out-of-band authenticator MAY be either manually initiated or prompted by a mechanism, such as a push notification.

Depending on the type of out-of-band authenticator, one of the following SHALL take place:

• Transfer of the secret from the secondary to the primary channel. As shown in Fig. 1, the verifier MAY signal the device that contains the subscriber’s authenticator to indicate a readiness to authenticate. It SHALL then transmit a random secret to the out-of-band authenticator and wait for the secret to be returned via the primary communication channel.
• Transfer of the secret from the primary to the secondary channel. As shown in Fig. 2, the verifier SHALL transmit a random authentication secret to the claimant via the primary channel. It SHALL then wait for the secret to be returned via the secondary channel from the claimant’s out-of-band authenticator. The verifier MAY additionally display an address, such as a phone number or VoIP address, for the claimant to use in addressing its response to the verifier.

In all cases, the authentication SHALL be considered invalid unless completed within 10 minutes. Verifiers SHALL accept a given authentication secret as valid only once during the validity period to provide replay resistance, as described in Sec. 3.2.7.

In practice: Identity provider policy sets how long a one-time code lasts, allows each code to be used once, and slows repeated attempts.

Authentication Using the Public Switched Telephone Network

Use of the PSTN for out-of-band verification is restricted as described in this section and SHALL satisfy the requirements of Sec. 3.2.9. Setting or changing the pre-registered telephone number is considered to be the binding of a new authenticator and SHALL only occur as described in Sec. 4.1.2.

Some subscribers may be unable to use PSTN to deliver out-of-band authentication secrets in areas with limited telephone coverage, particularly without mobile phone service. Accordingly, verifiers SHALL ensure that alternative authenticator types are available to all subscribers and SHOULD remind subscribers of this limitation of PSTN out-of-band authenticators before binding one or more devices controlled by the subscriber.

Verifiers SHOULD consider risk indicators (e.g., device swap, SIM change, number porting, other abnormal behavior) before using the PSTN to deliver an out-of-band authentication secret.

Consistent with the discussion of restricted authenticators in Sec. 3.2.9, NIST may adjust the restricted status of out-of-band authentication using the PSTN based on the evolution of the threat landscape and the technical operation of the PSTN.

In practice: Administrators restrict or turn off text message and phone call codes in the method policy, steering users toward app-based or key-based methods instead.

Multi-Factor Out-of-Band Authenticators

Multi-factor out-of-band authenticators operate similarly to single-factor out-of-band authenticators (see Sec. 3.1.3.1). However, they require the presentation and verification of an activation factor (i.e., a password or a biometric characteristic) before allowing the claimant to complete the authentication transaction (i.e., before accessing or entering the authentication secret as appropriate for the authentication flow being used). Each use of the authenticator SHALL require the presentation of the activation factor.

Authenticator activation secrets SHALL meet the requirements of Sec. 3.2.10. A biometric activation factor SHALL meet the requirements of Sec. 3.2.3, including limits on the number of consecutive authentication failures. The password or biometric sample used for activation and any biometric data derived from the biometric sample (e.g., a fingerprint image and feature locations produced by a fingerprint feature extractor) SHALL be erased immediately after an authentication operation.

In practice: A user opens an authenticator app and unlocks it with a fingerprint or PIN on their phone before approving the sign-in prompt.

Multi-Factor OTP Authenticators

Multi-factor OTP authenticators operate similarly to single-factor OTP authenticators (see Sec. 3.1.4.1), except they require the presentation and verification of an activation factor (i.e., a password or a biometric characteristic) to obtain the OTP from the authenticator. Each use of the authenticator SHALL require the input of the activation factor.

In addition to activation information, multi-factor OTP authenticators and verifiers contain two persistent values: 1) a symmetric key that persists for the authenticator’s lifetime and 2) a nonce that is either changed each time the authenticator is used or based on a real-time clock.

The secret key and its algorithm SHALL provide at least the minimum security strength specified in the latest revision of [SP800-131A] (i.e., 112 bits as of the date of this publication). The nonce SHALL be of sufficient length to ensure that it is unique for each operation of the authenticator over its lifetime. If a subscriber needs to change the device on which a software-based OTP authenticator resides, they SHOULD bind the authenticator application on the new device to their subscriber account, as described in Sec. 4.1.2, and invalidate the authenticator application that will no longer be used. Alternatively, the subscriber MAY export the secret key and store it in a sync fabric that meets the requirements in Appendix B.2 and retrieve the key with their new device.

The authenticator output is obtained using an approved cryptography block cipher or hash function to securely combine the key and nonce. In coordination with the verifier, the authenticator MAY truncate its output to as few as six decimal digits or equivalent.

In practice: Employees install an authenticator app that creates one-time codes, and they unlock the app with a PIN or fingerprint before seeing a code.

Multi-Factor OTP Verifiers

Multi-factor OTP verifiers effectively duplicate the process of generating the OTP used by the authenticator without requiring a second authentication factor. As such, the symmetric keys used by authenticators SHALL be strongly protected against unauthorized disclosure by access controls that limit access to the keys to only those software components that require access.

When binding a multi-factor OTP authenticator to a subscriber account, the verifier or associated CSP SHALL use approved cryptography for key establishment to generate and exchange keys or to obtain the secrets required to duplicate the authenticator output.

The verifier SHALL use approved encryption and an authenticated protected channel when collecting the OTP. Verifiers SHALL accept a given OTP only once while it is valid to provide replay resistance, as described in Sec. 3.2.7. If a claimant’s authentication is denied due to the duplicate use of an OTP, verifiers MAY warn the claimant if an attacker has been able to authenticate in advance. Verifiers MAY also warn a subscriber in an existing session of the attempted duplicate use of an OTP.

Time-based OTPs [TOTP] SHALL have a defined lifetime that is determined by the expected clock drift in either direction of the authenticator over its lifetime plus an allowance for network delay and claimant entry of the OTP.

The verifier SHALL implement a rate-limiting mechanism that effectively limits the number of consecutive failed authentication attempts that can be made on the subscriber account, as required by Sec. 3.2.10.

In practice: The identity provider checks app-generated codes, rejects a code used twice, limits the time each code is valid, and slows repeated wrong entries.

Multi-Factor Cryptographic Authenticators

Multi-factor cryptographic authenticators encapsulate one or more authentication keys that SHALL only be accessible through the presentation and verification of an activation factor (i.e., a password or a biometric characteristic). Non-exportable authentication keys, suitable for use at AAL3, SHALL be stored in an isolated execution environment that is protected by hardware or in a separate processor with a controlled interface to the central processing unit of the user endpoint. Exportable authentication keys (usable at AAL2 or below) SHOULD be stored in appropriate storage that is available to the authenticator (e.g., keychain storage). If accessible to the endpoint being authenticated, authentication keys SHALL be strongly protected against unauthorized disclosure by using access controls that limit access to the authentication keys to only those software components that require access.

External (non-embedded) cryptographic authenticators SHALL meet the requirements for connected authenticators in Sec. 3.2.11. Each authentication event SHALL require input and verification of the local activation factor. Authenticator activation secrets SHALL meet the requirements of Sec. 3.2.10. A biometric activation factor SHALL meet the requirements of Sec. 3.2.3, including limits on the number of consecutive authentication failures. The activation secret or biometric sample and any biometric data derived from the biometric sample (e.g., a fingerprint image and feature locations produced by a fingerprint feature extractor) SHALL be erased after an authentication transaction.

In practice: Staff sign in with a security key or a passkey on their laptop, unlocking it with a fingerprint or PIN, so no password is typed into the sign-in page.

Multi-Factor Cryptographic Verifiers

The requirements for a multi-factor cryptographic verifier are identical to those for a single-factor cryptographic verifier, as described in Sec. 3.1.6.2. Some multi-factor authenticators include flags to indicate whether an activation factor was used. If such a flag is present and indicates that an activation factor was not used, the authentication SHALL be treated as single-factor. Otherwise, verification of the output from a multi-factor cryptographic authenticator indicates that the activation factor was used.

In practice: The identity provider challenges the user's key or passkey, ties the response to the real site address, and handles registering new keys for each user.

Syncable Authenticators

Some cryptographic authenticators allow the subscriber to copy (i.e., clone) the authentication secret to additional devices, usually via a sync fabric. This eases the burden for subscribers who want to use additional devices to authenticate. Specific requirements for syncable authenticators and the sync fabric are given in Appendix B.

In practice: Passkey policy says whether a passkey that syncs across a user's devices is allowed, or whether certain applications need a key tied to one device.

Rate Limiting (Throttling)

When required by the authenticator type descriptions in Sec. 3.1, the verifier SHALL implement controls to protect against online guessing attacks. Unless otherwise specified in the description of a given authenticator, the verifier SHALL limit consecutive failed authentication attempts using a specific authenticator on a single subscriber account to no more than 100 by disabling that authenticator. If more than one authenticator is involved with an excessive number of authentication attempts (e.g., single-factor cryptographic authenticator and centrally verified password), both authenticators SHALL be disabled. Authenticators that have been disabled SHALL be required to rebind to the subscriber account, as described in Sec. 4.1, to be usable in the future.

The limit of 100 attempts is an upper bound, and agencies MAY impose lower limits. The limit of 100 was chosen to balance the likelihood of a correct guess (e.g., 100 attempts against a six-digit decimal OTP authenticator output) versus the potential need for account recovery when the limit is exceeded.

Additional techniques MAY be used to reduce the likelihood that an attacker will lock the legitimate claimant out due to rate limiting. These include:

• Requiring the claimant to complete a bot detection and mitigation challenge before attempting authentication
• Requiring the claimant to wait after a failed attempt for a period of time that increases as the subscriber account approaches its maximum allowance for consecutive failed attempts (e.g., 30 seconds up to an hour)

In practice: The identity provider locks or slows an account after repeated wrong sign-in attempts, and administrators set the thresholds in a throttling policy.

Phishing Resistance

Phishing attacks, previously referred to in SP 800-63B as “verifier impersonation,” are attempts by fraudulent verifiers and RPs to fool an unwary claimant into presenting an authenticator to an impostor. In some prior versions of SP 800-63, protocols that are resistant to phishing attacks were also referred to as “strongly MitM-resistant.”

In this document, phishing resistance is the ability of the authentication protocol to prevent the disclosure of authentication secrets and valid authenticator outputs to an impostor verifier (i.e., an attacker fraudulently posing as the verifier) without relying on the vigilance of the claimant. How the claimant is directed to the impostor verifier is not relevant. For example, regardless of whether the claimant was directed there via search engine optimization or prompted by email, it is considered to be a phishing attack.

Approved cryptographic algorithms SHALL be used to establish phishing resistance where required. Keys used for this purpose SHALL provide at least the minimum security strength specified in the latest revision of [SP800-131A] (i.e., 112 bits as of the date of this publication).

Phishing resistance requires single- or multi-factor cryptographic authentication. Authenticators that involve the manual entry of an authenticator output (e.g., out-of-band and OTP authenticators) SHALL NOT be considered phishing-resistant because the manual entry does not bind the authenticator output to the specific session being authenticated. For example, an impostor verifier could relay an authenticator output to the verifier and successfully authenticate.

In practice: An authentication method policy requires phishing-resistant methods, such as security keys, for administrators and finance staff; these are designed so a fake login page gets nothing reusable.

Restricted Authenticators

As threats evolve, authenticators’ ability to resist attacks typically degrades. Conversely, the performance of some authenticators may improve, such as when changes to their underlying standards increase their ability to resist particular attacks.

To account for these changes in authenticator performance, NIST places additional restrictions on authenticator types or specific classes or instantiations of an authenticator type. Although they represent a less secure approach to multi-factor authentication, restricted authenticators remain necessary for some government-to-public applications. At the time of publication of these guidelines, there is one restricted authenticator: the use of the PSTN for out-of-band authentication, as described in Sec. 3.1.3.3.

The acceptance of a restricted authenticator requires the implementing organization to assess, understand, and accept the risks associated with that authenticator and acknowledge that risks will likely increase over time. It is the RP’s responsibility to determine the level of acceptable risk for their systems and associated data, define any methods for mitigating excessive risks, and communicate those determinations to the verifier. If the RP determines that the risk to any party is unacceptable, the restricted authenticator SHALL NOT be used, and an alternative authenticator type SHALL be used.

In practice: Administrators keep a short list of older methods, such as text message codes, that are limited by policy, and record who accepted the risk where they remain.

Authenticator Binding

Authenticator binding refers to establishing an association between a specific authenticator and a subscriber account to enable the authenticator to authenticate for that subscriber account, possibly in conjunction with other authenticators.

Authenticators SHALL be bound to subscriber accounts by either:

• Being issued by the CSP as part of enrollment or
• Using a subscriber-provided authenticator that is acceptable to the CSP.

The SP 800-63 suite of guidelines refers to the binding rather than the issuance of authenticators to accommodate both options.

Throughout the lifetime of a digital identity, CSPs SHALL maintain a record of all authenticators that are bound to each subscriber account. The CSP SHALL determine the characteristics of the authenticator being bound (e.g., single-factor versus multi-factor, phishing-resistant or not) so that verifiers can assess compliance with the requirements at each AAL. This determination MAY be based on strong evidence (e.g., authenticator attestation), direct information from having issued the authenticator, or typical characteristics of authenticator implementations (e.g., whether a user verification bit is set by [WebAuthn]).

The CSP SHALL also maintain other state information that is required to meet the authenticator verification requirements. For example, the throttling of authentication attempts described in Sec. 3.2.2 requires the CSP or verifier to maintain state information on recent failed authentication attempts, except for activation factors verified at the authenticator.

In practice: When employees enroll a new sign-in method, the registration flow ties it to their verified account, and an existing strong sign-in method must be used first.

Binding an Additional Authenticator

To minimize the need for account recovery, CSPs and verifiers SHOULD encourage subscribers to maintain at least two separate means of authentication. For example, a subscriber who usually uses an OTP authenticator as a physical authenticator MAY also be issued look-up secret authenticators or register a device for out-of-band authentication to be used if the physical authenticator is lost, stolen, or damaged. See Sec. 4.2 for more information on replacing passwords.

Accordingly, CSPs SHALL permit the binding of multiple authenticators to a subscriber account. When any new authenticator is bound to a subscriber account, the CSP SHALL ensure that the process requires authentication at either the maximum AAL currently available in the subscriber account or the maximum AAL at which the new authenticator will be used, whichever is lower. For example, binding an authenticator that is suitable for use at AAL2 requires authentication at AAL2 unless the subscriber account currently has only AAL1 authentication capabilities. When an authenticator is added, the CSP SHALL notify the subscriber via a mechanism independent of the transaction binding the new authenticator, as described in Sec. 4.6.

In practice: Users are encouraged to register a second method, such as a backup key, and adding it requires signing in with a method they already hold.

Issued Recovery Codes

CSPs that support this option allow the subscriber to maintain one or more recovery addresses (e.g., postal, email, text message, voice). When recovery is required, a recovery code will be sent to a claimant-chosen address. The issued recovery code SHALL include at least six decimal digits (or equivalent) from an approved random bit generator, as described in Sec. 3.2.12. The issued recovery code may be presented as a numeric or a printable ASCII representation (e.g., Base64) for manual entry, a secure (e.g., https) link with a representation of the recovery code, or a machine-readable optical label (e.g., QR code) that contains the recovery code.

Issued recovery codes SHALL be valid for at most:

• 21 days when sent to a postal address within the contiguous United States
• 30 days when sent to a postal address outside of the contiguous United States
• 10 minutes when sent via text message or voice
• 24 hours when sent to an email address

The verification of issued recovery codes SHALL be subject to the throttling requirements in Sec. 3.2.2.

When establishing recovery addresses other than those validated or verified as part of the identity proofing process, the address SHALL be verified. To verify an address, the CSP SHALL send a confirmation code with the same characteristics as a recovery code to the newly established recovery address. A recovery address SHALL be established only after the subscriber provides the correct confirmation code to the CSP. CSPs SHALL allow the subscriber to establish at least two recovery addresses.

In practice: A user who lost their phone asks the help desk or a self-service page for recovery, confirms who they are, and receives a one-time recovery code at a recovery address on file.

Repeated Identity Proofing

When the subscriber account has been identity-proofed at a minimum of identity assurance level 1 (IAL1), CSPs SHOULD support account recovery by repeating a portion of the identity proofing process. The CSP SHALL repeat the necessary steps of identity proofing consistent with the level of initial identity proofing and SHALL confirm that the claimant’s identity is consistent with the previously established account. If the CSP has retained a biometric sample from the user or a copy of the evidence used during the initial proofing that is of sufficient quality and resolution, the CSP MAY repeat only the verification portion of the identity proofing process, as described in [SP800-63A].

In practice: To replace a lost authenticator, the help desk asks the user to repeat identity verification, for example through a video check, before issuing the replacement.

Recovery Without Identity Proofing

When subscribers have not been identity-proofed, a reproofing option is not available to support account recovery. The recovery of such subscriber accounts SHALL require the successful use of a saved recovery code, issued recovery code, or recovery contact.

Since identity proofing requires issuing authenticators that are sufficient for multi-factor authentication to allow the subscriber to access personal information about themselves, subscriber accounts that can authenticate at a maximum of AAL1 are without identity proofing.

In practice: For lower-risk accounts that were never identity-proofed, recovery relies on a saved or issued recovery code or a recovery contact, since there is no proofing step to repeat.

Recovery at AAL2

To recover an account that can authenticate at a maximum of AAL2, the CSP SHALL require the subscriber to complete one of the following:

• Two recovery codes obtained using different methods from the set (i.e., saved, issued, and recovery contacts)
• One recovery code from the set (i.e., saved, issued, and recovery contacts) plus authentication with a single-factor authenticator that is bound to the subscriber account
• Repeated identity proofing (provided that the subscriber account has been identity-proofed)

In practice: To recover an account that signs in with MFA, the person presents two recovery codes from different routes, or one code plus a bound single-factor sign-in method, or repeats identity verification.

Recovery at AAL3

If an account that can authenticate at AAL3 has been identity-proofed at IAL1 or IAL2, the requirements are the same as those for recovery at AAL2.

If an account that can authenticate at AAL3 has been identity-proofed at IAL3, the CSP SHALL successfully perform a successful biometric comparison against the biometric characteristic collected during an initial on-site attended identity proofing session, as described in [SP800-63A]. The CSP MAY also require the presentation of the evidence used in the initial identity proofing process.

In practice: For an account that needs a hardware key, recovery includes verifying the person again and registering a new key before access is restored.

Loss, Theft, Damage, and Compromise

Compromised authenticators include those that have been lost, stolen, or subject to unauthorized duplication or that have activation factors that are no longer in the subscriber’s control. Generally, one must assume that a lost authenticator has been stolen or compromised by someone other than the legitimate holder of the authenticator. Damaged or malfunctioning authenticators are also considered compromised to guard against any possibility of the extraction of the authenticator’s secret.

The CSP SHALL suspend, invalidate, or destroy compromised authenticators from the subscriber’s account promptly following compromise detection. Organizations SHOULD establish time limits for this process.

To facilitate the secure reporting of an authenticator’s loss, theft, damage, or compromise, the CSP SHOULD provide the subscriber with a method of authenticating using a backup or alternate authenticator. This backup authenticator SHALL be a password or a physical authenticator. Either could be used, but only one authentication factor is required to make this report. Alternatively, the subscriber MAY establish an authenticated protected channel for the CSP to verify the information collected during identity proofing. The CSP MAY choose to verify a contact address (i.e., the email address, telephone number, or postal address) and suspend or invalidate authenticators that are reported to have been compromised.

In practice: When a laptop or security key is reported lost, the help desk revokes that authenticator and its sessions, and issues a replacement to the verified user.

Invalidation

The invalidation of an authenticator (sometimes referred to as revocation or termination) is the removal of the binding between the authenticator and a subscriber account.

CSPs SHALL promptly invalidate authenticators when a subscriber account ceases to exist (e.g., subscriber’s death, the discovery of a fraudulent subscriber), when requested by the subscriber, when the authenticator is compromised, or when the CSP determines that the subscriber no longer meets its eligibility requirements. The CSP SHALL make a risk-based determination of the authenticity of invalidation requests from the subscriber. The consequences of not invalidating a compromised authenticator are usually more significant than the denial-of-service potential of invalidating one in error.

The CSP SHOULD retrieve any authenticator that contains personal information or provide for its erasure or destruction promptly following invalidation. The CSP SHOULD notify the subscriber when an authenticator is invalidated, as described in Sec. 4.6.

Further requirements on the invalidation of PIV authenticators are found in [FIPS201].

In practice: When someone leaves, or a key is reported compromised, their authenticators are removed from the account and active sessions are ended at the same time.

Session Bindings

A session occurs between the software (i.e., the session subject) that a subscriber is running (e.g., browser, application, operating system) and the RP or CSP that the subscriber is accessing (i.e., the session host). A session secret SHALL be shared between the subscriber’s software and the accessed service. This secret binds the two ends of the session and allows the subscriber to continue using the service over time. The secret SHALL be directly presented by the subscriber’s software, or possession of the secret SHALL be proven using a cryptographic mechanism.

The continuity of authenticated sessions SHALL be based on the possession of a session secret that is issued by the session host at the time of authentication and optionally refreshed during the session. The nature of a session depends on the application, such as:

• A web browser session with a “session” cookie
• An instance of a mobile application that retains a session secret

Session secrets that are used as bearer tokens for session management SHOULD NOT be persistent (i.e., retained across a restart of the associated application or a reboot of the host device) because they are tied to specific sessions that a restart or reboot would end. Cookies and similar “remember my browser” features SHALL NOT be used instead of authentication except as provided for reauthentication at AAL2 in Sec. 2.2.3 when the inactivity limit has been exceeded but the time limit has not.

In practice: Identity provider settings control how long a sign-in session lasts, how tokens and cookies are protected, and when a session must start over.

Reauthentication

The periodic reauthentication of sessions SHALL be performed to confirm the subscriber’s continued presence at an authenticated session (e.g., that the subscriber has not walked away without logging out).

Session management uses two types of timeouts. An overall timeout limits the duration of an authenticated session to a specific period following authentication or a previous reauthentication. An inactivity timeout terminates a session without activity from the subscriber for a specific period. For both types of timeouts, the RP MAY alert the subscriber that the session is about to be terminated and allow the subscriber to make the session active or reauthenticate as appropriate before the session expires. When either timeout expires, the session SHALL be terminated. Session activity SHALL reset the inactivity timeout, and successful reauthentication during a session SHALL reset both timeouts.

The overall and inactivity timeout expiration limits depend on several factors, including the AAL of the session, the environment in which the session is conducted (e.g., whether the subscriber is in a restricted area), the type of endpoint being used (e.g., mobile application, web-based), whether the endpoint is a managed device, and the nature of the application itself. The limits MAY also be extended when higher security session maintenance technologies (e.g., device-bound mechanisms) are used. Agencies SHALL establish and document the inactivity and overall time limits being enforced in a system security plan, such as that described in [SP800-39]. Detailed requirements for each AAL are given in Sec. 2.1.3, Sec. 2.2.3, and Sec. 2.3.3.

In practice: A policy asks users to sign in again after a set time and requires an extra check before sensitive actions, such as changing payment details.

Common FAL Requirements

If no FAL is specified by the trust agreement or federation transaction, the requirements of this section still apply.

At all FALs, all federation transactions SHALL comply with the requirements in Sec. 3 to deliver an assertion to the RP and create an authenticated session at the RP. Examples of assertions used in federation protocols include the ID Token in OpenID Connect [OIDC] and the Security Assertion Markup Language [SAML] Assertion format.

At all FALs, the RP SHALL validate the assertion from the IdP, since the RP needs to trust the IdP to provide valid assertions representing the subscriber’s authentication event.

All parties in the federation SHALL employ security controls, as discussed in Sec. 3.11.

An IdP or RP can be capable of operating at multiple FALs simultaneously, depending on use case and needs. For example, an IdP could provide federation transactions at FAL3 to an RP that provides access to a set of high-risk functionality while simultaneously providing FAL2 to an RP with a lower risk profile. Similarly, an RP could require FAL2 for normal actions but require the subscriber to successfully complete an FAL3 federation transaction for higher impact or more sensitive actions at the RP. This capability extends to other dimensions, as an IdP could simultaneously have access to subscriber accounts that have been proofed at any IAL and allow authentication at any AAL. An RP talking to that IdP would normally have restrictions on the lowest IAL and AAL that it is willing to accept for access. As a consequence, trust agreements are required to establish the xALs allowed and required for different use cases (see Sec. 2.5).

In practice: Federation settings between systems cover basics such as signed sign-in messages, named recipients, and an agreed trust setup before two parties exchange logins.

Federation Assurance Level 1 (FAL1)

FAL1 provides a basic level of protection for federation transactions and allows for a wide range of use cases and deployment decisions.

At FAL1, the federation protocol SHOULD apply assertion injection protection, as discussed in Sec. 3.11.1. The federation transaction SHOULD be initiated by the RP.

At FAL1, the IdP SHALL sign the assertion using approved cryptography. The RP SHALL validate the signature using the verification key associated with the expected IdP. The signature protects the integrity of the assertion contents and allows for the IdP to be verified as the source of the assertion.

At FAL1, the assertion SHALL be audience-restricted to a specific RP or set of RPs, and the RP SHALL validate that it is one of the targeted RPs for the given assertion. Each RP in the audience SHALL enforce replay protection mechanisms in the assertion to ensure that the same assertion is not accepted by a given RP multiple times. An assertion with multiple audiences could be accepted by multiple RPs but only once by each RP.

At FAL1, federated identifiers SHOULD NOT contain plaintext personal information, such as usernames, email addresses, employee numbers, etc.

At FAL1, the trust agreement MAY be established by the subscriber during the federation transaction, as discussed in Sec. 4.3.2. Alternatively, the trust agreement MAY be established prior to the federation transaction (i.e., a “pre-established” trust agreement), as discussed in Sec. 4.3.1.

In practice: A typical employee app uses standard single sign-on, where the identity provider sends a signed message and the application accepts it as proof of who signed in.

Federation Assurance Level 2 (FAL2)

FAL2 provides a high level of protection for federation transactions by requiring additional protections against a variety of attacks on federated systems, including attempts to inject assertions into a federated transaction. All of the requirements for FAL1 apply at FAL2, except where overridden by more specific or stringent requirements here.

At FAL2, the assertion SHALL be strongly protected from assertion injection attacks, as discussed in Sec. 3.11.1. The federation transaction SHALL be initiated by the RP.

At FAL2, the assertion SHALL be audience restricted to a single RP. The RP SHALL enforce replay protection mechanisms in the assertion.

At FAL2, federated identifiers SHALL NOT contain plaintext personal information, such as usernames, email addresses, employee numbers, etc.

At FAL2, a trust agreement SHALL be established prior to the federation transaction taking place (i.e., a “pre-established” trust agreement), as discussed in Sec. 4.3.1.

IdPs operated by or on behalf of federal agencies that present assertions at FAL2 or higher SHALL protect signing keys that are used in the generation of assertions with mechanisms validated at [FIPS140] Level 1 or higher.

In practice: For apps that need stronger federation, administrators allow only sign-ins the application starts, restrict each sign-in message to that one application, and register the trust before anyone signs in.

Federation Assurance Level 3 (FAL3)

FAL3 provides a very high level of protection for federation transactions and establishes very high confidence that the information communicated in the federation transaction matches what was established by the CSP and IdP. FAL3 also protects against the possibility of a compromised IdP by requiring additional authentication by the subscriber at the RP. All of the requirements at FAL1 and FAL2 apply at FAL3, except where overridden by more specific or stringent requirements here.

At FAL3, the RP SHALL verify that the subscriber is in control of an authenticator in addition to the assertion. This authenticator is either identified in a holder-of-key assertion (see Sec. 3.15) or is a bound authenticator (see Sec. 3.16).

At FAL3, a trust agreement SHALL be established prior to the federation transaction taking place (i.e., a “pre-established” trust agreement), as discussed in Sec. 4.3.1.

At FAL3, the identifiers for the CSP, IdP, and RP SHALL be established manually. Each identifier SHALL be uniquely associated with the verification keys for the party represented. Verification keys SHALL be transmitted through a trusted mechanism, which could be manual or automated, as indicated in the trust agreement.

In practice: For the highest-risk applications, federation is tied to a key the user holds, designed so a stolen sign-in message alone does not get anyone in.

Cryptographic Key Rotation

Over time, it can be desirable or necessary to update the cryptographic key associated with a CSP, IdP, or RP. The allowable update process for any identifiers and cryptographic keys SHALL be defined by the trust agreement and SHALL be executed using an authenticated protected channel, as in the initial cryptographic key establishment.

For example, if the IdP is identified by a URL, the IdP could publish its current public key set at a location underneath that URL. The IdP can update which keys are published at that location as needed. RPs can then fetch the public key from the known location as needed and obtain updated public keys as they are made available.

In practice: Federation signing certificates are replaced on a schedule or when needed, and the identity team coordinates the change with each connected application.

Account Resolution

If the RP has access to existing information about a set of subscribers, and this information is not associated with a federated identifier, the RP performs a process known as account resolution to determine which set of subscriber information to associate with a new RP subscriber account.

An RP that performs account resolution SHALL ensure that the attributes requested from the IdP are sufficient to uniquely resolve the subscriber within the RP’s system before linking the federated identifier with the RP subscriber account and granting access. The intended use of each attribute by the RP is detailed in the trust agreement, including whether the attribute is used for account resolution in this manner.

An RP that performs account resolution SHALL design the process such that it does not associate an RP subscriber account’s information with a federated identifier that does not belong to the subscriber.

For example, a subscriber-controlled wallet might not provide an RP with a federated identifier but could allow the RP to conduct account resolution by providing the RP an attribute bundle from the CSP that allows the RP to uniquely resolve the subscriber to an RP subscriber account. Alternatively, an RP using a pre-provisioning model could uniquely associate an incoming assertion to an RP subscriber account based on an agreed-upon set of attributes.

A similar account resolution process is also used when the RP verifies an authenticator used in a holder-of-key assertion for the first time. In this case, the RP SHALL ensure that the attributes carried with the authenticator uniquely resolve to the RP subscriber account before accepting the authenticator.

In practice: When an application already has user records, the identity team matches each federated sign-in to the right person through correlation rules, flagging unclear matches.

Authenticated Sessions at the RP

The ultimate goal of a federation transaction is to create an authenticated session between the subscriber and the RP that is backed by a verified assertion from the IdP. This authenticated session can be used for allowing the subscriber access to functions at the RP (i.e., logging in), identifying the subscriber to the RP, or processing attributes about the subscriber carried in the federation transaction.

An authenticated session SHALL be created by the RP only when the following conditions are true:

• The RP has processed and verified a valid assertion.
• The assertion is from the expected IdP for a transaction.
• The IdP that issued the assertion is the IdP identified in the federated identifier of the assertion.
• The assertion is associated with an RP subscriber account, which may be ephemeral.
• The RP subscriber account has been provisioned at the RP through the method specified in the trust agreement.

When federation is used as part of an identification process, an RP subscriber account may not be established until other processes have been completed.

If the assertion is a holder-of-key assertion at FAL3, the authenticator indicated in the assertion SHALL be verified before the RP subscriber account is associated with an authenticated session, as discussed in Sec. 3.15.

If the assertion also requires authentication with a bound authenticator at FAL3, a bound authenticator SHALL be verified before the RP subscriber account is associated with an authenticated session, as discussed in Sec. 3.16.

The authenticated session MAY be ended by the RP at any time.

See [SP800-63B] Sec. 5 for more information about session management requirements for both IdPs and RPs. For additional session requirements with general purpose IdPs, see Sec. 4.7.

In practice: After a federated sign-in, the application starts its own session for the user, with its own lifetime and re-sign-in rules set by the application owner.

Signed Assertion

Assertions SHALL be cryptographically signed by the issuer (IdP). The RP SHALL validate the digital signature or MAC of each such assertion based on the issuer’s verification key. This signature SHALL cover the entire assertion, including its identifier, issuer, audience, subject, and time validity window.

The assertion signature SHALL either be a digital signature using asymmetric keys or a MAC using a symmetric key that is shared between the RP and issuer with approved cryptography.

In practice: The identity provider signs every sign-in message with its certificate, and each connected application checks that signature before letting a user in.

Audience Restriction

Assertions SHALL use audience restriction techniques to allow an RP to recognize whether it is the intended target of an issued assertion. All RPs SHALL check that the audience of an assertion contains an identifier for their RP to prevent the assertion injection and replay of an assertion generated for one RP at another RP.

In order to limit the places that an assertion could successfully be replayed by an attacker, IdPs SHOULD issue assertions that are designated for only a single audience. Restriction to a single audience is required at FAL2 and above.

In practice: Each application is configured with its own recipient name, so a sign-in message meant for one application is turned away by another.

IdP Account Provisioning

In order to make subscriber accounts available through an IdP, the subscriber accounts need to be provisioned at the IdP. The means by which the subscriber account is provisioned to the IdP SHALL be disclosed in the trust agreement.

Due to the requirement for the IdP to be able to authenticate the subscriber, the IdP is often a service of the CSP and has some level of access to the attributes and authenticators in the subscriber account. Such IdPs are generally in the same security domain as the identity and access management system that houses the subscriber account.

In other cases, one or more authenticators in the subscriber account can be verified outside of the security domain, such as authenticators tied to a common PKI. In these cases, the IdP can pull subscriber attributes and account information from the authenticator to provide a federated login to RPs.

The IdP augments the subscriber account with federation-specific attributes, such as a federated identifier. The IdP can collect additional attributes for federation purposes subject to the privacy and storage requirements enumerated by the trust agreement.

The CSP can provide attributes from the subscriber account to the IdP as attribute values, derived attribute values, or attribute bundles. The CSP SHALL sign attribute bundles issued to the IdP.

After the subscriber account is provisioned to the IdP, the CSP is party to the trust agreement but is not directly involved in the federation transaction.

Consequently, even if the RP fetches attributes through an identity API that is hosted by the CSP, the identity API is considered a function of the IdP and not the CSP for the purposes of these guidelines.

In practice: Joiner and mover requests are signed off in the access request workflow, and the identity system creates and updates the account in the identity provider automatically.

Federation Transaction

A federation transaction that involves a general-purpose IdP establishes the subscriber account at the IdP and culminates in an authenticated session for the subscriber at the RP. This process is shown in Fig. 6.

[figure omitted]

A federation transaction is a multi-stage process:

• Before federation can occur, the subscriber account is established by the CSP. This account binds the identity attributes collected by the CSP to a set of authenticators used by the subscriber.
• The subscriber account is provisioned at the IdP. The IdP augments the subscriber account with federation-specific attributes, such as a federated identifier.
• The IdP and RP begin a federated authentication transaction to authenticate a subscriber to the RP.
• The subscriber authenticates to the IdP using an authenticator that is bound to the subscriber account. If mandated by the trust agreement, the authorized party (often the subscriber) is prompted to approve the release of identity information at runtime.
• The IdP creates an assertion to represent the results of the authentication event. The assertion is based on the terms established by the trust agreement, the request from the RP, the capabilities of the IdP, the subscriber account known to the IdP, and the attributes permitted by the authorized party.
• The assertion is passed to the RP across the network.
• The RP processes this assertion from the IdP and establishes an authenticated session with the subscriber. Optionally, the RP receives identity attributes from the IdP that represents the subscriber account, either in the assertion or through an identity API.

In practice: Each business application is set up with a standard single sign-on flow, so employees sign in once through the identity provider and then open the application.

Manual Registration

At all FALs, the cryptographic keys and identifiers of the RP and IdP can be exchanged in a manual process, whereby the system administrator of the RP submits the RP’s configuration to the IdP either directly or through a trusted third party and receives the identifier to use with that IdP. The RP system administrator then configures the RP with this identifier and any additional information needed for the federation transaction to continue.

As this is a manual process, the registration happens prior to the federation transaction.

This process MAY be facilitated by some level of automated tooling, whereby the manual configuration points the systems in question to a trusted source of information that can be updated over time. If such automation is used, the trust agreement SHALL enumerate the allowable terms of the cryptographic key distribution and assignment, including allowable cache lifetimes.

In practice: An administrator creates each application registration by hand, and a second person reviews the redirect addresses and certificates before it goes live.

Subscriber Authentication at the IdP

In a federation context, the IdP acts as the verifier for authenticators bound to the subscriber account, as described in [SP800-63B].

Verification of one or more authenticators creates an authentication event that begins the authenticated session at the IdP. This authentication event serves as the basis of the IdP’s claim that the subscriber is present.

The IdP SHALL require the subscriber to have an authenticated session before any of the following events:

• Approval of attribute release
• Creation and issuance of an assertion
• Establishment of a subscriber-driven trust agreement

Additional requirements for session management and reauthentication are discussed in Sec. 4.7.

In practice: Within a federation, the identity provider checks the user's sign-in method, and an authentication method policy decides what each application requires.

Provisioning Models for RP Subscriber Accounts

The life cycle of the provisioning process for an RP subscriber account varies based on factors including the trust agreement discussed in Sec. 3.5 and the deployment pattern of the IdP and RP. However, in all cases, the RP subscriber account SHALL be provisioned at the RP prior to the establishment of an authenticated session at the RP in one of the following ways:

Just-In-Time Provisioning

An RP subscriber account is created the first time that the RP receives an assertion with an unknown federated identifier from an IdP, an RP subscriber account does not exist, or an existing RP subscriber account can be resolved using an account resolution process, as described in Sec. 3.8.2. Any identity attributes learned during the federation process, either within the assertion or through an identity API as discussed in Sec. 3.12.3, MAY be associated with the RP subscriber account. Accounts that are provisioned in this way are bound to the federated identifier in the assertion used to provision them.

This is the most common form of provisioning in federation systems, as it requires the least coordination between the RP and IdP. However, in such systems, the RP SHALL be responsible for managing any cached attributes it might have. See Fig. 7.

In practice: Application accounts are created through automatic provisioning, such as a standard connector that pushes new users, or created at first sign-in.

Attribute Synchronization

In a federated process, the IdP and RP each have their own stores of identity attributes that are associated with the subscriber account. The IdP has a direct view of the subscriber account’s attributes, but the RP subscriber account is derived from a subset of attributes that are presented during the federation transaction. Therefore, it is possible for the IdP and RP’s attribute stores to diverge from each other over time.

From the RP’s perspective, the IdP is the trusted source for any attributes that the IdP asserts as being associated with the subscriber account at the IdP.

However, the RP MAY collect and optionally verify other attributes to associate with the RP subscriber account, as discussed in Sec. 4.6.6.

While it is possible for the IdP to proactively push updated attributes to the RP with every assertion, this practice exposes personal information on every transaction. To limit the amount of personal information sent at each transaction, the IdP SHOULD signal downstream RPs when the attributes of a subscriber account available to the RP have been updated. RPs MAY respond to this signal by requesting the new attributes from the IdP and updating the RP subscriber account. This synchronization can be accomplished by using shared signaling (see Sec. 4.8), through a provisioning API (see Sec. 4.6.5), or by signaling the RP (e.g., by providing a timestamp of when the subscriber account attributes were last updated) to request updated attributes through an identity API (see Sec. 3.12.3).

If the RP is granted access to an identity API, the IdP SHOULD allow the RP to access the identity API for sufficient time to perform synchronization operations after the federation transaction has concluded.

In practice: When someone's department or title changes in HR, attribute mappings push the change to connected applications, and reconciliation reports flag differences.

Provisioning APIs

As part of pre-provisioning, the RP can be given access to subscriber attributes through a general-purpose identity API known as a provisioning API. This type of API allows an IdP to push attributes for a range of subscriber accounts and sometimes allows an RP to directly query the attributes of these subscriber accounts. Since access to the API is granted outside of the context of a federation transaction, access to the provisioning API for a given subscriber does not indicate to the RP that a given subscriber has been authenticated.

The attributes in the provisioning API that are available to a given RP SHALL be limited to only those necessary for the RP to perform its functions, including any audit and security purposes, as discussed in Sec. 3.10.1. As part of establishing the trust agreement, the IdP SHALL document when an RP is given access to a provisioning API, including at least the following:

• The purpose for the access using the provisioning model
• The set of attributes made available to the RP
• Whether the API functions as a push to the RP, a pull from the RP, or both
• The population of subscribers whose attributes are made available to the RP

Access to the provisioning API SHALL occur over a mutually authenticated protected channel. The exact means of authentication varies depending on the specifics of the API and whether it is a push model (i.e., the IdP initiates the connection to the RP) or a pull model (i.e., the RP initiates the connection to the IdP).

In practice: A standard provisioning connector lets the identity system read and write user records in an application, using a scoped service account that has only needed permissions.

Time-Based Removal of RP Subscriber Accounts

If an RP is using a just-in-time provisioning mechanism, the RP only learns of the existence of a subscriber account when that account is first used at the RP. If the IdP does not inform the RP of terminated subscriber accounts using shared signaling (see Sec. 4.8), an RP could accumulate RP subscriber accounts that are no longer accessible from the IdP. This poses a risk to the RP for holding personal information in the RP subscriber accounts and providing potentially exploitable accounts for an attacker to target. In such circumstances, the RP MAY employ a time-based mechanism to identify RP subscriber accounts for termination that have not been accessed after a period of time that is tailored to the usage patterns of the application. For example, an RP that is usually accessed on a weekly basis could set a timeout of 120 days since last access at the RP to mark the RP subscriber account for termination. An RP that expects longer gaps between access (e.g., a service used annually) should have a much longer time frame for time-based termination, such as five years.

When processing an inactive account, the RP SHALL provide sufficient notice to the subscriber about the pending termination of the account and provide the subscriber with an option to re-activate the account prior to its scheduled termination. Upon termination, the RP SHALL remove all personal information associated with the RP subscriber account in accordance with Sec. 3.11.3.

In practice: Applications that create accounts at first sign-in remove accounts after a long period of no activity, using a deprovisioning rule set by the application owner.

Reauthentication and Session Requirements in Federated Environments

In a federated environment, the RP manages its sessions separately from any sessions at the IdP. The assertion is related to both sessions, but its validity period is ultimately independent of them.

As shown in Fig. 10, an assertion is created during an authenticated session at the IdP, and processing an assertion creates an authenticated session at the RP. The validity time window of an assertion is used to manage the RP’s processing of the assertion but does not indicate the lifetime of the authenticated session at the IdP or RP. If a request comes to the IdP for a new federation transaction while the subscriber’s session is still valid at the IdP, a new and separate assertion would be created with its own validity time window. Similarly, after the RP consumes the assertion, the validity of the RP’s session is independent of the validity of the assertion. In most cases, the authenticated session at the RP will far outlive the validity of the assertion. Access granted to an identity API is likewise independent of the validity of the assertion or the lifetime of the authenticated session at the RP.

[figure omitted]

The IdP terminating the subscriber’s session at the IdP will not necessarily terminate any sessions that subscriber might have at downstream RPs. The RP and IdP MAY communicate end-session events to each other if supported by the federation protocol or through shared signaling (see Sec. 4.8).

In practice: The application and the identity provider each run their own sessions, so administrators set a reauthentication interval and session lifetime for both.

Fair Evidence Requirements

To be considered FAIR, identity evidence SHALL meet all of the following requirements:

• There is a reasonable expectation that the issuing source of the evidence confirmed the claimed identity by following formal procedures designed to provide assurance that the claimed identity is associated with the subject, such as evidence issued by financial institutions that have customer identity verification obligations under the Customer Identification Program (CIP) rule or procedures for establishing a mobile phone account with a mobile network operator (MNO).
• The evidence has an issuance process that results in the delivery of the evidence to the person to whom it relates, such as delivery to a postal address, issuance in person, or through a protected remote provisioning process.
• The evidence contains the name of the claimed identity.
• The evidence contains at least one reference number, a facial image or other biometric characteristic, or sufficient attributes to uniquely identify the person to whom it relates.
• The evidence contains physical (e.g., security printing, optically variable features, holograms) or digital (e.g., digitally signed assertions, addressable SIM or ESIM) security features that make it difficult to reproduce.
• Core attributes on the evidence can be validated against information held by an authoritative or credible source, as described in Sec. 2.4.2.4.
• The evidence can be validated through an approved method, as provided in Sec. 2.4.2.2.
• The evidence can support the identity verification process, as described in Sec. 2.5.1.

In practice: Where onboarding borrows these evidence tiers, the procedure lists which documents count as fair evidence for lower-risk roles, and the onboarding record notes which one was checked.

Strong Evidence Requirements

In order to be considered STRONG, identity evidence SHALL meet all of the following requirements:

• There is a reasonable expectation that the issuing source of the evidence confirmed the claimed identity by following written procedures (e.g., identity proofing at IAL2 or above) designed to provide assurance that the claimed identity is associated with the subject. Additionally, these procedures are subject to recurring oversight by regulatory or publicly accountable institutions, such as states, the Federal Government, and some regulated industries.
• The evidence has an issuance process that results in the delivery of the evidence to the person to whom it relates, such as delivery to a postal address, issuance in person, or through a protected remote provisioning process.
• The evidence contains the name of the claimed identity.
• The evidence contains a reference number or other attributes that uniquely identify the person to whom it relates.
• The evidence contains a facial image or other biometric characteristic of the person to whom it relates.
• The evidence contains physical (e.g., security printing, optically variable features, holograms) or digital security (e.g., digitally signed assertions, addressable SIM or ESIM) features that make it difficult to reproduce.
• Core attributes on the evidence can be validated against information held by authoritative or credible sources, as described in Sec. 2.4.2.4.
• The evidence can be validated through an approved method, as provided in Sec. 2.4.2.2.
• The evidence can support the identity verification process, as described in Sec. 2.5.1.

In practice: In onboarding modeled on these tiers, roles with more sensitive access call for documents that count as strong evidence, and the onboarding record shows which kind was seen.

Superior Evidence Requirements

In order to be considered SUPERIOR, identity evidence SHALL meet all of the following requirements:

• The issuing source of the evidence confirmed the claimed identity by following written procedures (e.g., identity proofing at IAL2 or above) designed to enable it to have high confidence that the claimed identity is associated with the subject. Additionally, these procedures are subject to recurring oversight by regulatory or publicly accountable institutions, such as states, the Federal Government, and some regulated industries.
• The identity evidence contains attributes and data objects that are cryptographically protected and can be validated using approved cryptography through verification of a digital signature applied by the issuing source.
• The issuing source had the subject participate in an attended enrollment and identity proofing process that confirmed their physical existence.
• The evidence has an issuance process that results in the delivery of the evidence to the person to whom it relates, such as delivery to a postal address, issuance in person, or through a protected remote provisioning process.
• The evidence contains the name of the claimed identity.
• The evidence contains at least one reference number that uniquely identifies the person to whom it relates.
• The evidence contains a facial image or other biometric characteristic of the person to whom it relates.
• The evidence contains physical (e.g., security printing, optically variable features, holograms) or digital security (e.g., digitally signed assertions, addressable SIM or ESIM) features that make it difficult to reproduce.
• The evidence can be validated through an approved method, as provided in Sec. 2.4.2.2.

In practice: When an organization adapts these tiers to hiring, its highest-risk roles call for the strongest documents, and the onboarding record shows which one was checked and by whom.

Identity Service Documentation and Records

The CSP SHALL conduct its operations according to documented procedures or a practice statement that details all identity proofing processes as they are implemented to achieve the defined IAL. These documented procedures SHALL include, at a minimum:

• A complete service description, including the particular steps that the CSP follows to identity-proof applicants at each offered assurance level
• The CSP’s policy for providing notice to applicants about the types of identity proofing processes available, the evidence and attribute collection requirements for the IALs offered by the CSP, the purpose for collecting personal information (see Sec. 3.3.2), and the purposes for collecting, using, and retaining biometrics (see Sec. 3.1.11)
• The CSP’s policy for ensuring that the identity proofing process concludes in a timely manner once the applicant has met all of the requirements
• The types of evidence that the CSP accepts and the justification for how the evidence fulfills the strength requirements of the level at which it will be accepted by the CSP
• The CSP’s policy and process for validating and verifying identity evidence, including training and qualification requirements for personnel who serve in identity proofing roles, as provided in Sec. 2.1.2
• The specific technologies that the CSP employs for evidence validation and verification
• The CSP’s policy and processes for supporting applicants who lack sufficient identity evidence for the required IAL (Sec. 3.15) and for addressing identity proofing exceptions and errors
• The attributes that the CSP considers to be core attributes (Sec. 2.2) and the authoritative and credible sources it uses for validating those attributes (Sec. 2.4.2.4)

In practice: Onboarding steps are written down in a procedure, and each new hire's proofing record is stored and linked to their identity so a reviewer can find it later.

CSP Fraud Management

• CSPs SHALL establish and maintain a fraud management program that provides fraud identification, detection, investigation, reporting, and resolution capabilities. The specific capabilities and details of this program SHALL be documented within their CSP practice statement.
• CSPs SHALL conduct a privacy risk assessment of all fraud checks and fraud mitigation technologies prior to implementation.
• The CSP SHALL establish a self-reporting mechanism and investigation capability for subjects who believe they have been the victim of fraud or an attempt to compromise their involvement in the identity proofing processes.
• CSPs SHALL analyze all remote proofing communication channels to look for high-risk indicators (e.g., blocklisted proxies and IP addresses).
• The CSP SHALL take measures to prevent unsuccessful applicants from inferring the accuracy of any self-asserted information with that confirmed by authoritative or credible sources.
• CSPs SHALL monitor the performance of their fraud checks and fraud mitigation technologies to ensure continued effectiveness in mitigating fraud risks.
• CSPs SHALL establish a technical or process-based mechanism to communicate suspected and confirmed fraudulent events to RPs.
• CSPs SHALL implement a death records check for all identity proofing processes by confirming with a credible, authoritative, or issuing source that the applicant is not deceased. Such checks can aid in preventing synthetic identity fraud, the use of stolen identity information, and exploitation by a close associate or relative.

In practice: The fraud team runs the enrollment fraud program; identity sends it sign-in and enrollment signals, such as many new accounts from one source, so it can investigate.

Requirements for Confirmation Codes

This section includes requirements for CSPs that support the use of confirmation codes.

Confirmation codes are used to confirm that an applicant has access to a postal address, email address, or phone number for the purposes of future communications. Confirmation codes delivered to a postal or phone address can also be used as an identity verification option at IALs 1 and 2, as described in Sec. 4.1.6 and Sec. 4.2.6.

Confirmation codes used for these purposes SHALL include at least 6 decimal digits (or equivalent) from an approved random bit generator (see Sec. 3.2.12 of [SP800-63B]). The confirmation code may be presented as numeric or printable ASCII representation for manual entry, a secure (e.g., https) link containing a representation of the confirmation code, or a machine-readable optical label (e.g., QR code) that contains the confirmation code.

Confirmation codes SHALL be valid for at most:

• 21 days when sent to a validated postal address within the contiguous United States
• 30 days when sent to a validated postal address outside of the contiguous United States
• 10 minutes when sent to a validated telephone number (SMS or voice)
• 24 hours when sent to a validated email address

Upon its use, the CSP SHALL invalidate the confirmation code.

In practice: A new hire receives a one-time code at a contact address on file and enters it during setup, which confirms they control that channel before the account is activated.

Requirements for Notifications of Identity Proofing

Notifications of proofing are sent to the applicant’s validated address to inform them that they have been successfully identity-proofed and provide them with information about the identity proofing event and subsequent enrollment. Additionally, the notification explains how the recipient can dispute their involvement in the identity proofing events.

The following requirements apply to notifications of proofing at any IAL:

• SHALL be sent to a validated postal address or phone number at all IALs or MAY be sent to a validated email address at IAL1
• SHALL include details about the identity proofing event, including the name of the identity service and the date on which the identity proofing was completed
• SHALL provide clear instructions, including contact information, on actions for the recipient to take if they repudiate their participation in the identity proofing event
• SHALL provide information about how the organization or CSP protects the security and confidentiality of the information it collects
• SHALL provide information about any responsibilities that the recipient has as a subscriber of the identity service
• SHOULD provide instructions on how to access their subscriber account or information about how the subscriber can update the information contained in that account

If a subscriber repudiates having been identity-proofed by the identity service, the CSP or RP SHALL respond in accordance with its established fraud management and redress policies.

In practice: After onboarding, the new hire gets a message at their registered address saying their identity was verified, so they would notice if someone else had been proofed in their name.

Elevating Subscriber IALs

CSPs SHOULD allow subscribers to elevate IALs related to their subscriber accounts to support higher assurance transactions with RPs. For CSPs that support these functions, the following requirements apply:

• CSPs SHALL document their approved approaches for elevating assurance levels in their practice statements.
• CSPs SHALL require subscribers to authenticate at the highest authentication assurance level (AAL) available on their account prior to initiating the upgrade process.
• CSPs SHALL collect, validate, and verify additional evidence, as mandated to achieve the higher IAL.
• CSPs SHOULD avoid collecting, validating, and verifying previously processed evidence, though they MAY do so based on an extended period of account inactivity, indicators of fraud, or if evidence has become invalidated since the original proofing event.

In practice: A person who starts in a low-risk role and later needs higher-risk access completes a stronger verification step first, and the identity system records the higher level.

IAL1: Evidence Validation

Each piece of evidence presented SHALL be validated using one of the following methods:

• Confirming the authenticity of digital evidence by interrogating the digital security features (e.g., signatures on assertions or data)
• Confirming the authenticity of physical evidence using automated scanning technology that can detect physical security features, as described in Sec. 3.14
• Confirming the integrity of physical security features on presented evidence through visual inspection by a proofing agent using real-time or asynchronous processes (e.g., offline manual review)
• Confirming the integrity of physical security features through physical and tactile inspection by a proofing agent at an on-site location

In practice: For lower-risk roles, HR checks that the document a new hire presents looks genuine and is still valid, and records the result in the onboarding case.

IAL1: Verification Requirements

The CSP SHALL verify the applicant’s ownership of one piece of evidence using one of the following methods:

• Confirming the applicant’s ability to return a confirmation code delivered to a validated address associated with the evidence
• Confirming the applicant’s ability to return a microtransaction value delivered to a validated financial or similar account
• Confirming the applicant’s ability to successfully complete an authentication and federation protocol equivalent to AAL2/FAL2 or higher to access an account related to the identity evidence
• Comparing the applicant’s facial image to a facial portrait on evidence via an automated comparison
• Visually comparing the applicant’s facial image to a facial portrait on evidence or in records associated with the evidence during an on-site attended session (i.e., in-person with a proofing agent), a remote attended session (i.e., live video with a proofing agent), or an asynchronous process (i.e., visual comparison made by a proofing agent at a different time). If the comparison is performed asynchronously at a later time, the CSP SHALL implement PAD and passive or active document presence checks to increase confidence that both the live applicant and physical documents are present during the submission or capture event.
• Using automated means to compare a facial image represented on or stored in the identity evidence or in records associated with the evidence to a live sample provided by the applicant

In practice: For lower-risk roles, a new hire shows that the document is really theirs, for example by matching it to a photo, and HR records that check in the onboarding case.

IAL1: Notification of Proofing

Upon the successful completion of identity proofing at IAL1, the CSP SHALL send a notification of proofing to a validated address for the applicant, as specified in Sec. 3.10.

In practice: When a lower-risk onboarding check finishes, the person receives an automatic notice at their registered address, so a proofing they did not start would stand out.

IAL2: Evidence Validation

• Each piece of FAIR or STRONG evidence that is presented SHALL be validated using one of the following techniques:
• Confirming the authenticity of the digital evidence by interrogating the digital security features (e.g., signatures on assertions or data)
• Confirming the authenticity of the physical evidence using automated scanning technology that can detect physical security features
• Confirming the integrity of any physical security features through a visual inspection by a proofing agent using a real-time or asynchronous process (e.g., offline manual review)
• Confirming the integrity of any physical security features through physical and tactile inspection by a proofing agent at an on-site location
• Each piece of SUPERIOR evidence SHALL be validated through the cryptographic verification of the evidence contents and the issuing source, including digital signature verification and the validation of any trust chain back to a trust anchor. Any piece of SUPERIOR evidence that cannot be validated using this method MAY be considered STRONG evidence if it can be validated by using one of the techniques provided above.

In practice: HR or a verification service checks that each document a remote or in-person hire presents is genuine and unexpired, and the case record keeps the outcome.

IAL2: Verification Requirements

Verification pathways SHOULD be implemented consistent with relevant policy and be responsive to the use cases, populations, and threat environment of the online service being protected. CSPs SHOULD deploy more than one pathway to IAL2 verification and MAY combine pathways in order to achieve desired outcomes.

CSPs that offer multiple verification pathways SHALL record in the subscriber record which pathways were followed to achieve IAL2 and SHALL make that information available to RPs in the assertion, API, or as part of their trust agreement. When the Non-Biometric Pathway is used, the CSP SHALL additionally record whether a mailed confirmation code or a visual comparison of the applicant against evidence was used for verification.

In practice: A new hire is verified either remotely, for example by a live video check, or in person, and the onboarding case records which route was used and what the result was.

IAL2: Notification of Proofing

Upon the successful completion of identity proofing at IAL2, the CSP SHALL send a notification of proofing to a validated address for the applicant, as specified in Sec. 3.10. CSPs SHOULD send the notification of proofing to the applicant’s postal address.

In practice: Once identity verification finishes for a hire, the system sends a notice to their registered address, so the person knows verification took place.

IAL3: Evidence Validation

• Each piece of FAIR or STRONG evidence that is presented SHALL be validated using one of the following techniques:
• Confirming the authenticity of the digital evidence by interrogating the digital security features (e.g., signatures on assertions or data)
• Confirming the authenticity of the physical evidence using automated scanning technology that can detect physical security features
• Confirming the integrity of any physical security features through a visual inspection by a proofing agent using a real-time or asynchronous process (e.g., offline manual review)
• Confirming the integrity of any physical security features through physical and tactile inspection by a proofing agent at an on-site location
• Each piece of SUPERIOR evidence SHALL be validated through the cryptographic verification of the evidence contents and the issuing source, including digital signature verification and the validation of any trust chain back to a trust anchor. Any piece of SUPERIOR evidence that cannot be validated using this method MAY be considered STRONG evidence if it can be validated by using one of the techniques provided above.

In practice: For the highest-risk roles, HR validates each strong document a hire brings, and the onboarding record shows which checks were done and who performed them.

IAL3: Verification Requirements

• The CSP SHALL verify the applicant’s ownership of the strongest piece of evidence (STRONG or SUPERIOR) by one of the following methods:
• Confirming the applicant’s ability to successfully authenticate to a physical device or application (e.g., a mobile driver’s license) and comparing a digitally protected and transmitted facial portrait to the applicant
• Comparing the applicant’s facial image to the facial portrait on the presented evidence via an automated comparison
• Visually comparing the applicant’s facial image to the facial portrait on the presented evidence during an on-site attended session or a remote attended session
• Performing an automated comparison of a stored biometric on the identity evidence or in the authoritative records associated with the evidence to a sample provided by the applicant

In practice: For the most sensitive roles, a trained staff member meets the new hire in person, compares them to the strongest document, and logs the result in the onboarding case.

IAL3: Notification of Proofing

Upon the successful completion of identity proofing at IAL3, the CSP SHALL send a notification of proofing to a validated address for the applicant, as specified in Sec. 3.10. CSPs SHOULD send the notification of proofing to the applicant’s postal address.

In practice: After in-person proofing for a high-risk role, the person gets an automatic notice at their registered address, so they know the verification was completed.

Subscriber Accounts

The CSP SHALL establish and maintain a unique subscriber account for each active subscriber in its identity system from the time of enrollment to the time of account closure. The CSP establishes a subscriber account to record each subscriber as a unique identity within its identity service and to maintain a record of all authenticators associated with that account.

The CSP SHALL assign a unique identifier to each subscriber account. The identifier SHOULD be randomly generated by the CSP’s system and of sufficient length and entropy to ensure uniqueness within its user population and to support federation with RPs, where applicable. The identifier MAY be used as a subject identifier in the generation of assertions, consistent with [SP800-63C].

At a minimum, the CSP SHALL include the following information in each subscriber account:

• The unique identifier associated with the subscriber account
• Any subject identifiers established for the subscriber, including any RP-specific subject identifiers
• A record of the identity proofing steps completed for the subscriber, including:
• The type and issuer of identity evidence
• The type of proofing (i.e., remote unattended, remote attended, on-site attended, on-site unattended)
• The validation and verification methods used
• The use of a trusted referee or other exception handling process
• The use of an applicant reference, including a unique identifier for the applicant reference
• Maximum IAL successfully achieved for the identity proofing of the subscriber
• Records of any applicant consent agreements related to the collection and processing of information about the applicant throughout the subscriber account life cycle, including biometrics

In practice: Each active employee or contractor has exactly one account in the directory, matched to a single identity record, so activity can be traced back to one person.

Subscriber Account Access

The CSP SHALL provide the capability for subscribers to authenticate and access information in their subscriber account.

For subscriber accounts that contain personal information, this capability SHALL be accomplished through AAL2 or AAL3 authentication processes using authenticators that are registered to the subscriber account.

In practice: Employees view their own profile in a self-service portal after signing in with MFA, because the profile holds personal details; administrators face stricter sign-in rules.

Multiple Subscriber Account Scenarios

Some CSPs need to support a single user’s ability to interact with the CSP while fulfilling different roles or personas. For example, a subscriber may interact as themselves and also as a representative of a business across different services supported by the CSP. Another scenario is a CSP that serves both commercial and federal RPs and must maintain a separation between its services. To limit fraud and avoid redundant costs and processes, CSPs SHOULD provide users with a means to manage multiple user personas without having to create multiple subscriber accounts. If this is not possible, and multiple subscriber accounts are supported for a single subscriber, the CSP SHOULD implement its subscriber accounts in a manner that avoids unnecessary re-proofing of the same subscriber (e.g., linking accounts via a common identifier or through biometric or attribute resolution).

If multiple subscriber accounts are permitted for a single subscriber, the following requirements apply:

• The CSP SHALL develop and document their process for reviewing and assessing subscribers with multiple accounts to identify possible fraud.
• The CSP SHALL maintain a mapping of all accounts associated with a unique government identifier or common core attributes.
• The CSP SHALL provide individuals with visibility into the full list of subscriber accounts associated with their identity.
• The CSP SHOULD allow subscribers to block the creation of additional accounts using their personal information.

Similar scenarios can also occur when RPs use the services of multiple CSPs. This is known as account linking, and Sec. 3.8.1 of [SP800-63C] describes the association of an RP subscriber account with multiple CSP/IdP accounts.

In practice: A contractor who is also a part-time employee has two accounts, and the identity governance platform links both to one person so access for each role can be reviewed together.

Security Controls

The verifier SHALL employ appropriately tailored security controls from the moderate baseline security controls defined in [SP800-53] or an equivalent federal (e.g., [FEDRAMP]) or industry standard that the organization has chosen for the information systems, applications, and online services that these guidelines are used to protect.

In practice: The architecture document for the sign-in service lists the security controls chosen from a baseline, and the identity team keeps that list with the design.

Records Retention Policy

The verifier SHALL comply with its respective records retention policies in accordance with applicable laws, regulations, and policies, including any National Archives and Records Administration (NARA) records retention schedules that may apply. If the verifier opts to retain records in the absence of mandatory requirements, the verifier or the CSP or IdP of which it is a part SHALL conduct a risk management process [NISTRMF], including assessments of privacy and security risks, to determine how long records should be retained and SHALL inform the subscriber of that retention policy.

In practice: The identity provider logs sign-ins and authenticator changes, and those logs are kept for the period the organization's retention policy sets.

Look-Up Secret Authenticators

CSPs that create look-up secret authenticators SHALL use an approved random bit generator, as described in Sec. 3.2.12, to generate the list of secrets and SHALL deliver the authenticator list securely to the subscriber (e.g., in an in-person session, via an online session, through the postal mail to a contact address). If delivered via an online session, the session SHALL be authenticated by the subscriber at AAL2 or higher and SHALL deliver the secrets through an authenticated protected channel and in accordance with the post-enrollment binding requirements in Sec. 4.1.2. Look-up secrets SHALL be at least six decimal digits (or equivalent) in length. Additional requirements described in Sec. 3.1.2.2 may also apply, depending on their length.

In practice: Where the platform supports backup codes, a user can generate a set of random codes at MFA registration and store them safely for use if their main device is lost.

Look-Up Secret Verifiers

Verifiers of look-up secrets SHALL prompt the claimant for a secret from their authenticator. A secret from a look-up secret authenticator SHALL be used successfully only once. If the look-up secret is derived from a grid card, each grid cell SHOULD be used only once, which limits the number of authentications that can be accomplished using look-up secrets. A very long list of secrets is potentially required.

Verifiers SHALL store look-up secrets in a form that is resistant to offline attacks. All look-up secrets SHALL be stored in a hashed form using an approved hashing function.

Look-up secrets SHALL be at least six decimal digits (or equivalent) in length, as specified in Sec. 3.1.2.1. Look-up secrets that are shorter than specified lengths have additional verification requirements as follows:

• Look-up secrets that are shorter than the minimum security strength specified in the latest revision of [SP800-131A] (i.e., 112 bits as of the date of this publication) SHALL be stored in a salted and hashed form using a suitable password hashing scheme, as described in Sec. 3.1.1.2. The salt value SHALL be at least 32 bits in length and arbitrarily chosen to minimize salt value collisions among stored hashes. Both the salt value and the resulting hash SHALL be stored for each look-up secret.
• The verifier SHALL implement a rate-limiting mechanism that effectively limits the number of failed authentication attempts that can be made on the subscriber account, as described in Sec. 3.2.2.

The verifier SHALL use approved encryption and an authenticated protected channel when requesting look-up secrets.

In practice: Where backup codes are supported, a user who loses their phone enters one of their codes at sign-in, and the identity provider checks it and marks it as used.

Single-Factor OTP Authenticators

Single-factor OTP authenticators and verifiers contain two persistent values: 1) a symmetric key that persists for the authenticator’s lifetime and 2) a nonce that is either changed each time the authenticator is used or is based on a real-time clock.

The secret key and its algorithm SHALL provide at least the minimum security strength specified in the latest revision of [SP800-131A] (i.e., 112 bits as of the date of this publication). The nonce SHALL be of sufficient length to ensure that it is unique for each operation of the authenticator over its lifetime. If a subscriber needs to change the device on which a software-based OTP authenticator resides, they SHOULD bind the authenticator application on the new device to their subscriber account, as described in Sec. 4.1.2, and invalidate the authenticator application that will no longer be used. Alternatively, the subscriber MAY export the secret key and store it in a sync fabric that meets the requirements in Appendix B.2 and then retrieve the key with their new device.

The authenticator output is obtained using an approved block cipher or hash function to securely combine the key and nonce. In coordination with the verifier, the authenticator MAY truncate its output to as few as six decimal digits (or an equivalent representation).

If the nonce used to generate the authenticator output is based on a real-time clock, the nonce SHALL be changed at least once every two minutes.

In practice: Some older single-factor code tokens remain for low-risk uses, and administrators plan to retire them in favor of multi-factor methods over time.

Single-Factor OTP Verifiers

Single-factor OTP verifiers effectively duplicate the process of generating the OTP used by the authenticator. As such, the symmetric keys used by authenticators are also present in the verifier and SHALL be strongly protected against unauthorized disclosure by access controls that limit access to the keys to only those software components that require access.

When binding a single-factor OTP authenticator to a subscriber account, the verifier or associated CSP SHALL use approved cryptography for key establishment to generate and exchange keys or to obtain the secrets required to duplicate the authenticator output.

The verifier SHALL use approved encryption and an authenticated protected channel when collecting the OTP. Verifiers SHALL accept a given OTP only once while it is valid to provide replay resistance, as described in Sec. 3.2.7. If a claimant’s authentication is denied due to the duplicate use of an OTP, verifiers MAY warn the claimant if an attacker has been able to authenticate in advance. Verifiers MAY also warn a subscriber in an existing session of the attempted duplicate use of an OTP.

Time-based OTPs [TOTP] SHALL have a defined lifetime that is determined by the expected clock drift in either direction of the authenticator over its lifetime plus an allowance for network delay and claimant entry of the OTP.

The verifier SHOULD implement or, if the authenticator output is less than 64 bits in length, SHALL implement a rate-limiting mechanism that effectively limits the number of failed authentication attempts that can be made on the subscriber account, as described in Sec. 3.2.2.

In practice: The identity provider checks single-factor one-time codes, and policy sets how long each code stays valid and how many wrong attempts are tolerated.

Single-Factor Cryptographic Authenticators

Single-factor cryptographic authenticators encapsulate one or more authentication keys. Authentication keys are described as either exportable (see Sec. 3.2.13) or non-exportable. Exportable authentication keys (usable at AAL2 or below) SHOULD be stored in appropriate storage that is available to the authenticator (e.g., keychain storage). If they are accessible to the endpoint being authenticated, exportable authentication keys SHALL be strongly protected against unauthorized disclosure with access controls that limit access to the key to only those software components that require access. Non-exportable authentication keys (usable at AAL3 or below) SHALL be stored in an isolated execution environment that is protected by hardware or in a separate processor with a controlled interface to the central processing unit of the user endpoint.

Some cryptographic authenticators, referred to as syncable authenticators, can manage their authentication keys using a sync fabric (e.g., a cloud provider). Additional requirements for using syncable authenticators are in Appendix B.

External (i.e., non-embedded) cryptographic authenticators SHALL meet the requirements for connected authenticators in Sec. 3.2.11.

As required by Sec. 2.3.2, single-factor cryptographic authenticators that are being used at AAL3 must meet the authentication intent requirements of Sec. 3.2.8.

In practice: A user signs in with a certificate on a smart card or a device-bound user certificate together with a password, and the identity team tracks which certificates are issued to whom.

Single-Factor Cryptographic Verifiers

Single-factor cryptographic verifiers generate a challenge nonce, send it to the corresponding authenticator, and use the authenticator output to verify possession of the authenticator. The authenticator output is highly dependent on the specific cryptographic authenticator and protocol used but is generally some type of signed message.

The verifier has a public cryptographic key that corresponds to each authenticator. While both types of keys SHALL be protected against modification, symmetric keys SHALL additionally be protected against unauthorized disclosure by access controls that limit access to the key to only those software components that require access.

The authentication key and its algorithm SHALL provide at least the minimum security strength specified in the latest revision of [SP800-131A] (i.e., 112 bits as of the date of this publication). The challenge nonce SHALL be at least 64 bits in length and SHALL either be unique over the authenticator’s lifetime or statistically unique (i.e., generated using an approved random bit generator, as described in Sec. 3.2.12). The verification operation SHALL use approved cryptography.

In practice: When a user signs in with a smart card or user certificate, the identity provider sends a fresh challenge, checks the signed response against the registered key, and enforces the key strength and certificate validation settings the identity team maintains.

Usage With Subscriber-Controlled Wallets

A specific form of multi-factor cryptographic authentication is a subscriber-controlled wallet on the subscriber’s device, as described in Sec. 5 of [SP800-63C]. After the claimant first unlocks the wallet using an activation factor, the authentication process uses a federation protocol, as detailed in [SP800-63C]. The assertion contents and presentation requirements of the federation protocol provide the security characteristics required of cryptographic authenticators. As such, subscriber-controlled wallets on the subscriber’s device can be considered multi-factor authenticators through the activation factor and the presentation and validation of an assertion generated by the wallet.

Cloud-hosted wallets are not considered cryptographic multi-factor authenticators because access is maintained through authentication over the internet rather than locally. All authentication information from hosted wallets is treated as an assertion, as addressed in Sec. 5 of [SP800-63C].

Access to the private key SHALL require an activation factor. Authenticator activation secrets SHALL meet the requirements of Sec. 3.2.10. Biometric activation factors SHALL meet the requirements of Sec. 3.2.3, including limits on the number of consecutive authentication failures. The password or biometric sample used for activation and any biometric data derived from the biometric sample SHALL be erased immediately after an authentication transaction.

In practice: Some organizations are starting to let people sign in using a digital wallet on their phone, and the identity team pilots this as an emerging option.

Physical Authenticators

CSPs SHALL provide subscriber instructions for appropriately protecting the authenticator against theft or loss. The CSP SHALL provide a mechanism to invalidate the authenticator immediately upon notification from a subscriber that the authenticator’s loss, theft, or compromise is suspected.

Possession and control of a physical authenticator are based on proof of possession of a secret associated with the authenticator. When an embedded secret (typically a certificate and associated private key) is in the endpoint, its “device identity” can be considered a physical authenticator. However, this requires a secure authentication protocol that is appropriate for the AAL being authenticated. Browser cookies do not satisfy this requirement except as short-term secrets for session maintenance (not authentication), as described in Sec. 5.1.1.

In practice: When a user reports a lost or stolen security key or smart card, the help desk or a self-service page invalidates it at once, so it can no longer be used to sign in.

Attestation

The CSP needs to have a reliable basis for evaluating the characteristics of the authenticator, such as the inclusion of a signed attestation. An attestation is information conveyed to the CSP, generally when an authenticator is bound, regarding that connected authenticator or the endpoint involved in an authentication operation. Information conveyed by attestation MAY include but is not limited to:

• The provenance (e.g., manufacturer or supplier certification), health, and integrity of the authenticator and endpoint
• Security features of the authenticator
• Security and performance characteristics of biometric sensors
• Sensor modality
• Properties of the authentication key

Attestations SHALL be signed using a digital signature that provides at least the minimum security strength specified in the latest revision of [SP800-131A] (i.e., 112 bits as of the date of this publication).

Verifiers in federal enterprise systems SHOULD use attestation features to verify the capabilities and sources of authenticators. In other applications, attestation information MAY be used as part of a verifier’s risk-based authentication decisions.

In practice: Registration policy accepts only permitted security key models, and the identity provider checks the key's manufacturer statement when a user enrolls it.

Channel Binding

An authentication protocol with channel binding SHALL establish an authenticated protected channel with the verifier. The protocol SHALL then strongly and irreversibly bind a channel identifier negotiated in establishing the authenticated protected channel to the authenticator output (e.g., by signing the two values together using a private key controlled by the claimant for which the public key is known to the verifier). The verifier SHALL validate the signature or other information used to prove phishing resistance. This prevents an impostor verifier — even one that has obtained a certificate that represents the actual verifier — from successfully relaying that authentication on a different authenticated protected channel.

An example of a phishing-resistant authentication protocol that uses channel binding is client-authenticated TLS [RFC8446] in which the client signs the authenticator output along with earlier messages from the protocol that are unique to the particular TLS connection being negotiated. Personal identity verification (PIV) and common access card (CAC) cards, which use client-authenticated TLS, provide phishing resistance through channel binding.

In practice: The sign-in protocol itself links the session to the connection used, which is built into the authenticator and identity provider, and the identity team chooses compatible products.

Verifier Name Binding

An authentication protocol with verifier name binding SHALL establish an authenticated protected channel with the verifier. The protocol SHALL then generate an authenticator output that is cryptographically bound to a verifier identifier that is authenticated as part of the protocol. In the case of DNS identifiers, the verifier identifier SHALL be either the authenticated hostname of the verifier or a parent domain that is at least one level below the public suffix [PSL] associated with that hostname. The binding MAY be established by choosing an associated authenticator secret, deriving an authenticator secret using the verifier identifier, cryptographically signing the authenticator output with the verifier identifier, or using similar cryptographically secure means.

WebAuthn [WebAuthn], which is used by authenticators that implement the Fast Identity Online 2 (FIDO2) specifications [FIDO2], is an example of a standard that provides phishing resistance through verifier name binding by choosing an authenticator secret based on the authenticated domain name of the verifier.

In practice: Passkeys respond only to the real website address, so a look-alike site gets no usable response; the identity team sets the correct site address when configuring each application.

Replay Resistance

An authentication process resists replay attacks if it is impractical to achieve a successful authentication by recording and replaying a previous authentication message. Replay resistance is in addition to the replay-resistant nature of authenticated protected channel protocols since the output could be stolen before entry into the protected channel. Protocols that use nonces or challenges to prove the “freshness” of the transaction are resistant to replay attacks since the verifier will easily detect when old protocol messages are replayed because they will not contain the appropriate nonces or timeliness data. Examples of replay-resistant authenticators include OTP authenticators, cryptographic authenticators, and look-up secrets.

In contrast, passwords are not considered replay-resistant because the same authenticator output (i.e., the password itself) is provided for each authentication.

In practice: The identity team favors keys and short-lived tokens when selecting methods, because a recorded sign-in message from them is designed not to work if played back later.

Authentication Intent

An authentication process demonstrates intent if it requires the claimant to respond explicitly to each authentication or reauthentication request. The goal of authentication intent is to make it more difficult for authenticators (e.g., multi-factor cryptographic authenticators) to be used without the claimant’s knowledge, such as by malware on the endpoint. The authenticator itself SHALL establish authentication intent. Multi-factor authenticators MAY establish intent by reentry of the activation factor for the authenticator.

Authentication intent MAY be established in several ways. Authentication processes that require the claimant’s intervention can be used to prove intent (e.g., a claimant entering an authenticator output from an OTP authenticator). Cryptographic authenticators that require claimant action for each authentication or reauthentication operation can also be used to establish intent (e.g., by pushing a button or reinsertion).

The presentation of biometric characteristics does not always establish authentication intent. For example, using a front-facing camera on a mobile phone to capture a face biometric does not necessarily constitute intent, as it can be reasonably expected to capture a face image while the device is used for other non-authentication purposes. In these scenarios, an explicit mechanism (e.g., tapping a software or physical button) SHALL be provided to establish authentication intent.

In practice: A push prompt asks the user to type a number shown on the sign-in screen, which confirms a real person is present and means to sign in.

Activation Secrets

A password used locally as an activation factor for a multi-factor authenticator is referred to as an activation secret. An activation secret is used to obtain access to a stored authentication key. In all cases, the activation secret SHALL remain within the authenticator and its associated user endpoint.

Authenticators that use activation secrets SHALL require the secrets to be at least four characters in length and SHOULD require the secrets to be at least six characters in length. Activation secrets MAY be entirely numeric (i.e., a PIN). Otherwise, all printing ASCII [RFC20] characters, the space character, and Unicode [ISO/ISC 10646] characters SHOULD be permitted in activation secrets. The authenticator or its management tools SHOULD implement a blocklist to discourage subscribers from selecting commonly used activation secrets (e.g., 123456).

The authenticator or verifier SHALL implement a retry-limiting mechanism that limits the number of consecutive failed activation attempts using the authenticator to no more than 10. If an incorrect activation secret entry causes the authenticator to provide an invalid output to the central verifier, the verifier MAY implement this retry-limiting mechanism. Otherwise, retry limiting SHALL be implemented in the authenticator. Once the limit of attempts is reached, the authenticator SHALL be disabled, and a different authenticator SHALL be required for authentication.

For authenticators that are usable at AAL3, verification of activation secrets SHALL be performed in a hardware-protected environment (e.g., a secure element, TPM, or TEE). At AAL2, if a hardware-protected environment is not used, the authenticator SHALL use the activation secret to derive a key used to decrypt the authentication key.

In practice: The PIN or fingerprint a user enters to unlock a security key or passkey stays on the device, and identity staff explain this local unlock step to users.

Exportability

Exportability is the ability of an authenticator to replicate, share, or store its authentication keys outside of the protected boundary of the authenticator (e.g., copying it to another authenticator, backing up a key to a separate storage location). Generally, authentication keys are considered exportable unless the authenticator generates, stores, and uses the keys in a protected hardware environment that prevents software from accessing the keys, such as in a security coprocessor (e.g., TPM) or a dedicated device (e.g., a security key). This is intended to prevent software on the endpoint from copying or leaking the authentication secret. Non-exportable authentication keys are considered more secure, and accordingly, non-exportable cryptographic keys are required at AAL3. The authentication keys on syncable authenticators are inherently exportable (see Appendix B).

To be considered non-exportable, an authenticator SHALL either be a separate piece of hardware or an embedded processor or execution environment (e.g., secure element, TEE, TPM). These hardware authenticators and embedded processors are separate from a host processor, such as the CPU on a laptop or mobile device. A non-exportable authenticator SHALL be designed to prohibit the export of the authentication secret to the host processor and SHALL NOT be capable of being reprogrammed by the host processor to allow the secret to be extracted. The authenticator is subject to applicable [FIPS140] requirements. Organizations SHOULD employ authenticators that have undergone independent security testing, such as authenticators validated to [FIPS140] security level 2 overall with level 3 physical security or evaluated against relevant Common Criteria Protection Profiles.

In practice: For higher assurance, administrators prefer device-bound passkeys and hardware keys whose secrets cannot be copied off the device.

Binding Across Endpoints

It may be necessary for a subscriber to bind an authenticator to a subscriber account using a device that is different from the authenticated endpoint (i.e., the endpoint for the session being authenticated). This process is typically used when adding authenticators that are embedded in a new endpoint or when connectivity limitations prevent the newly bound authenticator from being connected to an authenticated endpoint.

The binding process SHALL proceed in one of the following ways:

• An endpoint that has authenticated to the CSP requests a binding code from the CSP. The binding code is input into the endpoint associated with the new authenticator and sent to the CSP.
• The endpoint associated with the new authenticator obtains a binding code from the CSP. The binding code is input to an authenticated endpoint and sent to the CSP.

In addition to the requirements in Sec. 4.1.2.1 and Sec. 4.2, the following requirements SHALL apply when binding an external authenticator:

• An authenticated protected channel SHALL be established by the endpoint associated with the new authenticator and the CSP.
• The subscriber MAY be prompted to enter an identifier by which the CSP knows them on the endpoint associated with the new authenticator.
• The CSP SHALL generate a binding code using an approved random bit generator, as described in Sec. 3.2.12 and send it to either the new authenticator endpoint or the authenticated endpoint approving the binding. The binding code SHALL be at least 40 bits in length if it is used with an identifier that was entered in the previous step. Otherwise, a binding code of at least 112 bits in length SHALL be required.

In practice: A user with a new laptop signs in with the passkey on their phone, then uses that session to register a new passkey on the laptop, binding it to the same account.

Saved Recovery Codes

At enrollment, a CSP that supports this recovery option SHOULD issue a recovery code to the subscriber. The recovery code SHALL include at least 64 bits from an approved random bit generator. The saved recovery code may be presented as numeric or a printable ASCII representation (e.g., Base64) for manual entry or as a machine-readable optical label (e.g., QR code) that contains the recovery code. At any point following enrollment, the subscriber MAY request a replacement recovery code. The issuance of a replacement recovery code SHALL result in an account recovery notification, as described in Sec. 4.6.

Saved recovery codes are intended to be maintained offline (e.g., printed or written down) and stored securely by the subscriber for future use. The verification of saved recovery codes SHALL be subject to the throttling requirements in Sec. 3.2.2. Saved recovery codes SHALL be stored in the subscriber account in hashed form using an approved one-way function, as described in Sec. 3.1.1.2. Following the use of a saved recovery code, the CSP SHALL invalidate that recovery code and SHALL issue a new saved recovery code to the subscriber.

In practice: Where the platform supports saved recovery codes, it offers a set at MFA registration for the user to store safely in case their main device is lost.

Recovery Contacts

CSPs that support the use of recovery contacts SHALL allow the subscriber to specify one or more addresses of trusted associates to receive issued recovery codes. The requirements for recovery contacts are very similar to those for issued recovery codes with the following exceptions:

• The validity time for recovery codes sent to recovery contacts MAY be extended by 24 hours (e.g., valid for no more than 24 hours and 10 minutes if sent via text messaging) to provide additional time for the recovery contact to communicate the recovery code to the subscriber.
• Confirmation of the recovery code address MAY also be extended by 24 hours to allow the recovery contact to send the confirmation code to the subscriber for entry.

If the CSP supports the use of recovery contacts, the CSP SHALL provide methods for subscribers to view and manage recovery contacts. CSPs SHOULD send a reminder annually to subscribers to review their list of recovery contacts.

In practice: If a user cannot recover alone, a colleague they registered in advance as a recovery contact receives a one-time recovery code and passes it to them to enter.

Account Recovery Notification

In all cases, account recovery SHALL cause a notification to be sent to the subscriber or their designee, as described in Sec. 4.6.

In practice: Whenever an account is recovered, the identity provider sends an alert to the user, so they would notice a recovery they did not start.

Expiration

CSPs MAY bind authenticators that expire to subscriber accounts. When an authenticator expires, it SHALL NOT be usable for authentication. When an authentication is attempted using an expired authenticator, the CSP SHOULD indicate to the subscriber that the authentication failure is due to expiration rather than some other cause.

The CSP SHOULD retrieve any authenticator that contains personal information or provide for its erasure or destruction promptly following expiration.

The replacement of expired authenticators SHALL conform to the binding process for an additional authenticator, as described in Sec. 4.1.2.

In practice: Where certificates or tokens issued to users carry an expiry date, the identity provider refuses them after that date until they are renewed.

Account Notifications

Certain subscriber account events (e.g., the binding of an authenticator, account recovery) require the subscriber or someone designated by them to be independently notified. These notifications help the subscriber detect possible fraud associated with their subscriber account.

Events that require notification SHALL cause a notification to be sent to the notification addresses stored in the subscriber account. Notification addresses may be any means by which the subscriber can be reliably contacted, such as:

• Postal address
• Email address
• Address (e.g., telephone number) to which a text message or voice message may be sent
• Reference to the subscriber in a push notification service

CSPs SHALL support at least two notification addresses per subscriber account. For subscriber accounts that have undergone identity proofing, at least one address SHALL have been validated during the identity proofing process. The CSP SHOULD allow subscribers with authentication at AAL2 or higher (or at AAL1 if that is the highest AAL available for the subscriber account) to update their notification addresses. The CSP SHOULD encourage the subscriber to maintain multiple notification addresses to improve the likelihood of contacting them if a contact address changes.

Notifications SHALL be sent to all notification addresses except postal addresses. However, notifications SHALL be sent to postal addresses if no other form of notification address is stored in the subscriber account or if the notification is for account recovery at AAL3. Account recovery notifications SHALL also be sent to a postal address if the only other notification address in the subscriber account is the address to which an issued recovery code was sent.

In practice: The identity provider emails or notifies a user when a new sign-in method is added or the account is recovered, so unexpected changes get noticed.

Browser Cookies

Browser cookies are the predominant mechanism by which a session is created and tracked when a subscriber accesses a service. Cookies are not authenticators but are suitable as short-term secrets for the duration of a session.

Cookies used for session maintenance:

• SHALL be tagged to be accessible only on secure (i.e., HTTPS) sessions.
• SHALL be accessible to the minimum practical hostnames and paths.
• SHOULD be tagged as inaccessible via JavaScript (i.e., HttpOnly).
• SHOULD be tagged to expire at or soon after the session’s validity period. This requirement is intended to limit the accumulation of cookies but SHALL NOT be relied upon to enforce session timeouts.
• SHOULD have the “__Host-“ prefix and set “Path=/”.
• SHOULD set “SameSite=Lax” or “SameSite=Strict”.
• SHOULD contain only an opaque string (e.g., a session identifier) and SHALL NOT contain cleartext personal information.

In practice: Web applications set session cookies as secure and short-lived; the identity provider and each application owner configure these settings.

Access Tokens

An access token (e.g., OAuth [RFC6749]) is used to allow an application to access a set of services on a subscriber’s behalf following an authentication event. The RP SHALL NOT interpret the presence of an access token as an indicator of the subscriber’s presence in the absence of other signals. The access token and any associated refresh tokens could be valid long after the authentication session has ended and the subscriber has left the application.

In practice: Access tokens given to applications are short-lived, tied to a named audience, and protected in transit, using settings the identity team manages.

Session Monitoring

Session monitoring (sometimes called continuous authentication) is the ongoing evaluation of session characteristics to detect possible fraud during a session. Session monitoring MAY be performed by the RP in coordination with the CSP or IdP and associated verifier as a risk reduction measure. When potential fraud is detected during a session, the RP SHOULD act in conjunction with the CSP, IdP, or verifier to reauthenticate, terminate the session, or notify appropriate support personnel. Session characteristics that MAY be evaluated include:

• Usage patterns, velocity, and timing
• Behavioral biometric characteristics (e.g., typing cadence)
• Device and browser characteristics (e.g., accepted languages)
• Geolocation
• IP address characteristics (e.g., whether the IP address is in a block known for abuse)

Most of these characteristics have privacy implications. Collection, the storage of expected subscriber characteristics, and the processing of session characteristics SHALL be included in the privacy risk assessment described in Sec. 7.

Session monitoring MAY be facilitated by the use of shared signaling between the RP and CSP or IdP, as described in [SP800-63C].

In practice: The security team watches for odd session behavior, and identity risk detections can ask a user to sign in again when something looks wrong.

Requesting and Processing xALs

Since an IdP is capable of asserting the identities of many different subscribers with a variety of authenticators using a variety of federation parameters, the IAL, AAL, and FAL could vary across different federation transactions, even to the same RP.

IdPs SHALL support a mechanism for RPs to specify a set of minimum acceptable xALs as part of the trust agreement and SHOULD support the RP specifying a more strict minimum set at runtime as part of the federation transaction. When an RP requests a particular xAL, the IdP SHOULD fulfill that request, if possible, or SHOULD fail the request if it cannot fulfil the RP’s requested xALs. The IdP SHALL always indicate the resulting xAL in the assertion, even if the request has not been met. For example, if the subscriber has an active session that was authenticated at AAL1, but the RP has requested AAL2, the IdP needs to prompt the subscriber for AAL2 authentication to increase the security of the session at the IdP during the subscriber’s interaction at the IdP, if possible. The IdP sends the resulting AAL as part of the returned assertion, whether it is AAL1 (i.e., the step-up authentication request was not met) or AAL2 (i.e., the step-up authentication request was met successfully).

The IdP SHALL inform the RP of the following information for each federation transaction:

• The IAL of the subscriber account being presented to the RP, or an indication that no IAL claim is being made
• The AAL of the currently active session of the subscriber at the IdP, or an indication that no AAL claim is being made
• The FAL of the federation transaction

In practice: An application can ask for a certain level of sign-in strength, and the identity provider reports back how the user signed in and how they were verified.

Federated Identifiers

The subscriber is identified in the federation transaction by information in the assertion, which allows the RP to associate the assertion with an RP subscriber account. This identification can happen through an account resolution process (see Sec. 3.8.2) or through a federated identifier.

For general purpose IdPs, a federated identifier is the logical combination of a subject identifier that represents a subscriber account and an issuer identifier that represents the IdP. The subject identifier is assigned by the IdP, and the issuer identifier is usually assigned to the IdP through configuration.

For subscriber-controlled wallets, a federated identifier is the logical combination of a subscriber identifier that represents the subscriber account and an issuer identifier that represents the CSP that issued the attribute bundle. The subject identifier is assigned by the CSP, and the issuer identifier is usually assigned to the CSP through configuration. However, these will not always be available, for example in the case of mobile driver’s licenses where the account resolution is typically done through the use of the driver’s license number and the issuer of the driver’s license. Such a pattern is addressed in Sec. 3.8.2.

In practice: Each user appears to a connected application through a stable identifier in the sign-in message, and the identity team decides which fields it contains.

General Requirements

When using pairwise pseudonymous identifiers within the assertions generated by the IdP for the RP, the IdP SHALL generate a different federated identifier for each RP (see Sec. 3.4.1.2) or set of RPs (see Sec. 3.4.1.3).

Some identity attributes such as names, physical addresses, phone numbers, email addresses, and others can be used to identify a subscriber outside of a federation transaction. When PPIs are used alongside these kinds of identifying attributes, it may still be possible for multiple colluding RPs to re-identify a subscriber by correlation across systems. For example, if two independent RPs each see the same subscriber identified with a different PPI, the RPs could still determine that the subscriber is the same person by comparing the name, email address, physical address, or other identifying attributes carried alongside the PPI in the respective assertions. If PPIs are used alongside identifying attributes, RPs SHALL establish privacy policies, processes, and procedures to prevent the correlation of subscriber data consistent with applicable legal and regulatory requirements.

In practice: For privacy, the identity provider can give each application a different, meaningless ID for the same person, so two applications cannot easily compare notes.

Trust Agreements

Trust agreements are a construct that represent the set of trust relationships established to support parties in a federation transaction. A trust agreement SHALL address one or more of the following relationships:

IdP to CSP:

The IdP trusts the CSP to provide access to attributes in subscriber accounts, through either an IdP onboarding process or the issuance of attribute bundles. The IdP trusts the CSP’s identity proofing processes used in the establishment of the subscriber account.

CSP to IdP:

The CSP trusts the IdP to accurately represent subscriber identity attributes to RPs and to not disclose identity attributes outside of agreed-upon functionality. The CSP trusts the IdP to protect the release of attributes, such as requiring authentication of the subscriber or the presentation of an activation factor before attributes are released.

RP to IdP:

The RP trusts the IdP to accurately represent subscriber identity attributes as provided by the CSP. The RP trusts the IdP to authenticate or identify the subscriber when representing an authentication event.

IdP to RP:

The IdP trusts the RP to only use the requested attributes for its stated purposes.

RP to CSP:

The RP trusts the CSP to provide access to subscriber identity attributes through IdPs. The RP trusts that the CSP has identity-proofed the subscriber and is managing the subscriber account.

In practice: Before two systems exchange logins, an administrator sets up the trust through metadata and an application registration, with paperwork recording who agreed to what.

Bilateral Trust Agreements

In a bilateral trust agreement, the establishment of the trust agreement occurs directly between the federated parties, and the trust agreement is not managed or facilitated by a separate party. Bilateral trust agreements allow for a point-to-point connection to be established between organizations that wish to provide federated identity access to services. Bilateral connections can take many forms, including large enterprise applications with static contracts or subscriber-driven dynamic connections to previously unknown RPs. In all cases, the CSP, IdP, and RP directly manage their policies regarding the federated connection.

Bilateral trust agreements conform to the stated requirements for all trust agreements. However, since these trust agreements do not involve additional parties, there are no additional normative requirements for their establishment and management, such as those mandated for multi-lateral trust agreements (see Sec. 3.5.2).

In practice: An administrator registers a single application with the identity provider one to one, exchanging certificates and addresses directly with that application's owner.

Cryptographic Key Storage

CSPs, IdPs (including subscriber-controlled wallets), and RPs SHALL store all signing keys, decryption keys, and symmetric keys in a secure fashion. Cryptographic key storage is subject to applicable [FIPS140] requirements, including applicable tamper resistance requirements.

Some circumstances require the cryptographic keys to be stored in a non-exportable manner, such as reaching FAL3 with a subscriber-controlled wallet on a subscriber’s device (see Sec. 5.4.1). To be considered non-exportable, key storage SHALL either be a separate piece of hardware or an embedded processor or execution environment, such as a secure element, trusted execution environment (TEE), or trusted platform module (TPM). These hardware modules or embedded processors are separate from a host processor, such as the CPU on a laptop or mobile device. Non-exportable key storage SHALL be designed to prohibit the export of the secret keys to the host processor and SHALL NOT be capable of being reprogrammed by the host processor to allow the secret keys to be extracted.

In practice: The identity provider keeps its signing and decryption keys in a protected key store, often hardware-backed, so administrators cannot casually copy them.

Authentication and Attribute Disclosure

Once the IdP and RP have entered into a trust agreement and completed registration, the federation protocol can be used to pass subscriber attributes from the IdP to the RP.

A subscriber’s identity attributes SHALL only be transmitted between the IdP and the RP for federation transactions or support functions, such as identification of compromised subscriber accounts (see Sec. 3.10.1), even when parties are allowlisted for federation purposes.

A subscriber’s identity attributes SHALL NOT be used by the RP for purposes other than those stipulated in the trust agreement unless the subscriber specifically consents to such purposes. A subscriber’s attributes SHALL be stored and managed in accordance with Sec. 3.11.3.

The subscriber SHALL be informed of the transmission of attributes to an RP. If the authorized party is the organization, the organization SHALL make the list of approved RPs and the associated sets of attributes sent to those RPs available to the subscriber. If the authorized party is the subscriber, the subscriber SHALL be prompted prior to the release of attributes using a runtime decision at the IdP, as described in Sec. 4.6.1.3.

In practice: Administrators decide which attributes, such as name and department, an application receives, and users may be asked for consent where the setup requires it.

Account Linking

A single RP subscriber account MAY be associated with more than one federated identifier. This practice is sometimes known as account linking. If the RP allows a subscriber to link multiple subscriber accounts in this way, the RP SHALL require an authenticated session with the subscriber account for all linking functions. This authenticated session SHOULD require authentication using one existing federated identifier before linking the new federated identifier to the RP subscriber account.

When a federated identifier is removed from an RP subscriber account, the RP SHALL disallow access to the RP subscriber account from the removed federated identifier.

The RP MAY associate different access rights with the same account, depending on which federated account is used to access the RP. The means by which an RP determines authorization and access is out of scope for these guidelines.

In practice: When a person signs in through more than one identity provider, the application links those logins to one account using matching rules.

Protection From Assertion Injection Attacks

An assertion injection attack in the context of a federated protocol consists of an attacker attempting to force an RP to accept or process an assertion or assertion reference in order to gain access to the RP or deny a legitimate subscriber access to the RP. The attacker does this by taking an assertion or assertion reference and injecting it into a vulnerable RP. A successful attacker can trick an RP into binding the attacker’s session to the federated identifier in the assertion. The attacker’s assertion could be either stolen from a legitimate subscriber or manufactured to perpetrate the attack.

Protection from assertion injection attacks is recommended at all FALs and required at FAL2 and above. In all cases, the RP needs to take reasonable steps to prevent an attacker from presenting an injected assertion or assertion reference based on the nature of the RP software, the capabilities of the federation protocol in use, and the needs of the overall system. Both [OIDC] and [SAML] provide mechanisms for assertion injection protection, including nonces sent from the RP during the request, RP authentication for back-channel communications, and methods for the RP to start the federation transaction and track its state throughout the process. Different mechanisms provide different degrees of protection and are applicable in different circumstances.

While the details of specific protections will vary based on the federation protocol and technology in use, common best practices can be used to limit the attack surface, such as:

• Back channel assertion presentation, which prevents an RP from accepting assertions outside of a direct response from the IdP (see Sec. 4.11.1)

In practice: The application checks that each incoming sign-in message is signed, meant for it, and recent, which helps reject forged messages from an attacker.

Encrypted Assertion

The contents of the assertion can be encrypted to protect against exposing sensitive information to untrusted third parties, such as a user agent. This protection is especially relevant when the assertion contains personal information about the subscriber.

A trust agreement MAY require the encryption of assertion contents in other situations.

While most assertion formats support encryption of the entire assertion, some assertion formats allow for only the personal information portions of the assertion to be encrypted, providing the selective disclosure of sensitive information to the RP without encrypting the entire assertion.

When portions of the assertion are encrypted, only an RP that holds the necessary decryption key will be able to access the encrypted information in the assertion.

When encrypting assertions, the IdP SHALL encrypt the contents of the assertion using the RP’s encryption key with approved cryptography.

For example, a SAML assertion can be encrypted using XML-Encryption, while an OpenID Connect ID Token can be encrypted using JSON Web Encryption (JWE).

When used with back-channel presentation, an assertion can also be encrypted in transit with a mutually authenticated TLS connection if there are no intermediaries between the IdP and RP that interrupt the TLS channel.

The meaning of subject identifiers is contextual to their target systems, unlike other possible identifiers, such as SSNs, email addresses, or driver’s license numbers. Therefore, subject identifiers alone do not trigger encryption requirements based on protecting personal information.

In practice: Where sign-in messages pass through untrusted parties, administrators turn on encryption so personal details inside them stay hidden.

Bearer Assertions

A bearer assertion can be presented on its own as proof of the identity of the party presenting it. No other proof beyond validation of the assertion is required. Similarly, a bearer assertion reference can be presented on its own to the RP and used by the RP to fetch an assertion. If an attacker can capture or manufacture a valid assertion or assertion reference that represents a subscriber and can successfully present that assertion or reference to the RP, then the attacker could impersonate the subscriber at that RP.

The mere possession of a bearer assertion or reference is not always enough to impersonate a subscriber. For example, if an assertion is presented in the back-channel federation model (see Sec. 4.11.1), additional controls can be placed on the transaction (e.g., identification of the RP, assertion injection protections) that help further protect the RP from fraudulent activity.

In practice: Ordinary web single sign-on uses messages that work for whoever presents them, so they have short lifetimes and travel only over protected connections.

Holder-of-Key Assertions

A holder-of-key assertion (Fig. 3) SHALL include a unique identifier for an authenticator that can be verified independently by the RP, such as the public key of a certificate controlled by the subscriber. The RP SHALL verify that the subscriber possesses the authenticator identified by the assertion. Holder-of-key assertions are most often used when the authenticator technology is tied to a public-key infrastructure (PKI) trusted by both the IdP and RP.

[figure omitted]

The authenticator identified in a holder-of-key assertion MAY be distinct from the primary authenticator that the subscriber uses to authenticate to the IdP. The authenticator identified in a holder-of-key assertion SHALL be phishing-resistant, as defined by Sec. 3.2.5 of [SP800-63B]. When the RP encounters an authenticator in a holder-of-key assertion for the first time, the RP SHALL ensure that the authenticator can be uniquely resolved to the RP subscriber account, as discussed in Sec. 3.8.2.

A holder-of-key assertion SHALL NOT include an unencrypted private key or symmetric key to be used as an authenticator.

Assertions from subscriber-controlled wallets that run on a subscriber’s device can be considered holder-of-key assertions.

Section 9.6 provides a more complete example of the use of a mutual TLS connection to provide the proof of possession of a certificate on a smart card that is listed by the assertion.

Since the authenticators used in holder-of-key assertions could be presented to multiple parties, and these authenticators often contain identity attributes, there are additional privacy considerations to address, as discussed in Sec. 7.

In practice: In higher-risk setups, a sign-in message carries a reference to a key the user holds, and the application checks that the user can use that key.

Bound Authenticators

A bound authenticator (Fig. 4) is an authenticator that is bound to the RP subscriber account and managed by the RP. The IdP SHALL include an indicator in the assertion when the assertion is to be used with a bound authenticator at FAL3. The unique identifier for the authenticator (such as its public key) SHALL be stored in the RP subscriber account. The RP needs to have a reliable basis for evaluating the characteristics of the bound authenticator, such as the inclusion of a signed attestation, as discussed in Sec. 3.2.4 of [SP800-63B]. Bound authenticators are most often used when the authenticator technology is not tied to a PKI trusted by both the IdP and RP, for example when no such PKI exists.

[figure omitted]

A bound authenticator SHALL be unique per subscriber at the RP such that two subscribers cannot present the same authenticator for their separate RP subscriber accounts. All bound authenticators SHALL use phishing-resistant authentication mechanisms, as defined by Sec. 3.2.5 of [SP800-63B]. Consequently, subscriber-chosen values such as a password cannot be used as bound authenticators.

Bound authenticators SHALL be accepted for authentication in the context of processing an FAL3 assertion for a federated transaction. While it is possible for the same authenticator to also be used for direct authentication to the RP (see Sec. 3.8.3), such use is not considered a bound authenticator, and the RP SHALL document these as distinct use cases.

The IdP MAY specify types or characteristics for allowable bound authenticators in the trust agreement.

In practice: For the highest federation level, a user's authenticator is registered directly with the application's account, which the application manages alongside the identity provider.

Pre-Established Trust Agreements

When the trust agreement is established by the federated parties prior to the federation transaction, the trust agreement SHALL establish the following terms:

• The set of subscriber attributes, derived attributes, and attribute bundles that the IdP can make available to the RP
• The attribute storage policy of the IdP for the subscriber account, including any available means for the subscriber to request deletion
• Any attribute sources from which the IdP receives applicable subscriber attributes, derived attributes, and attribute bundles, including the CSP
• Any identity APIs that are made available by the IdP, either directly or through an external provider, and which subscriber attributes are available at these APIs
• The population of subscriber accounts for which the IdP can create assertions
• Any additional uses of subscriber information beyond providing the identity service
• The set of subscriber attributes, derived attributes, and attribute bundles that the RP is allowed to request (i.e., a subset of the attributes made available)
• The purpose for each attribute requested by the RP
• The provisioning models used by the RP for RP subscriber accounts
• The authorized party responsible for decisions regarding the release of subscriber attributes to the RP (e.g., the IdP organization, the subscriber)
• The process and techniques used to inform subscribers about attribute sharing
• The process and techniques for collecting consent from the authorized party when necessary
• The xALs available from the IdP
• The xALs required by the RP

The terms of the trust agreement SHALL be available to the operators of the RP and the IdP upon its establishment. The terms of the trust agreement SHALL be made available to subscribers upon request to the IdP or RP.

In practice: An administrator registers each application with the identity provider before anyone uses it, so trust is already in place at the first sign-in.

Dynamic Registration

At FAL1 and FAL2, the cryptographic keys and identifiers of the RP can be exchanged in a dynamic process, whereby the RP software presents its configuration to the IdP either directly or through a trusted third party and receives the identifier to use with that IdP. This process is specific to the federation protocol in use but requires machine-readable configuration data to be made available over the network. All transmission of configuration information SHALL be made over a secure protected channel to endpoints that are associated with the IdP’s identifier by the trust agreement.

IdPs SHOULD consider the risks of information leakage to multiple RP instances and take appropriate countermeasures, such as issuing PPIs for subscribers who access dynamically registered RPs, as discussed in Sec. 3.4.1.

Dynamic registration SHOULD be augmented by attestations about the RP software and device, as discussed in Sec. 3.6.3.

[OIDC-Registration] defines a protocol for the dynamic registration of RPs at an OpenID Connect IdP.

In practice: Where enabled, applications can register themselves under a registration policy, with consent rules limiting who may connect new applications.

IdP Allowlists of RPs

In a pre-established trust agreement, IdPs MAY establish allowlists of RPs that are authorized to receive authentication and attributes from the IdP without a runtime decision from the subscriber. When placing an RP on its allowlist, the IdP SHALL confirm that the RP abides by the terms of the trust agreement. The IdP SHALL determine which identity attributes are passed to the allowlisted RP upon authentication. IdPs SHALL make allowlists available to subscribers, as described in Sec. 7.2.

IdP allowlists SHALL uniquely identify RPs through fully qualified domain names, cryptographic keys, or other identifiers that are applicable to the federation protocol in use. Any entities that share an identifier SHALL be considered equivalent for the purposes of the allowlist. Allowlists SHOULD be as specific as possible to avoid unintentional impersonation of an RP. An allowlist entry for an RP SHALL NOT use a wildcard domain identifier.

IdP allowlist entries for an RP SHALL indicate which attributes are included as part of an allowlisted decision. If additional attributes are requested by the RP, the request SHALL be:

• Subject to a runtime decision of the authorized party to approve the additional attributes requested,
• Redacted to only the attributes in the allowlist entry, or
• Denied outright by the IdP.

IdP allowlist entries MAY be applied based on aspects of the federation transaction, such as the xALs required for the transaction. For example, an IdP could use an allowlist entry to bypass a consent screen for an FAL1 transaction but require confirmation of consent from the subscriber during an FAL3 transaction.

In practice: Administrators assign which applications each group may use and limit consent, so the identity provider only sends logins to the applications assigned.

RP Allowlists of IdPs

RPs MAY establish allowlists of IdPs from which the RP will accept authentication and attributes without a runtime decision from the subscriber to use the IdP. In practice, many RPs interface with only a single IdP, and this IdP is allowlisted as the only possible entry for that RP. When placing an IdP in its allowlist, the RP SHALL confirm that the IdP abides by the terms of the trust agreement. This confirmation can be facilitated by a federation authority or undertaken directly by the RP.

RP allowlists SHALL uniquely identify IdPs through fully qualified domain names, cryptographic keys, or other identifiers that are applicable to the federation protocol in use. Allowlists SHOULD be as specific as possible to avoid unintentional impersonation of an IdP. An allowlist entry for an IdP SHALL NOT use a wildcard domain identifier.

RP allowlist entries MAY be applied based on aspects of the federation transaction, such as the xALs required for the transaction. For example, an RP could use a runtime decision for FAL1 transactions but require an allowlisted IdP for FAL3 transactions.

In practice: An application lists which identity providers it trusts, so a sign-in from an unknown provider is rejected.

Shared Signaling

In some environments, it is useful for the IdP and RP to send information to each other outside of the federation transaction. These signals can communicate important changes in state between parties that would not otherwise be known, such as suspected fraud or an account status change. Shared signaling SHALL be limited to the allowable functions of the identity process, as discussed in Sec. 3.10.1. All uses of shared signaling SHALL be documented in the trust agreement and made available to the authorized party stipulated by the trust agreement. This documentation SHALL include the events under which a signal is sent, the type of information included in such a signal (including any personal information), any additional parameters sent with the signal, and the expected processing of a received signal. The use of shared signaling SHALL be subject to privacy review under the trust agreement. Shared signals SHALL NOT include personal information except what is necessary to identify the subscriber account in question (e.g., an account identifier or attributes that can be correlated by the receiving party).

Signaling from the IdP to the RP SHALL require a pre-established trust agreement. Signaling from the RP to the IdP MAY be used in both pre-established and subscriber-driven trust agreements.

The IdP SHOULD send a signal to the RP regarding the following changes to the subscriber account:

• The account has been terminated, suspended, or disabled.
• The account is suspected of being compromised.
• Attributes of the account have changed, including identifiers other than the federated identifier (e.g., email address, certificate common name).
• The possible range of IAL, AAL, or FAL for the account has changed.
• Authenticators have been updated.

In practice: When the identity provider sees a risky event, such as a disabled account, it signals connected applications so they can end that user's session sooner.

Assertion Contents

An assertion is a statement from the IdP to the RP that contains information about an authentication event for an authenticated subscriber as well as a set of attribute values, derived attribute values, or attribute bundles about or associated with that subscriber. In addition to attribute information, assertions comprise a variety of data, including assertion metadata, information about the subscriber’s authentication at the IdP, and other information that the RP can leverage (e.g., restrictions, validity time window). While the assertion’s primary function is to authenticate the user to an RP, the information conveyed in the assertion can be used by the RP for a number of use cases (e.g., identity proofing, authorization, personalization of a website). These guidelines do not restrict RP use cases nor the type of protocol or data payload used to federate an identity, provided that the chosen solution meets all mandatory requirements contained herein.

Assertions SHALL represent a discrete authentication event of the subscriber at the IdP and SHALL be processed as a discrete authentication event at the RP.

All assertions SHALL include the following attributes:

• Issuer identifier: An identifier for the issuer of the assertion (i.e., the IdP).
• Audience identifier: An identifier for the party intended to consume the assertion (i.e., the RP). An assertion can contain more than one audience identifier at FAL1.
• Issuance time: A timestamp that indicates when the IdP issued the assertion.

In practice: Administrators decide which claims and attributes are included in a sign-in message, keeping it to what the application needs to do its job.

General Security Requirements

• Each online transaction within the identity proofing process, including transactions that involve third parties, SHALL occur over an authenticated protected channel.
• The CSP SHALL implement automated attack protections for the identity proofing process, such as bot detection, mitigation, and management solutions; behavioral analytics; web application firewall settings; and network traffic analysis.
• All personal information that is collected as part of the identity proofing process SHALL be protected to maintain the confidentiality and integrity of the information, including the encryption of data at rest and the exchange of information using authenticated protected channels.
• The CSP SHALL assess the information security and privacy risks associated with operating its identity service, according to the NIST Risk Management Framework [NIST-RMF] or equivalent risk management guidelines. At a minimum, the CSP SHALL apply appropriate controls consistent with the NIST SP 800-53 [SP800-53] moderate baseline, regardless of IAL.
• The CSP SHALL assess risks associated with its use of third-party services and apply appropriate controls, as provided in the [SP800-161] Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations.

Requirements for Continuation Codes

Continuation codes are used to reestablish an applicant’s linkage to an incomplete identity proofing or enrollment process. The continuation code provides a temporary secret that can connect one session to another. A typical scenario would involve an applicant starting an identity proofing process online (e.g., remote unattended) but needing to complete it through an in-person (e.g., on-site attended) event. This on-site service is often offered by a third party or through a channel that may not have the technology to support authentication of the applicant with established CSP-issued authenticators. If applicants are able to leverage established authenticators at all steps in the identity proofing process, then a continuation code is not needed.

As such, CSPs MAY use continuation codes when an applicant is unable to complete all of the steps necessary to be successfully identity-proofed and enrolled into the CSP’s identity service in a single session, particularly when switching between different identity proofing types. Continuation codes are intended to be maintained offline (e.g., printed or written down) and stored in a secure location by the applicant for use in reestablishing linkage to a previous, incomplete session. In order to facilitate the authentication of the applicant to a subsequent session with the CSP, the CSP SHOULD first bind an authenticator to a record or account that was established for the applicant prior to the cessation of the initial session.

If continuation codes are used, the following requirements apply:

• Continuation codes SHOULD be delivered in-session but MAY be delivered out-of-band to a physical mailing address, phone number, or email address.

Requirements for the Use of Biometrics

Biometrics refers to the automated recognition of individuals based on their biological and behavioral characteristics, such as facial features, fingerprints, voice patterns, keystroke patterns, angle of holding a smart phone, screen pressure, typing speed, mouse movements, or gait. As used in these guidelines, biometric data refers to any analog or digital representation of biological and behavioral characteristics at any stage of their capture, storage, or processing, including the transmission of biometric data to other applications or service partners. This includes live biometric samples from applicants (e.g., facial images, fingerprint) as well as biometric references obtained from evidence (e.g., facial image on a driver’s license, fingerprint minutiae template on identification cards). As applied to the identity proofing process, CSPs can use biometrics to verify that an individual is the rightful subject of identity evidence, to bind an individual to a new piece of identity evidence or credential, or for the purposes of deduplication. These requirements also address the additional privacy impacts associated with the use of biometrics in the identity proofing process.

The following requirements apply to CSPs that employ biometrics as part of their identity proofing process:

• CSPs SHALL provide clear, publicly available information about all uses of biometrics, including what biometric data is collected, how it is stored and protected, and how to remove biometric data consistent with applicable laws and regulations.
• CSPs SHALL obtain explicit informed consent to collect and use biometrics from all applicants.
• CSPs SHALL store a record of the subscriber’s consent for biometric use and associate it with the subscriber’s account.

Digital Injection Prevention and Forged Media Detection

Many emerging attacks on both attended and unattended remote identity proofing processes pair digital injection attacks with increasingly effective and available generative AI tools. These AI tools are used to create or modify media that contain images or videos of applicants and evidence (i.e., deepfakes) to defeat automated document validation processes, biometric operations, and visual comparisons done by proofing agents. Injection attacks insert modified or forged media between the capture point (e.g., a device) and the element conducting the comparison or other operation (e.g., a server running the algorithms, a workstation used by a proofing agent).

All types of remote identity proofing are in some way vulnerable to these forms of attack, whether the attack is on the remote optical capture and inspection components, the automated biometric mechanisms, or the video systems used in remote attended processes.

A biometric comparison performed with a captured sample does not prevent these attacks. However, live document capture and presentation attack detection mechanisms do provide some protection from injection and forged media attacks by making the injection of viable forged media more challenging. Not only does the media need to be inserted into the communication channel between the applicant endpoint and the CSP comparison component, but the forged media would also need to sufficiently defeat any passive or active presentation attack detection mechanisms implemented by the CSP. However, even these mechanisms are not sufficient to address all possible cases of these kinds of attacks.

Use of Biometrics

Biometrics is the automated recognition of individuals based on their biological and behavioral characteristics, such as fingerprints, voice patterns, facial features, keystroke patterns, angle of holding a smart phone, screen pressure, typing speed, mouse movements, or gait. Such characteristics have multiple modalities that may differ in the extent to which they establish authentication intent, as described in Sec. 3.2.8.

Biometric comparisons are based on a measurement from the biometric sensor (e.g., camera, fingerprint reader). This measurement is subject to noise and presentation variations that require setting an acceptance threshold based on the differences between the measured biometric and the reference against which it is being compared. Due to these factors, there is some probability that a comparison will not result in a match, which is referred to as a false non-match rate (FNMR). Similarly, there is a probability that an impostor comparison will result in a match, referred to as a false match rate (FMR). A high-quality biometric system has both a very low FMR and FNMR. The chosen threshold usually emphasizes a low FMR to maximize security since false non-matches can often be mitigated by repeating the measurement or using an alternative authentication method.

For a variety of reasons, this document supports only a limited use of biometrics for authentication. These reasons include:

• The biometric FMR does not provide sufficient confidence in the subscriber’s authentication by itself because it does not account for active impersonation attacks.
• Biometric comparison is probabilistic, whereas the other authentication factors are deterministic.

Verifier-CSP or IdP Communications

If the verifier and CSP or IdP are separate entities (as shown by the dotted line in Fig. 3 of [SP800-63]), communications between the verifier and CSP or IdP SHALL occur through a mutually authenticated protected channel (e.g., a client-authenticated TLS connection) using approved cryptography.

Connected Authenticators

Cryptographic authenticators require a trustworthy connection between the authenticator and the endpoint being authenticated that provides resistance to eavesdropping, injection, and relay attacks. This connection SHALL be made using a wired connection (e.g., USB or direct connection with a smartcard), a wireless technology, or a hybrid of those technologies, including network connections.

Approved cryptography SHALL be used for all cases in which cryptographic operations are required. All communication of authentication data between authenticators and endpoints SHALL occur directly between those devices or through an authenticated protected channel between the authenticator and endpoint.

Random Values

Random values are extensively used in authentication processes in a variety of roles (e.g., nonces, authentication secrets). Unless otherwise specified, random values that reference this section SHALL be generated by an approved random bit generator [RBG] that provides at least the minimum security strength specified in the latest revision of [SP800-131A] (i.e., 112 bits as of the date of this publication).