Identity Management Security Checklist

AID:

Category:

wdt_ID	AID	Category	Requirement	Guidance	Procedure
1	1	Authentication Assurance Level	Authentication SHALL occur by the use of either a multi-factor authenticator or a combination of two single-factor authenticators.	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.	Determine if the Credential Service Provider (CSP) requires the use of two single-factor authenticators or one multi-factor authenticator in all cases at the Authentication Assurance Level (AAL).
2	2	Authentication Assurance Level	If the multi-factor authentication process uses a combination of two single-factor authenticators, then it SHALL include a Memorized Secret authenticator and a possession-based authenticator.	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.	Determine that all combinations of single-factor authenticators usable at the Authentication Assurance Level (AAL) include both a memorized secret and a possession-based authenticator,
3	3	Authentication Assurance Level	At least one authenticator used at the Authentication Assurance Level (AAL) SHALL be replay resistant.	Replay resistance is a characteristic of most, although not all, physical authenticators. A given output of the authenticator is required to be accepted for only one authentication transaction. For example, the output of a time-based OTP device or an out-of-band device is considered replay resistant if it can only be used for at most one authentication transaction during its validity period. If it can be used for more than one during this period, it is not replay resistant.	Ensure that the authentication transaction cannot be replayed by an attacker. If verifying a physical authenticator that does not implement a cryptographic challenge/response protocol, attempt to authenticate more than once using the same authenticator output (during its validity period, if time-based). If a subsequent authentication succeeds, the test of replay resistance has failed.
4	4	Authentication Assurance Level	Communication between the claimant and verifier SHALL be via an authenticated protected channel.	Communication between claimant and verifier is required to be via an encrypted channel that authenticates the verifier to provide confidentiality of the authenticator output and resistance to MitM attacks. This is typically accomplished using the Transport Level Security (TLS) protocol. Mutual authentication of the communication channel is not required unless that is part of the process of authenticating the claimant. Accordingly, the verifier is only responsible the use of an appropriately secure communications protocol.	Examine the verifier’s API documentation to ensure that TLS or a similarly secure protocol is used in conjunction with an approved encryption protocol
5	5	Authentication Assurance Level	If a device such as a smartphone is used in the authentication process, then the unlocking of that device (typically done using a PIN or biometric) SHALL NOT be considered one of the authentication factors.	This requirement applies to multi-factor authenticators resident on a smartphone or similar device; single-factor authenticators on such devices would only provide a single (physical) authentication factor. Unlocking of a device such as a smartphone may be done for any number of reasons unrelated to authentication, and such devices are normally in an unlocked state for a period of time thereafter. Human action such as entry of a memorized secret or presentation of a biometric factor needs to be provided that is directly associated with the authentication event. Generally, it is not possible for a verifier to know that the device had been locked or if the unlock process met the requirements for the relevant authenticator type.	Attempt to authenticate using supported smartphones and similar devices and observe that presentation of an authentication factor (memorized secret or biometric factor) is required at the time of authentication.
6	6	Authentication Assurance Level	Reauthentication of the subscriber SHALL be repeated at least once per 12 hours during an extended usage session.	Reauthentication is required to mitigate the risks associated with an authenticated endpoint that has been abandoned by the subscriber or has been misappropriated by an attacker while authenticated. At the Authentication Assurance Level (AAL), providing a memorized secret or biometric factor is sufficient for reauthentication prior to the expiration time.	Authenticate, then idle for 30 minutes and determine that reauthentication is required. Maintain a session for at least 12 hours and observe that reauthentication is required.
7	7	Authentication Assurance Level	Reauthentication of the subscriber SHALL be repeated following any period of inactivity lasting 30 minutes or longer.	Reauthentication is required to mitigate the risks associated with an authenticated endpoint that has been abandoned by the subscriber or has been misappropriated by an attacker while authenticated. At the Authentication Assurance Level (AAL), providing a memorized secret or biometric factor is sufficient for reauthentication prior to the expiration time.	Authenticate, then idle for 30 minutes and determine that reauthentication is required. Maintain a session for at least 12 hours and observe that reauthentication is required.
8	8	Authentication Assurance Level	The session SHALL be terminated (i.e., logged out) when either the extended usage or inactivity time limit is reached.	If reauthentication is not performed in accordance with the Authentication Assurance Level (AAL) requirements the session needs to be logged out at that time.	Authenticate, then idle for 30 minutes and determine that the session is logged out. Maintain a session for at least 12 hours and determine that the session is logged out.
9	9	Memorized Secret Verifiers	If chosen by the subscriber, memorized secrets SHALL be at least 8 characters in length.	Memorized secret length is the most reliable metric determining strength against online and offline guessing attacks. The objective is primarily to defend against online attacks (with throttling of guesses) and to provide some protection against offline attacks, with the primary defense for such attacks being secure storage of the verifier.	Determine if the minimum memorized secret length is enforced. Attempt to enroll or change a memorized secret with less than the required length. The user should be re-prompted with an explanation if this occurs.
10	10	Memorized Secret Verifiers	Memorized secret verifiers SHALL NOT permit the subscriber to store a “hint” that is accessible to an unauthenticated claimant.	The availability of memorized secret hints greatly weakens the strength of memorized secret authenticators.	Determine if password hints and prompts are provided to the user.
11	11	Memorized Secret Verifiers	Verifiers SHALL NOT prompt subscribers to use specific types of information (e.g., “What was the name of your first pet?”) when choosing memorized secrets.	Prompts for specific information (often called Knowledge-based Authentication or Security Questions) encourage use of the same memorized secrets at multiple sites, which causes a vulnerability to “password stuffing” attacks. This guidance applies to account recovery situations as well as normal authentication.	Attempt to authenticate (including “forgot password” situations) and determine that there is no use of knowledge-based authentication.
12	12	Memorized Secret Verifiers	When processing requests to establish and change memorized secrets, verifiers SHALL compare the prospective secrets against a list that contains values known to be commonly used, expected, or compromised.	The maintenance of a list of common memorized secrets that cannot be used by users provides protection against online attacks that might otherwise succeed before throttling mechanisms take effect to defend against these attacks. This is an alternative to the use of composition rules (requirements for particular character types, etc.) and can provide more customized protection against common memorized secrets. This list may include, but is not limited to: • Passwords obtained from previous breach corpuses. • Dictionary words. • Repetitive or sequential characters (e.g. ‘aaaaaa’, ‘1234abcd’). • Context-specific words, such as the name of the service, the username, and derivatives thereof.	Determine that a memorized secret “blocklist” exists and is used.
13	13	Memorized Secret Verifiers	Verifiers SHALL implement a rate-limiting mechanism that effectively limits the number of failed authentication attempts that can be made on the subscriber’s account.	Rate limiting restricts the ability of an attacker to make many online guessing attacks on the memorized secret. Other requirements (e.g., minimum length of memorized secrets) depend on the existence of rate limiting, so effective rate limiting is an essential capability. Ideally, a rate limiting mechanism should restrict the attacker as much as possible without creating an opportunity for a denial-of-service attack against the subscriber.	Make repeated attempts to authenticate with the wrong memorized secret and determine that it is not possible to successfully authenticate immediately following a large number of incorrect attempts.
14	14	Memorized Secret Verifiers	Verifiers SHALL force a change of memorized secret if there is evidence of compromise of the authenticator.	Although requiring routine periodic changes to memorized secrets is not recommended, it is important that verifiers have the capability to prompt memorized secrets on an emergency basis if there is evidence of a possible successful attack.	Determine that the capability exists to force memorized secret changes when a compromise is suspected.
15	15	Memorized Secret Verifiers	The verifier SHALL use approved encryption when requesting memorized secrets in order to provide resistance to eavesdropping and MitM attacks.	Cryptography is considered approved if it is specified or adopted in a FIPS or NIST recommendation.	Ensure that only secure, well-vetted cryptographic algorithms are being used.
16	16	OTP Verifiers	OTP authenticators — particularly software-based OTP generators —SHALL NOT facilitate the cloning of the secret key onto multiple devices.	Like other physical authenticators, the use of OTP authenticators is premised upon the authenticator secret being present in a single authenticator so that it proves possession of a specific device. Mechanisms that would facilitate cloning the secret onto multiple devices include the ability to enroll more than one device producing the same OTP output and backup mechanisms, especially when software-based authenticators are used. Verifiers are expected to make their best effort at determining that bring-your-own authenticators not issued by them meet this requirement and to have policies not allowing the use of non-compliant authenticators.	Determine that the management of authenticator secrets is sufficiently secure to ensure that authenticators have unique secrets.
17	17	OTP Verifiers	If the nonce used to generate the authenticator output is based on a real-time clock, then the nonce SHALL be changed at least once every 2 minutes.	The authenticator output needs to be changed often enough that there is reasonable assurance that it is in the possession of the claimant and that it is not susceptible to OTP-guessing attacks.	Determine that the output of time-based OTP authenticators changes often enough.
18	18	OTP Verifiers	The OTP value associated with a given nonce SHALL be accepted only once.	fundamental premise of a “one-time” authenticator is that it can be used successfully only once during its validity period.	Determine that it is not possible to successfully authenticate more than once using the same authenticator output (during the validity period, if time-based).
19	19	OTP Verifiers	If a time-based OTP is used, it SHALL have a defined lifetime that is determined by the expected clock drift — in either direction — of the authenticator over its lifetime, plus allowance for network delay and user entry of the OTP.	The clocks on time-based authenticators are subject to drift because of cost and environmental factors such as temperature. Accordingly, verifiers need to accept authenticator outputs before and particularly after the intended validity period to allow use by authenticators that are not in synchronization.	Determine that verifiers provide an appropriate “grace period” around the expected validity window.
20	20	OTP Verifiers	Verifiers SHALL accept a given time-based OTP only once during the validity period.	In order to prevent an attacker who gains access to an OTP authenticator output from using it, it is important that the secret only be valid for a single authentication.	Determine that it is not possible to successfully authenticate more than once using the same authenticator output (during the validity period, if time-based).
21	21	Cryptographic Verifiers	If the cryptographic authenticator is software based, the key SHALL be stored in suitably secure storage available to the authenticator application.	Although dependent on the computing device on which the authenticator is operating, authenticator software needs to avail itself of the most secure storage available, considering issues like ability to extract the secret from the device and its potential to be included in backup data. Verifiers are expected to make their best effort at determining that bring-your-own authenticators not issued by them meet this requirement and to have policies not allowing the use of non-compliant authenticators.	Ensure that the authenticator is storing secret keys appropriately.
22	22	Cryptographic Verifiers	If the cryptographic authenticator is software based, the key SHALL be strongly protected against unauthorized disclosure by the use of access controls that limit access to the key to only those software components on the device requiring access.	Although dependent on the computing device on which the authenticator is operating, authenticator software needs to store secret keys in a manner that limits access to keys to the maximum extent possible so that they cannot be accessed by other (possibly rogue) applications and/or users. Verifiers are expected to make their best effort at determining that bring-your-own authenticators not issued by them meet this requirement and to have policies not allowing the use of non-compliant authenticators.	Ensure that the authenticator is storing secret keys appropriately.
23	23	Cryptographic Verifiers	If the cryptographic authenticator is software based, it SHALL NOT facilitate the cloning of the secret key onto multiple devices.	Like other physical authenticators, the use of cryptographic authenticators is premised upon the authenticator secret being present in a single authenticator so that it proves possession of a specific device. Mechanisms that would facilitate cloning the secret onto multiple devices include the ability to enroll more than one device with the same key and backup mechanisms, especially when software-based authenticators are used. Verifiers are expected to make their best effort at determining that bring-your-own authenticators not issued by them meet this requirement and to have policies not allowing the use of non-compliant authenticators.	Determine that the management of authenticator secrets is sufficiently secure to ensure that authenticators have unique secrets.
24	24	Cryptographic Verifiers	If the authenticator is hardware-based, approved cryptography SHALL be used.	Cryptography is considered approved if it is specified or adopted in a FIPS or NIST recommendation. Since verifiers and cryptographic authenticators must use the same algorithms to successfully authenticate, assessment of the verifier also assesses the authenticators that may be used.	Determine that the secret key is sufficiently complex.
25	25	Cryptographic Verifiers	Cryptographic keys stored by the verifier SHALL be protected against modification.	Protection against modification is required for all keys to ensure that an attacker can’t substitute keys they control, which would permit them to authenticate successfully. This protection could be provided by operating system access controls, or through integrity checks of the stored keys with separately stored hashes.	Determine if keys stored in the verifier have appropriate protection against modification.
26	26	Cryptographic Verifiers	If a multi-factor cryptographic software authenticator is being used, then each authentication requires the presentation of the activation factor.	The activation factor, either a memorized secret or a biometric, is required to be presented each time an authentication operation is requested by the authenticator to ensure that an activated authenticator cannot be used by an attacker.	Perform multiple authentications and verify that the activation factor is required each time.
27	27	Cryptographic Verifiers	If the authenticator is multi-factor, then use of a memorized secret for activation SHALL be rate limited.	Rate limiting is required to provide protection against brute-force guessing attacks, particularly if the authenticator gives an indication when an incorrect secret is entered.	Make repeated attempts to authenticate with the wrong memorized secret and determine that it is not possible to successfully authenticate immediately following a large number of incorrect attempts.
28	28	General Authentication Criteria	CSPs SHALL provide subscriber instructions on how to appropriately protect a physical authenticator against theft or loss.	Instruction should address aspects of protecting the specific type of authenticator being used.	Examine briefing handouts or procedures for issuing physical authenticators to determine that the subscriber was briefed on the importance of protecting the authenticator and strategies for doing so.
29	29	General Authentication Criteria	The Credential Service Provider (CSP) SHALL provide a mechanism to revoke or suspend the authenticator immediately upon notification from subscriber that loss or theft of the authenticator is suspected.	The Credential Service Provider (CSP) needs to have a documented procedure to allow subscribers to report lost or stolen physical authenticators, and to revoke or suspend such authenticators promptly when reported. Subscribers need to be instructed on the procedure for reporting loss or theft.	Examine procedures for accepting and processing reports of lost or stolen physical authenticators to determine that effective procedures exist.
30	30	General Authentication Criteria	If the Credential Service Provider (CSP) provides the subscriber with a means to report loss, theft, or damage to an authenticator using a backup or alternate authenticator, then that authenticator SHALL be either a memorized secret or a physical authenticator.	It is important that the loss of control of an authenticator be quickly reported to the Credential Service Provider (CSP). To balance between the need to easily and promptly report this and the risk of a fraudulent report, a backup authenticator, either a memorized secret or physical authenticator, should be usable by the subscriber to make this report. Only a single, single-factor authenticator is required.	Using a test account and the backup authenticator for that account, make a lost authenticator report to the Credential Service Provider (CSP) and determine that the authenticator is suspended properly.
31	31	General Authentication Criteria	If the Credential Service Provider (CSP) chooses to verify an address of record (i.e., email, telephone, postal) and suspend authenticator(s) reported to have been compromised, then...The suspension SHALL be reversible if the subscriber successfully authenticates to the Credential Service Provider (CSP) using a valid (i.e., not suspended) authenticator and requests reactivation of an authenticator suspended in this manner.	Reversibility of suspension is intended to minimize the impact of inadvertent loss reports from the subscriber and in some cases from an attacker who may be attempting to deny service to the subscriber.	Using a test account and an associated authenticator other than that which was reported lost, revert a loss report previously made to the Credential Service Provider (CSP) and determine that it the suspended authenticator is reinstated.
32	32	General Authentication Criteria	If and when an authenticator expires, it SHALL NOT be usable for authentication.	Expiration is used by some CSPs to limit the security exposure from an authenticator that is lost but the loss has not been detected/reported and revoked.	Using an authenticator that has expired, attempt to authenticate and determine that this cannot be done successfully.
33	33	General Authentication Criteria	The Credential Service Provider (CSP) SHALL require subscribers to surrender or prove destruction of any physical authenticator containing attribute certificates signed by the Credential Service Provider (CSP) as soon as practical after expiration or receipt of a renewed authenticator.	The requirement for surrender or destruction of expired authenticators minimizes the possibility that authentication with an expired authenticator will be attempted. PKI-based authenticators that are collected or known to be destroyed also do not need to be included in certificate revocation lists.	Examine Credential Service Provider (CSP) procedures for handling of authenticators that expire to determine that collection and/or destruction are performed.
34	34	General Authentication Criteria	CSPs SHALL revoke the binding of authenticators promptly when an online identity 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.	Prompt revocation ensures that unauthorized parties are not able to use the authenticator to make unauthorized access to the subscriber account. Revocation at subscriber request can affect only a single authenticator; the other classes of revocation generally affect all authenticators associated with the subscriber’s account.	Determine if procedures exist to properly revoke authenticators upon request from the subscriber, when an account ceases to exist, or when the subscriber is no longer eligible
35	35	Biometrics	Biometrics SHALL be used only as part of multi-factor authentication with a physical authenticator (something you have).	For a variety of reasons outlined in Section 5.2.3, a biometric factor is not considered to be an authenticator by itself. The risks associated with biometric factors are largely mitigated by binding the biometric with a specific physical authenticator.	Determine if all use of biometrics for authentication is in conjunction with a physical authenticator.
36	36	Biometrics	An authenticated protected channel between a sensor (or an endpoint containing a sensor that resists sensor replacement) and verifier SHALL be established.	This requirement ensures that biometric data that flows across the network to the verifier is protected from disclosure and that an attacker cannot substitute a “skimmer” or other fraudulent replacement for the biometric sensor. If the biometric factor is verified directly on a multi-factor authenticator and the sensor is tightly integrated with it, that local connection does not require an authenticated protected channel.	Examine documentation describing the communication protocol used between sensors and verifiers.
37	37	Biometrics	The sensor or endpoint SHALL be authenticated prior to capturing the biometric sample from the claimant.	This requirement ensures that the biometric data being verified is obtained from the expected sensor rather than from a device that may be spoofing biometric information. This is generally not required when the biometric factor is verified in an endpoint that is tightly integrated with the sensor in a manner that resists sensor replacement.	Examine documentation describing integration of the sensor and endpoint or the method of authenticating the sensor.
38	38	Biometrics	The biometric system SHALL operate with an False Match Rate (FMR) [ISO/IEC 2382-37] of 1 in 1000 or better. This FMR SHALL be achieved under conditions of a conformant attack (i.e., zero-effort impostor attempt) as defined in [ISO/IEC 30107-1]	Since biometric comparison is an approximate match, an operating point threshold is chosen by the verifier that balances false matches and false non-matches. To operate adequately as a verifier, a 1 in 1000 or better false match rate is required.	Examine testing results to determine that a better than 1 in 1000 false match rate Is achieved by the biometric system.
39	39	Biometrics	The biometric system SHALL allow no more than 5 consecutive failed authentication attempts or 10 consecutive failed attempts if Presentation Attack Detection (PAD) demonstrating at least 90% resistance to presentation attacks is implemented.	With a false accept rate of as much as 1 in 1000 zero-effort attempts, the ability to make a large number of biometric authentication attempts would result in an unacceptably high probability of mis-authentication. This limit is comparable to that provided by several commercial products (mobile devices) currently on the market.	Attempt to authenticate several times with an invalid biometric (e.g., wrong fingerprint) and determine that that an alternate factor is requested or delays are imposed after the appropriate number of consecutive failures.
40	40	Biometrics	Once the limit on authentication failures has been reached, the biometric authenticator SHALL either: (1) Impose a delay of at least 30 seconds before the next attempt, increasing exponentially with each successive attempt, or (2) disable the biometric user authentication and offer another factor (e.g., a different biometric modality or a PIN/Passcode if it is not already a required factor) if such an alternative method is already available.	Following a number of consecutive biometric match failures that exceeds the limit in the previous requirement, subsequent attempts need to be either aggressively delayed (e.g., 1 minute before the following failed attempt, 2 minutes before the second following attempt) or another authentication or biometric modality associated with the same physical authenticator needs to be used.	Attempt to authenticate several times with an invalid biometric (e.g., wrong fingerprint) and determine that that an alternate factor is requested or delays are imposed after the appropriate number of consecutive failures.
41	41	Biometrics	The verifier SHALL make a determination of sensor and endpoint performance, integrity, and authenticity.	The verifier needs to have a basis for determining that biometric verification meets the necessary performance requirements. This may be accomplished by authenticating the sensor or endpoint, by a certification by an approved accreditation authority, or by runtime interrogation of a signed attestation.	Examine documentation to establish that the verifier determines that the sensor and endpoint are required to meet the necessary performance requirements.
42	42	Biometrics	If biometric comparison is performed centrally, then use of the biometric as an authentication factor SHALL be limited to one or more specific devices that are identified using approved cryptography.	The ability to use a biometric factor on an arbitrary device greatly increases the value of breached biometric data. For this reason, the use of the biometric factor is limited to specific devices for each subscriber. A separate key is required since the main authentication key is only unlocked upon successful comparison of the biometric factor.	Determine if the biometric factor can only be used from specific devices by examining design documentation and user interface flows to understand how the endpoint is authenticated in conjunction with the use of the biometric, the manner in which the biometric factor is individually associated with each device to be used, and that the necessary authentication is accomplished using approved cryptography
43	43	Biometrics	If biometric comparison is performed centrally, all transmission of biometrics SHALL be over the authenticated protected channel.	Because of the replay potential of biometric data, biometric information needs to be distributed in a manner that minimizes the opportunity for attackers to intercept the data either by eavesdropping on man-in-the-middle attacks.	Determine if an authenticated protected channel is used for transmitting biometric data by observing communication traffic.
44	44	Biometrics	Biometric samples and any biometric data derived from the biometric sample such as a probe produced through signal processing SHALL be zeroized immediately after any training or research data has been derived.	If the biometric factor is used for any supplemental purpose, it is important that it not be a mechanism for breach of subscribers’ biometric data.	Examine procedures for research and training use of biometric data and determine that the biometric data is securely cleared at the earliest possible opportunity.
45	45	Authenticator Binding	Throughout the digital identity lifecycle, CSPs SHALL maintain a record of all authenticators that are or have been associated with each identity.	In order to authenticate subscribers successfully, the Credential Service Provider (CSP) needs to maintain a record of authenticators bound to each subscriber’s account. In addition, a record of authenticators formerly bound to each account needs to be kept for forensic purposes.	Determine if the Credential Service Provider (CSP) maintains the necessary records.
46	46	Authenticator Binding	The Credential Service Provider (CSP) SHALL also verify the type of user-provided authenticator so verifiers can determine compliance with requirements at each Authentication Assurance Level (AAL).	In order to determine compliance with Authentication Assurance Level (AAL)-specific requirements, the Credential Service Provider (CSP) needs to reliably determine some authenticator characteristics, such as whether the authenticator is hardware-based, whether it is a single-factor or multi-factor authenticator, and performance characteristics of associated biometric sensors. Mechanisms to do this include attestation certificates from the manufacturer and examination of the authenticator (particularly at account issuance). In the absence of this information, the Credential Service Provider (CSP) needs to assume that the authenticator is the weakest type that is consistent with the authentication protocol being used.	Determine if the Credential Service Provider (CSP) verifies authenticator types and uses that information when determining the Authentication Assurance Level (AAL).
47	47	Authenticator Binding	The record created by the Credential Service Provider (CSP) SHALL contain the date and time the authenticator was bound to the account.	For forensic purposes it is useful to have a record of the period of time each authenticator is bound to the subscriber’s account.	Determine if the Credential Service Provider (CSP) maintains the necessary records.
48	48	Authenticator Binding	If enrollment and binding are being done remotely and cannot be completed in a single electronic transaction, then 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.	The issuance or binding of authenticators may occur well after the enrollment process, following adjudication and eligibility determinations. It is necessary to securely associate the applicant that appears for identity proofing with the person appearing for authenticator issuance/binding in order to avoid mis-issuance of authenticators. At this point it is not possible to fully authenticate the applicant, but the use of a temporary secret provides the necessary protection for this one-time transaction.	Observe if binding and enrollment take place in separate sessions, determine that Credential Service Provider (CSP) procedures include the issuance of a unique temporary secret that the applicant presents in order to perform authenticator binding.
49	49	Authenticator Binding	If enrollment and binding are being done in person and cannot be completed in a single physical encounter, the applicant SHALL identify themselves in person by either using a secret as described above, or through use of a biometric that was recorded during a prior encounter.	The issuance or binding of authenticators may occur well after the enrollment process, following adjudication and eligibility determinations. It is necessary to securely associate the applicant that appears for identity proofing with the person appearing for authenticator issuance/binding in order to avoid mis-issuance of authenticators. At this point it is not possible to fully authenticate the applicant, but the use of a temporary secret provides the necessary protection for this one-time transaction.	Examine if binding and enrollment take place in separate sessions, determine that Credential Service Provider (CSP) procedures include the issuance of a unique temporary secret that the applicant presents in order to perform authenticator binding, or by biometric comparison with a biometric recorded during a previous encounter.
50	50	Authenticator Binding	If enrollment and binding are being done in person and cannot be completed in a single physical encounter, temporary secrets SHALL NOT be reused.	The issuance or binding of authenticators may occur well after the enrollment process, following adjudication and eligibility determinations. It is necessary to securely associate the applicant that appears for identity proofing with the person appearing for authenticator issuance/binding in order to avoid mis-issuance of authenticators. A new secret for this purpose is required for each subsequent encounter.	If binding and enrollment take place in separate in-person sessions, determine that Credential Service Provider (CSP) procedures include the issuance of a new unique temporary secret for each subsequent interaction.
51	51	Authenticator Binding	Before adding a new authenticator to a subscriber’s account, the Credential Service Provider (CSP) SHALL first require the subscriber to authenticate at the Authentication Assurance Level (AAL) (or a higher AAL) at which the new authenticator will be used.	In order to maintain the significance of Authentication Assurance Levels (AAL) and prevent attackers from leveraging lower AAL authentication to gain access to higher AAL resources, subscribers binding additional authenticators need to do so at the maximum AAL at which they will be used.	Determine that the binding process for additional authenticators requires the subscriber to authenticate at the maximum Authentication Assurance Level (AAL) at which the new authenticator will be used.
52	52	Authenticator Binding	If the subscriber’s account has only one authentication factor bound to it, the Credential Service Provider (CSP) SHALL require the subscriber to authenticate at AAL in order to bind an additional authenticator of a different authentication factor.	This is a special-case to allow a single-factor account to be upgraded to a multi-factor account. This provides a mechanism for such accounts to increase their authentication security.	Establish a single-factor account and attempt to add an additional authenticator of a different factor to it and determine that it requires user authentication.
53	53	Authenticator Binding	Subscribers who have been identity proofed at the Identity Assurance Level (IAL) and lose all authenticators of a factor necessary for multi-factor authentication SHALL reestablish authentication factors in person, or through a supervised remote process.	This is a supplemental requirement to ensure that the process used for Identity Assurance Level (IAL) proofed subscribers has the additional strength necessary to support that level of identity assurance.	Establish an account that has been identity proofed at the Identity Assurance Level (IAL) and simulate the loss of an authentication factor (either a physical authenticator or a memorized secret). Observe the account-recovery procedures to determine that the repeated identity proofing process is also done either in person or via supervised remote identity proofing.
54	54	Authenticator Binding	Subscribers who have been identity proofed at the Identity Assurance Level (IAL) and lose all authenticators of a factor necessary for multi-factor authentication SHALL verify the biometric collected during the original proofing process	This is a supplemental requirement to ensure that the process used for Identity Assurance Level (IAL) proofed subscribers has the additional strength necessary to support that level of identity assurance, since identity proofing at Identity Assurance Level (IAL) requires the collection of a biometric characteristic.	Establish an account that has been identity proofed at the Identity Assurance Level (IAL) and simulate the loss of an authentication factor (either a physical authenticator or a memorized secret). Observe the account-recovery procedures to determine that the repeated identity proofing process requires a match against the biometric collected during the original proofing process.
55	55	Session Management	A session is maintained by a session secret which SHALL be shared between the subscriber’s software and the service being accessed.	This secret binds the two ends of the session, allowing the subscriber to continue using the service over time.	Determine if session management is based on a secret that is shared by the session endpoints.
56	56	Session Management	The secret used for session binding SHALL be generated by the session host in direct response to an authentication event.	The session secret needs to be directly associated with authentication so that it isn’t inadvertently provided to the wrong session.	Determine if the session management secret is generated properly and associated with a maximum Authentication Assurance Level (AAL) at which it is valid.
57	57	Session Management	Secrets used for session binding SHALL be generated by an approved random bit generator	The use of a high-quality random bit generator is important to ensure that an attacker cannot guess the session secret.	Determine if the session management secret is securely generated.
58	58	Session Management	Secrets used for session binding SHALL be erased or invalidated by the session subject when the subscriber logs out.	At a minimum, the Credential Service Provider (CSP)/Relying Party (RP) needs to ensure that the session secret can no longer to be used following logout. If possible, the secret should be erased on the subscriber endpoint as well.	Make a copy of a session secret at the user endpoint, log out, and try to present the secret again as if logout had not occurred, and determine that it is no longer accepted.
59	59	Session Management	Secrets used for session binding SHALL be sent to and received from the device using an authenticated protected channel.	Session secrets, particularly when directly presented, need to be protected against eavesdropping and man-in-the-middle attacks. This is typically accomplished using the Transport Level Security (TLS) protocol.	Attempt to manually downgrade an active session (e.g., from https to http) and determine that the downgraded packets are not associated with the session.
60	60	Session Management	Secrets used for session binding SHALL NOT be available to insecure communications between the host and subscriber’s endpoint.	User endpoints such as browsers that support both secure and insecure communications typically have mechanisms to flag information (e.g., cookies) that are only available to secure sessions. These mechanisms are required to be used for session management secrets.	Attempt to manually downgrade an active session (e.g., from https to http) and determine that the downgraded packets are not associated with the session. Determine if the session management secret is tagged to be available only to secure sessions.
61	61	Session Management	Authenticated sessions SHALL NOT fall back to an insecure transport, such as from https to http, following authentication.	In some cases, endpoints supporting https provide, primary for legacy purposes, the ability to connect via http as well. If not done properly, this can make the site vulnerable to a “downgrade attack” where a session switches from https to http. This must not happen for authenticated sessions. If session secrets are managed properly, this downgrade interferes with the continuity of the session.	Attempt to manually downgrade an active session (e.g., from https to http) and determine that the downgraded packets are not associated with the session.
62	62	Session Management	URLs or POST content SHALL contain a session identifier that SHALL be verified by the Relying Party (RP) to ensure that actions taken outside the session do not affect the protected session.	Unique session identifiers in the URL or POST content are used to ensure that sessions are not vulnerable to cross-site request forgery (CSRF). Note that the session identifier is separate and different from the session secret; under no circumstances should the session secret be included in a URL.	Examine URLs and/or POST content to determine that session identifiers are present as required. Attempt to perform a transaction with an incorrect session identifier and verify that transactions with the wrong session identifier are not honored.
63	63	Session Management	Browser cookies SHALL be tagged to be accessible only on secure (HTTPS) sessions.	Browser cookies have an optional “secure” flag to ensure that they are not accidentally transmitted over a non-secure channel. This flag must be set for session secrets.	Observe the browser cookies at a user endpoint during an active session and ensure that cookies containing session secrets have the secure flag set.
64	64	Session Management	Expiration of browser cookies SHALL NOT be dependet upon to enforce session timeouts.	While browser cookies have an expiration time, enforcement of session timeouts must occur at the Relying Party (RP)/Credential Service Provider (CSP) and not at the user endpoint. Cookie expiration may, however, be used to limit accumulation of cookies in the browser.	Extend the lifetime of a session secret cookie in the browser to exceed the session timeout and verify that it is not possible to maintain the session for longer than the permitted reauthentication time.
65	65	Session Management	Session secrets SHALL be non-persistent, i.e., they SHALL NOT be retained across a restart of the associated application or a reboot of the host device.	Session secrets are not to be maintained across a restart of the associated application or a reboot of the host device in order to minimize the likelihood that a misappropriated logged in device can be exploited.	Determine if session management secrets are maintained in non-persistent storage or flagged as non-persistent (e.g., for browser cookies)
66	66	Reauthentication	Periodic reauthentication of sessions SHALL be performed to confirm the continued presence of the subscriber at an authenticated session.	In order to protect against a subscriber leaving a logged-in endpoint, timeouts are defined for session inactivity and overall session length. The timer for these timeouts is reset by a reauthentication transaction. Higher Authentication Assurance Levels (AALs) have more stringent (shorter) reauthentication timeouts. Following expiration of the session timer, the subscriber is required to start a new session by authenticating.	Begin a session (authenticate) and allow the session to expire. Determine that the session is terminated at the end of the session timeout period. This test should be performed for both inactivity and total session timers.
67	67	Reauthentication	Prior to session expiration, the reauthentication time limit SHALL be extended by prompting the subscriber for the authentication factor(s), any one factor at the Authentication Assurance Level (AAL), a memorized secret or biometric at the Authentication Assurance Level (AAL), and full reauthentication.	Before the session times out, the subscriber should be given an opportunity to reauthenticate to extend the session. The subscriber may be prompted when an idle timeout is about to expire, to allow them to cause activity and thereby avoid the need to reauthenticate.	Determine if proper reauthentication methods are used.
68	68	Reauthentication	When a session has been terminated, due to a time-out or other action, the user SHALL be required to establish a new session by authenticating again.	After the session time-out, the session is terminated. A new session needs to be established, and full authentication requirements for the session Authentication Assurance Level (AAL) need to be satisfied.	Determine sessions are fully logged out at the expiration of the reauthentication time.
	AID	Category