Abstract

This paper analyzes the “Binding” provisions within the new digital identity standard, NIST SP800-63-4 (released July 31, 2025). While the standard does not explicitly define a “Binding Level of Assurance,” the document concentrates on the implicit levels found in SP800-63A-4 and a critical security flaw in the process for adding subsequent authenticators, as detailed in SP800-63B-4.

The core issue is that the current provision allows a new, higher-level authenticator (e.g., AAL2 or AAL3) to be bound to a subscriber’s account within a low-assurance session (e.g., AAL1). This creates a vulnerability where an attacker, having compromised a lower-level authenticator, could bind their own high-level authenticator to the victim’s account, potentially leading to an account hijack.

To mitigate this risk, the paper proposes three amendments to the binding provision. These amendments aim to ensure that the binding process is either performed at an authentication assurance level (AAL) equal to or greater than the new authenticator’s AAL, that the new authenticator is registered at the AAL of the current session, or that identity proofing is re-executed. This would prevent the binding of a high-assurance authenticator using a low-assurance session, thereby enhancing security and providing a more accurate assessment of assurance to Relying Parties.

Table of Contents

• 1. Introduction

• 2. Authenticator Binding

• General provisions

• 3. Binding at Enrollment

• 4. Binding Provisions

• 4.1 IAL2 Binding Provisions

• 4.2 IAL3 Binding Provisions

• 5. Problems of the current documentation

• 5.1 Issues around initial binding of the authenticator

• 5.2 Issues around adding subsequent authenticators

• 6. Conclusion

• Like this:

• Related

1. Introduction

NIST SP800-63-4 is a new digital identity standard that came out on July 31, 2025. It covers vast territory. However, in this paper, we will concentrate on the aspect of “Binding”.

NIST SP800-63B-4 used the word “Binding” rather than “Issuance” because users can bring their own authenticators and register them to their account at the CSP rather than CSPs issuing it. So “binding” is a term that encompasses both registration by the user (subscriber) to the CSP and the issuance by the CSP.

There is no explicit mention of the binding level of assurance in NIST SP800-63-4. However, there are some hints of it. It is mainly in the initial registration phase of the authenticator, which is described in SP800-63A-4 in the list of provisions for each level, referring to NIST SP800-63B-4 for specific security requirements that are common to all levels.

**2. Authenticator Binding **

General provisions

In SP800-63B-4, section 4.1 is dedicated to this binding.

First, it defines “Authenticator binding” as follows:

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. (Source: NIST SP800-63B-4)

Then, the document introduces a group of provisions as follows.

Authenticators SHALL be bound to subscriber accounts by either:

1. being issued by the CSP as part of enrollment or
2. using a subscriber-provided authenticator that is acceptable to the CSP.

When subsequent authenticator is to be bound to the subscriber account, the CSP

1. 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; and

• 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.

1. SHALL notify the subscriber via a mechanism independent of the transaction binding the new authenticator, as described in Sec. 4.6., when an authenticator is added.

Provision 1-3 above is problematic. It will be discussed in section 4.2.

Throughout the lifetime of a digital identity, CSPs

1. SHALL bound to subscriber accounts by either

• the CSP issues as part of enrollment or
• the CSP accept the acceptable authenticator and registers it linke to the subscriber account;

1. SHALL maintain a record of all authenticators that are bound to each subscriber account;
2. 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;
3. (implicit) SHALL communicate to the RP the result of determination;
4. MAY determine it 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]);
5. SHALL also maintain other state information that is required to meet the authenticator verification requirements;

• **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.

1. SHALL create the record that contain the date and time of significant authenticator lifecycle events (e.g., binding to the subscriber account, renewal, update, expiration);
2. SHOULD include information about the source of the binding (e.g., IP address, device identifier) of any device associated with the event; and
3. MAY require additional information about the new authenticator or its associated endpoint to determine whether it is suitable for the requested AAL.

**3. Binding at Enrollment **

Binding at the time of enrollment is part of the enrollment process and is discussed in [SP800-63A]. paraphrasing, the provisions are as follows.

CSP SHALL

1. permit the binding of multiple authenticators to a subscriber account;
2. ensure that the process requires authentication at the lower of either

• the maximum AAL currently available; or
• maximum AAL at which the new authenticator will be used;

