This section is normative.
A number of events can occur over the lifecycle of a subscriber’s authenticator that affect that authenticator’s use. These events include binding, loss, theft, unauthorized duplication, expiration, and revocation. This section describes the actions to be taken in response to those events.
Authenticator binding refers to the establishment of an association between a specific authenticator and a subscriber account, enabling the authenticator to be used — possibly in conjunction with other authenticators — to authenticate for that subscriber account.
Authenticators SHALL be bound to subscriber accounts either
These guidelines refer to the binding rather than the issuance of an authenticator to accommodate both options.
Throughout the digital identity lifecycle, CSPs SHALL maintain a record of all authenticators that are or have been associated with each subscriber account. The CSP or verifier SHALL maintain the information required for throttling authentication attempts when required, as described in Sec. 5.2.2. The CSP SHALL also verify the type of user-provided authenticator (e.g., single-factor cryptographic device vs. multi-factor cryptographic device) so verifiers can determine compliance with requirements at each AAL.
The record created by the CSP SHALL contain the date and time the authenticator was bound to the subscriber account. The record SHOULD include information about the source of the binding (e.g., IP address, device identifier) of any device associated with the enrollment. If available, the record SHOULD also contain information about the source of unsuccessful authentications attempted with the authenticator.
When any new authenticator is bound to a subscriber account, the CSP SHALL ensure that the binding protocol and the protocol for provisioning the associated keys are done at a level of security commensurate with the AAL at which the authenticator will be used. For example, protocols for key provisioning SHALL use authenticated protected channels or be performed in person to protect against adversary-in-the-middle attacks. Binding of multi-factor authenticators SHALL require multi-factor authentication or equivalent (e.g., association with the session in which identity proofing has been just completed) be used in order to bind the authenticator. The same conditions apply when a key pair is generated by the authenticator and the public key is sent to the CSP.
As part of the binding process, the CSP MAY require additional information about the new authenticator or the endpoint it is associated with to determine that they are suitable for the AAL being requested and to attempt to determine that the endpoint and authenticator are free from malware.
The following requirements apply when an authenticator is bound to a subscriber account as part of the enrollment process.
The CSP SHALL bind at least one — and SHOULD bind at least two — physical (something you have) authenticators to the subscriber account, in addition to a memorized secret or one or more biometric characteristics. Binding of multiple authenticators provides a means to recover from the loss or theft of the subscriber’s primary authenticator. Preservation of online material or an online reputation makes it undesirable to lose control of a subscriber account due to the loss of an authenticator. The second authenticator makes it possible to securely recover from an authenticator loss.
If enrollment and binding cannot be completed in a single physical encounter or electronic transaction (i.e., within a single protected session), the following methods SHALL be used to ensure that the same party acts as the applicant throughout the processes:
For remote transactions:
The applicant SHALL identify themselves in each new binding transaction by presenting a temporary secret which was either established during a prior transaction, or sent to the applicant’s phone number, email address, or postal address of record.
Long-term authenticator secrets SHALL only be issued to the applicant within a protected session.
For in-person transactions:
The applicant SHALL identify themselves in person by either using a secret as described in remote transaction (1) above, or through use of a biometric that was recorded during a prior encounter.
Temporary secrets SHALL NOT be reused.
If the CSP issues long-term authenticator secrets during a physical transaction, then they SHALL be loaded locally onto a physical device that is issued in person to the applicant or delivered in a manner that confirms the address of record.
With the exception of memorized secrets, CSPs and verifiers SHOULD encourage subscribers to maintain at least two valid authenticators of each factor that they will be using. For example, a subscriber who usually uses an OTP device as a physical authenticator MAY also be issued a number of look-up secret authenticators, or register a device for out-of-band authentication, in case the physical authenticator is lost, stolen, or damaged. See Sec. 6.1.2.3 for more information on replacement of memorized secret authenticators.
Accordingly, CSPs SHOULD permit the binding of additional authenticators to a subscriber account. Before adding the new authenticator, the CSP SHALL first require the subscriber to authenticate at the AAL (or a higher AAL) at which the new authenticator will be used. A separate authentication using existing authenticators SHALL be performed following the request to bind a new authenticator, and SHALL be valid for 20 minutes. When an authenticator is added, the CSP SHOULD send a notification to the subscriber via a mechanism that is independent of the transaction binding the new authenticator (e.g., email to an address previously associated with the subscriber). The CSP MAY limit the number of authenticators that are bound in this manner.
If the subscriber account has only one authentication factor bound to it and an additional authenticator of a different authentication factor is to be added, the subscriber MAY request that the subscriber account be upgraded to AAL2.
Before binding the new authenticator, the CSP SHALL require the subscriber to authenticate at AAL1. The CSP SHOULD send a notification of the event to the subscriber via a mechanism independent of the transaction binding the new authenticator (e.g., email to an address previously associated with the subscriber).
The situation where a subscriber loses control of authenticators necessary to successfully authenticate is commonly referred to as account recovery.
If a subscriber that has been identity proofed loses all authenticators necessary to complete authentication, that subscriber SHALL repeat the identity proofing process described in [SP800-63A]. If the CSP has retained information from the evidence used in the original identity proofing process (pursuant to a privacy risk assessment as described in [SP800-63A] Sec. 5.2.2) that is sufficient to perform verification of the subscriber and if that evidence is still valid, it MAY repeat only the verification portion of the identity proofing process as described in [SP800-63A].
The CSP SHALL require the claimant to authenticate using an authenticator of the remaining factor, if any, to confirm binding to the existing subscriber account. Reestablishment of authentication factors at IAL3 SHALL be done in person or through a supervised remote process as described in [SP800-63A] Sec. 5.6.8, and SHALL perform a successful biometric comparison against the biometric characteristic collected during the original identity proofing process.
The CSP SHOULD send a notification of the event to the subscriber. This MAY be the same notice that is required as part of the identity proofing process.
Subscriber accounts that have not been identity proofed (i.e., without IAL) cannot be recovered because there is no reliable means for reassociating the subscriber with that account. Such accounts SHALL be treated as abandoned and a new subscriber account SHALL be established.
Replacement of a lost (i.e., forgotten) memorized secret is problematic because it is very common. Additional “backup” memorized secrets do not mitigate this because they are just as likely to also have been forgotten. If a biometric is bound to the subscriber account, the biometric characteristic and associated physical authenticator SHOULD be used to establish a new memorized secret.
As an alternative to the above re-proofing process when there is no biometric bound to the subscriber account, the CSP MAY bind a new memorized secret with authentication using two physical authenticators, along with a confirmation code that has been sent to one of the subscriber’s addresses of record. The confirmation code SHALL consist of at least 6 random alphanumeric characters generated by an approved random bit generator [SP800-90Ar1]. Confirmation codes SHALL be valid for at most:
External authenticator binding refers to the process of binding an authenticator to a subscriber account when it is not connected to (or embedded in) the authenticated endpoint. 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 MAY begin with a request from an endpoint that has authenticated to the CSP obtaining a binding code from the CSP that is input into the endpoint associated with the new authenticator and sent to that CSP. Alternatively, the endpoint associated with the new authenticator MAY obtain a binding code from the CSP, which is input to an authenticated endpoint and sent to the CSP.
In addition to the requirements given in Sec. 6.1.2.1, Sec. 6.1.2.2, and Sec. 6.1.2.3 above as applicable, the following requirements SHALL apply when binding an external authenticator:
An authenticated protected session 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 they are known by the CSP on the endpoint associated with the new authenticator.
The CSP SHALL generate a binding code using an approved random number generator and send it to either the new authenticator endpoint or the authenticated endpoint approving the binding. The binding code SHALL have at least 40 bits of entropy if used in conjunction with an identifier entered on the previous step; otherwise a binding code with at least 112 bits of entropy SHALL be required.
The subscriber SHALL transfer the binding code to the other endpoint. This transfer SHALL be either manual or via a local out-of-band method such as a QR code. The binding code SHALL NOT be communicated over any insecure channel such as email or PSTN (SMS or voice).
The binding code SHALL be usable only once and SHALL be valid for a maximum of 10 minutes.
Following the binding of the new authenticator (or issuance of a certificate, in the case of PKI-based authenticators), the CSP SHOULD encourage the subscriber to authenticate with the new authenticator to confirm that the process has completed successfully.
The CSP SHALL provide clear instruction on what the subscriber should do in the event of an authenticator binding mishap, such as a button or contact address to allow a mis-bound authenticator to be quickly invalidated as appropriate. This MAY be provided in the authenticated session or in the binding notification described in Sec. 6.1.2.1, Sec. 6.1.2.2, and Sec. 6.1.2.3 above.
Binding an external authenticator is a potentially risky operation because of the potential for the subscriber to be tricked into using a binding code by an attacker or supplying a binding code to an attacker. In some cases, QR codes obtained from a trusted source (such as from an authenticated session, especially when that authentication is phishing resistant) are considered to be more robust against such attacks, because they typically contain the URL of the CSP as well as the binding code. There is less potential for the subscriber to be fooled into entering a binding code at a phishing site as a result.
A subscriber may already possess authenticators suitable for authentication at a particular AAL. For example, they may have a two-factor authenticator from a social network provider, considered AAL2 and IAL1, and would like to use those credentials at an RP that requires IAL2.
CSPs SHOULD, where practical, accommodate the use of subscriber-provided authenticators in order to relieve the burden to the subscriber of managing a large number of authenticators. Binding of these authenticators SHALL be done as described in Sec. 6.1.2. In situations where the authenticator strength is not self-evident (e.g., between single-factor and multi-factor authenticators of a given type), the CSP SHALL assume the use of the weaker authenticator unless it is able to establish that the stronger authenticator is in fact being used (e.g., by verification with the issuer or manufacturer of the authenticator).
The subscriber SHOULD bind a new or updated authenticator an appropriate amount of time before an existing authenticator’s expiration. The process for this SHOULD conform closely to the binding process for an additional authenticator described in Sec. 6.1.2.1. The CSP MAY periodically take other actions, such as reconfirming address of record, either as a part of the renewal process or separately. Following successful use of the replacement authenticator, the CSP MAY invalidate the authenticator that is expiring.
Compromised authenticators include those that have been lost, stolen, or subject to unauthorized duplication. Generally, one must assume that a lost authenticator has been stolen or compromised by someone that is not the legitimate subscriber of the authenticator. Damaged or malfunctioning authenticators are also considered compromised to guard against any possibility of extraction of the authenticator secret. One notable exception is a memorized secret that has been forgotten without other indications of having been compromised, such as having been obtained by an attacker.
Suspension, revocation, or destruction of compromised authenticators SHOULD occur as promptly as practical following detection. Organizations SHOULD establish time limits for this process.
To facilitate secure reporting of the loss, theft, or damage to an authenticator, the CSP SHOULD provide the subscriber with a method of authenticating to the CSP using a backup or alternate authenticator. This backup authenticator SHALL be either a memorized secret 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 to the CSP and verify information collected during the proofing process. The CSP MAY choose to verify an address of record (i.e., email, telephone, postal) and suspend authenticators reported to have been compromised. The suspension SHALL be reversible if the subscriber successfully authenticates to the CSP using a valid (i.e., not suspended) authenticator and requests reactivation of an authenticator suspended in this manner. The CSP MAY set a time limit after which a suspended authenticator can no longer be reactivated.
CSPs MAY issue authenticators that expire. If and when an authenticator expires, it SHALL NOT be usable for authentication. When an authentication is attempted using an expired authenticator, the CSP SHOULD give an indication to the subscriber that the authentication failure is due to expiration rather than some other cause.
The CSP SHALL require subscribers to surrender or prove destruction of any physical authenticator containing attribute certificates signed by the CSP as soon as practical after expiration or receipt of a renewed authenticator.
Invalidation of an authenticator (sometimes referred to as revocation or termination) refers to removal of the binding between an authenticator and a subscriber account.
CSPs SHALL invalidate authenticators promptly when a subscriber account ceases to exist (e.g., subscriber’s death, discovery of a fraudulent subscriber), when requested by the subscriber, or when the CSP determines that the subscriber no longer meets its eligibility requirements.
The CSP SHALL require subscribers to surrender or certify destruction of any physical authenticator containing subscriber attributes, such as certificates signed by the CSP, as soon as practical after invalidation takes place. This is necessary to protect the privacy of the subscriber and to block the use of any certificates in offline situations between invalidation and expiration of the certificates.
Further requirements on the invalidation of PIV authenticators are found in [FIPS201].