NOTE 1: This means that if the subscriber account is only bound to AAL1 authenticator, the subsequent AAL2 authenticator is boud to the subscriber account within an AAL1 session. This poses a problem as AAL1 session may have been already taken over by the attacker and the attacker may be attempting to bind its AAL2 authenticator to the victim’s account.

1. notify the subscriber via a mechanism independent of the transaction binding the new authenticator, as described in Sec. 4.6. (Account Notifications).

NOTE 2: This partly addresses the problem pointed out in NOTE 1.

Further, if an authenticator is provided by another device other than the one on which the subscriber is currently authenticated, the binding process SHALL occur in the following sequence.

1. The device on which the subscriber is currently authenticated requests a binding code to the CSP.
2. CSP generates and returns a binding code to the device.
3. The subscriber enters the binding code to the second device with a new authenticator.

**4. Binding Provisions **

SP800-63A-4 states the requirements for each IAL. The following are the requirements for IAL 2 and 3.

4.1 IAL2 Binding Provisions

IAL2 Binding requirements are listed in SP800-63A-4 section 4.2.12 Initial Authenticator Binding.

Once a unique subscriber account is established for the applicant (now subscriber) in the CSP’s identity system, that is, when a record was created in the identity register of the CSP, one or more authenticators can be associated (i.e., bound) to the subscriber’s account.

To minimize the need for account recovery, the CSP

1. SHOULD encourage subscribers to bind at least two separate means of authentication. NOTE: See Sec. 5 for more information about subscriber accounts and Sec. 4.1.2.1 of [SP800-63B] for more information on binding authenticators.

2. SHALL provide the ability for the applicant to bind an authenticator using one of the following methods:

3. 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]

4. Distribution of a physical authenticator to a validated address

5. Distribution or on-site enrollment of an authenticator

6. SHALL confirm the presence of the intended subscriber through one of the following methods if authenticators are bound outside of a single protected session with the user:

7. Return of a continuation code

8. Comparison against a biometric collected at the time of proofing

4.2 IAL3 Binding Provisions

IAL3 Binding requirements are listed in SP800-63A-4 section 4.3.10 Initial Authenticator Binding. The provisions are as follows:

The CSP

1. SHALL distribute or enroll the subscriber’s initial authenticator during an on-site attended interaction with a proofing agent;
2. SHALL compare a biometric sample collected from the subscriber to the one collected at the time of proofing prior to registration of the authenticator if the CSP distributes or enrolls the initial authenticator outside of a single authenticated protected session with the subscriber, the CSP; and
3. 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.

5. Problems of the current documentation

There are several issues that can be pointed out in the SP800-63-4 binding processes.

5.1 Issues around initial binding of the authenticator

Notably, it is missing the remote registration provisions, which could look like:

1. SHALL enroll the subscriber’s initial authenticator during the same protected session in which a proofing agent established the identity to be registered to the identity register.

This could be the oversight or the reflection of the American local condition, where remote identity proofing at IAL3 is difficult since there is no widespread digital identity document that can be meaningfully used in the remote identity proofing.

When other jurisdictions that can utilize digital identity document (Digital ID) try to make use of SP800-63-4, it is probably wise to add the point 4 above.

5.2 Issues around adding subsequent authenticators

As stated earlier, provision 1-3 is problematic. It states that

• 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

This means that “AAL2” and “AAL3” authenticators can be bound to the subscriber account within the session created by an “AAL1” authenticator.

This poses a problem: an attacker may have already compromised the victim’s ALL1 authenticator (such as a password) and binds their “AAL2/3” authenticator and uses it subsequently.

Provision 1-3 should probably amended to:

The CSP SHALL

1. ensure that the process requires authentication at either the same or greater AAL that the subscriber is trying to add; or
2. mark the registered authenticator as the same AAL of the current session even if the authenticator is capable of fulfilling a higher AAL; or
3. redo the identity proofing at the matching IAL to raise the session quality to be equal or higher of the AAL of the authenticator being registered.

** 6. Conclusion**

This paper summarizes the “Binding” provisions available in NIST SP800-63-4 series. It points out that there are implicit notions of “Binding Level” expressed in SP800-63A-4 and that the method referred by it (SP800-63B-4) is problematic because it is vulnerable to the attacker adding their higher level authenticator to the victim’s account.

To mitigate it, this paper proposes some amendments/additional provisions to it. With the mitigation, CSPs can provide safer ways to bind the authenticator to the account, or avoid providing false sense of security to the RP.