Federal RPs SHALL implement the DIRM process for all online services.

Determine if all online services of the Federal RP are identified and ensure the DIRM process is implemented for those online services.

For relying parties, the intent of [the DIRM] process is to determine the assurance levels and any tailoring required to protect all online services and the applications, transactions, and systems that comprise or are impacted by those services. This directly contributes to the selection, development, and procurement of CSP services.

Whenever a service offering deviates from normative guidance, those deviations SHALL be clearly communicated to the RPs that utilize the service.

Ensure that the CSP/IdP has a documented process for communicating when their services deviate from the established normative guidance of the applicable NIST SP 900-63 requirements.

For credential service providers and identity providers, the intent of [the DIRM] process is to design service offerings that meet the requirements of the defined assurance levels, continuously guard against compromises to the identity system, and meet the needs of RPs.

At a minimum, organizations SHALL execute and document each step and complete and document the normative mandates and outcomes of each step, regardless of any organization-specific processes or tools used in the overall DIRM process.

Determine that each step of the DIRM process is executed and documented.

This requirement is agnostic to any organization-specific processes or tools used in the overall DIRM process.(Ref. Sec. 3.0 #A)

RPs SHALL develop a description of the online service that includes the organizational mission and business objectives supported by the online service.

Determine if a description of the online service has been developed that includes the organizational mission and business objectives that are supported by the online service.

The purpose of this initial step is to establish a common understanding of the online service's context and functionality, which is essential for informing the subsequent risk assessment steps of the DIRM process.

RPs SHALL develop a description of the online service that includes the mission and business partner dependencies associated with the online service.

Determine if a description of the online service has been developed that includes the mission and business partner dependencies associated with the online service.

The purpose of this initial step is to establish a common understanding of the online service's context and functionality, which is essential for informing the subsequent risk assessment steps of the DIRM process.

RPs SHALL develop a description of the online service that includes legal, regulatory, and contractual requirements, including privacy obligations that apply to the online service.

Determine if a description of the online service has been developed that includes the legal, regulatory, and contractual requirements, including obligations that apply to the online service.

The purpose of this initial step is to establish a common understanding of the online service's context and functionality, which is essential for informing the subsequent risk assessment steps of the DIRM process.

RPs SHALL develop a description of the online service that includes the functionality of the online service and the data that it is expected to process.

Determine if a description of the online service has been developed that includes the functionality of the online service and the data that it is expected to process.

The purpose of this initial step is to establish a common understanding of the online service's context and functionality, which is essential for informing the subsequent risk assessment steps of the DIRM process.

RPs SHALL develop a description of the online service that includes user groups that need to have access to the online service as well as the types of online transactions and access privileges available to each user group.

Determine if a description of the online service has been developed that includes the user groups that need to have access to the online service.

The purpose of this initial step is to establish a common understanding of the online service's context and functionality, which is essential for informing the subsequent risk assessment steps of the DIRM process.

The set of entities includes users of the online service, organizations, and populations served.

It is crucial to differentiate between user groups and impacted entities.

(a) User groups are users who are partitioned based on the specific functionality or access privileges offered to them (e.g., citizens checking tax status vs. tax preparers filing returns).

(b) Impacted entities include everyone who could face negative consequences if the identity system fails. This group includes members of the user groups but also potentially those who never directly use the system.

RPs SHALL develop a description of the online service that includes the set of entities (to include users of the online service, organizations, and populations served) that will be impacted by the online service and the broader business process of which it is a part.

Determine if a description of the online service has been developed that includes the set of entities that will be impacted by the online service and the broader business process of which it is a part.

The purpose of this initial step is to establish a common understanding of the online service's context and functionality, which is essential for informing the subsequent risk assessment steps of the DIRM process. The set of entities includes users of the online service, organizations, and populations served.

RPs SHALL develop a description of the online service that includes the results of any preexisting DIRM assessments (as an input) and the current state of any preexisting identity technologies (i.e., proofing, authentication, or federation).

Determine if a description of the online service has been developed that includes the results of any preexisting DIRM assessments and the current state of any preexisting identity technologies.

The purpose of this initial step is to establish a common understanding of the online service's context and functionality, which is essential for informing the subsequent risk assessment steps of the DIRM process.

RPs SHALL develop a description of the online service that includes the estimated availability of the types of identity evidence required for identity proofing across all user groups served.

Determine if a description of the online service has been developed that includes the estimated availability of the types of identity evidence required for identity proofing across all user groups served.

The purpose of this initial step is to establish a common understanding of the online service's context and functionality, which is essential for informing the subsequent risk assessment steps of the DIRM process.

The scope of impact assessments SHALL include individuals who use the online service as well as the organization itself.

Determine if the scope of impact assessments includes impacts to individuals who use the online service and impacts to the organization.

Note: "online application" is the same as "online service".

The scope of impact assessments for organizations SHALL identify other entities (e.g., mission partners, communities, and those identified in [SP800-30]) that need to be specifically included based on mission and business needs.

Determine if the scope of impact assessments for organizations identify other entities that need to be specifically included based on mission and business needs.

DOS-3 deals with user groups.

At a minimum, organizations SHALL document all impacted entities (both internal and external to the organization) when conducting their impact assessments.

Determine if the scope of impact assessments for organizations identify all internal and external impacted entities.

DOS-4 deals with impacted entities.

The impact assessment SHALL include a set of impact categories and the potential harms for each impact category.

Determine that the impact assessment includes a set of impact categories and the potential harms for each impact category.

The impact assessment SHALL include identifying the levels of impact.

Determine that the impact assessment includes the levels of impact.

The impact assessment SHALL include assessing the level of impact for each user group.

Determine that the impact assessment includes an assessment of the level of impact for each user group.

The level of impact for each user group identified in Sec. 3.1 SHALL be considered separately based on the transactions available to that user group.

Determine if the levels of impact for each user group is considered separately based on the transactions available to that user group.

At a minimum, organizations SHALL include the following impact categories in their impact assessments:

(a) Degradation of mission delivery.

(b) Damage to trust, standing, or reputation.

(c) Unauthorized access to information.

(d) Financial loss or liability.

(e) Loss of life or danger to human safety, human health, or environmental health.

Determine if the impact categories in the impact assessments include degradation of mission delivery, damage to trust, standing, or reputation, unauthorized access to information, financial loss or liability, and loss of life or danger to human safety, human health, or environmental health.

Each impact category SHALL be documented and consistently applied when implementing the DIRM process across different online services offered by the organization.

Determine if, for each online service offered by the organization, each impact category is documented and applied as part of the DIRM process.

For each impact category, organizations SHALL consider potential harms for each of the impacted entities identified in Sec. 3.1

Determine if potential harms are identified for each impact category and each of the impacted entities.

To provide a more objective basis for impact level assignments, organizations SHOULD develop thresholds and examples for the impact levels for each impact category. Where this is done, particularly with specifically defined quantifiable values, these thresholds SHALL be documented and used consistently in the DIRM assessments across an organization to allow for a common understanding of risks.

PIL-1Obj1: Determine if thresholds and examples for the impact levels for each impact category have been developed. (0ptional) PIL-1Obj2: Determine if PIL-1Obj1 is documented and used consistently in the DIRM assessments. (conditional)

Assessment is required when: thresholds and examples for the impact levels were developed.

The impact analysis SHALL consider the level of impact for each impact category for each type of impacted entity if an intruder obtains unauthorized access as a member of each user group.

Determine if the impact analysis considers the level of impact resulting from unauthorized access, for each impact category for each type of impacted entity.

The impact analysis SHALL be performed for each user group that has access to the online service.

Determine if the impact analysis is performed for each user group that has access to the online service.

The output of this impact analysis is a set of impact levels for each user group that SHALL be documented for further analysis in accordance with Sec. 3.4.

Determine if the output of the impact analysis includes a documented set of impact levels.

Organizations SHALL document the approach they use to combine their impact assessment into an overall impact level for each of their defined user groups and SHALL apply it consistently across all of its online services.

At the conclusion of the combinatorial analysis, organizations SHALL document the impact for each user group.

Determine if the overall impact levels for each user group have been documented.

The RP SHALL identify the types of assurance levels that apply to their online service from the following:

(a) IAL: The robustness of the identity proofing process to determine the identity of an individual. The IAL is selected to mitigate risks that result from potential identity proofing failures.

(b) AAL: The robustness of the authentication process itself and the binding between an authenticator and a specific individual's identifier. The AAL is selected to mitigate risks that result from potential authentication failures.

(c) FAL: The robustness of the federation process used to communicate authentication and attribute information to an RP from an IdP. The FAL is selected to mitigate risks that result from potential federation failures.

Determine if the online service needs an IAL, AAL, or FAL.

Organizations SHALL develop and document a process and governance model for selecting initial assurance levels and controls based on the potential impacts of failures in the digital identity system.

Determine if the process and governance model for selecting initial assurance levels and controls has been developed based on the potential impacts of failures in the digital identity system and has been documented.

The organization SHALL document whether identity proofing is required for their application.

Determine if the question of whether identity proofing is required for the online service has been documented.

This documents the results of control AL-1.

If identity proofing is required for their application, the organization SHALL select an initial IAL for each user group based on the effective impact level determination from Sec. 3.2.4.

Determine if an initial IAL for each user group was determined and is based on the impact level determination (see CIL requirements)

Assessment is required when: the online service requires identity proofing for their user groups. See AL-1. If identity proofing is required, see CIL controls for impact levels.

The organization SHALL document whether authentication is required for their application.

Determine if the question of whether authentication is required for the online service has been documented.

This documents the results of requirement AL-1.

If authentication is required for their application, the organization SHALL select an initial AAL for each user group based on the effective impact level determination from Sec. 3.2.4.

Determine if an initial AAL for each user group was determined and is based on the impact level determination (see CIL requirements)

Assessment is required when: the online service requires authentication. See AL-1. If authentication is required, see CIL controls for impact levels.

The organization SHALL document whether federation is required for their application.

Determine if the question of whether federation is required for the online service has been documented.

This documents the results of the FAL assessment in control AL-1. Assessment is required when: the organization will use federation.

If federation is required for their application, the organization SHALL select an initial FAL for each user group based on the effective impact level determination from Sec. 3.2.4.

Determine if an initial FAL for each user group was determined and is based on the impact level determination (see CIL requirements)

Assessment is required when: the online service requires federation. See AL-1. If federation will be used, see CIL controls for impact levels.

For online services that are assessed to be high impact, organizations SHALL conduct a further assessment to evaluate the risk of a compromised IdP to determine whether FAL2 or FAL3 is more appropriate for their use case.

If the online service is "high impact," determine if further assessment has been done to evaluate the risk of a compromised IdP and if FAL2 or FAL3 is more appropriate.

Dependent on the results from controls AL-1 and IFAL-1a. Assessment is required when: the online service is assessed to be "high-impact."

Using the initial xALs selected in Sec. 3.3.3, the organization SHALL identify the applicable baseline controls for each user group for the Initial IAL and related technical and process controls from [SP800-63A].

Determine if the applicable baseline controls for the initial IAL and related technical and process controls have been identified for each user group in alignment with SP 800-63A.

See IIAL controls.

Using the initial xALs selected in Sec. 3.3.3, the organization SHALL identify the applicable baseline controls for each user group for the Initial AAL and related technical and process controls from [SP800-63B].

Determine if the applicable baseline controls for the initial AAL and related technical and process controls have been identified for each user group in alignment with SP 800-63B.

See IAAL controls.

Using the initial xALs selected in Sec. 3.3.3, the organization SHALL identify the applicable baseline controls for each user group for the Initial FAL and related technical and process controls from [SP800-63C].

Determine if the applicable baseline controls for the initial FAL and related technical and process controls have been identified for each user group in alignment with SP 800-63C.

See IFAL controls.

Within the tailoring step, organizations SHALL focus on impacts to mission delivery due to the implementation of identity management controls.

Determine if the impacts to mission delivery are used as a focus for the tailoring step.

Impacts include the possibility of legitimate users who are unable to access desired online services or experience sufficient friction or frustration with the identity system (and technology selection) that they abandon attempts to access the online service.(Ref. Sec. 3.4 A)

As a part of the tailoring process, organizations SHALL review the Digital Identity Acceptance Statements (DIAS) and practice statements from CSPs and IdPs that they use or intend to use.

Determine if the DIAS and practice statements from CSPs and IdPs have been reviewed as part of the tailoring process.

Organizations SHALL also conduct their own analysis to ensure that their specific mission and the communities being served by the online service are given due consideration for tailoring purposes.

Determine if the tailoring process includes organizations' own analysis to ensure that their mission and communities served by the online services are given due consideration.

Organizations SHALL establish and document their xAL tailoring process.

(1) Determine if the xAL tailoring process has been documented.

(2) Determine if the xAL tailoring process has been implemented.

At a minimum, [the tailoring] process SHALL follow a documented governance approach to allow for decision-making.

Determine if the tailoring process follows a documented governance approach that allows for decision-making.

At a minimum, [the tailoring] process SHALL document all decisions in the tailoring process (see Sec. 3.4.4).

Determine if the tailoring process documents all decisions made during the tailoring process.

Examples of decisions include the assessed xALs, modified xALs, and supplemental and compensating controls in the Digital Identity Acceptance Statement

At a minimum, the [tailoring] process SHALL justify and document all risk-based decisions or modifications to the initially assessed xALs in the Digital Identity Acceptance Statement (DIAS) (see Sec. 3.4.4).

Determine if the tailoring process justifies and documents all risk-based decisions or modifications to the initially selected xALs in the DIAS.

When progressing from the initial assurance level selection in [the Baseline Controls requirements] (Sec. 3.3.4) to the final xAL selection and implementation, organizations SHALL conduct detailed assessments of the controls defined for the initially selected xALs to identify potential impacts in the operational environment.

As part of the selection of the final xALs, determine if a detailed assessment of the initial xAL controls was conducted and identified potential impacts in the operational environment.

At a minimum, organizations SHALL assess the impacts and potential unintended consequences related to Privacy - Identify unintended consequences to the privacy of individuals who will be subject to the controls at an assessed xAL and of individuals affected by organizational or third-party practices related to the establishment, management, or federation of a digital identity. A privacy assessment SHOULD leverage an existing Privacy Threshold Analysis (PTA) or Privacy Impact Assessment (PIA) as inputs during the privacy assessment process.

Determine if the organization assessed the impacts and potential unintended consequences related to privacy.

As the goal of the privacy assessment is to identify privacy risks that arise from the initial assurance level selection, additional assessments and evaluations that are specific to the baseline controls for the assurance levels may be required for the underlying information system. Leveraging an existing PTA or PIA is recommended.

At a minimum, organizations SHALL assess the impacts and potential unintended consequences related to Customer Experience - Determine whether implementation of the initial assurance levels may create substantial or unacceptable barriers to individuals seeking to access services. Customer experience assessments SHALL consider impacts that result from the identity management controls to ensure that they do not cause undue burdens, frustrations, or frictions for individuals and that there are pathways to provide service to users of all capabilities, resources, technology access, and economic statuses.

Determine if the organization assessed the impacts and potential unintended consequences related to customer experience.

Determine whether implementation of the initial assurance levels may create substantial or unacceptable barriers to individuals seeking to access services.

At a minimum, organizations SHALL assess the impacts and potential unintended consequences related to Threat Resistance - Determine whether the defined assurance level and related controls will address specific threats to the online service based on the operational environment, its threat actors, and known tactics, techniques, and procedures (TTPs). Threat assessments SHALL consider specific known and potential threats, threat actors, and TTPs within the implementation environment for the identity management functions.

Determine if the organization assessed the impacts and potential unintended consequences related to threat resistance.

For example, certain benefits programs may be more subject to familial threats or collusion. Based on their assessments, organizations MAY implement supplemental controls specific to the communities served by their online service. Conversely, organizations MAY tailor their assessed xAL down or modify their baseline controls if their threat assessment indicates that a reduced threat posture is appropriate based on their environment.

All assessments applied during the tailoring phase SHALL be extended to any compensating or supplemental controls, as defined in Sec. 3.4.2 and Sec. 3.4.3.

Determine if all assessments applied during the tailoring phase were extended to any identified compensating or supplemental controls.

A compensating control is a management, operational, or technical control employed by an organization in lieu of a normative control (i.e., SHALL statements) in the defined xALs. (Ref. Sec. 3.4.2. A) The purpose of this requirement is to allow the RP to assess and determine the acceptability of the compensating controls for their use cases.(Ref. Sec. 3.4.2. C) Assessment is required when: compensating controls are implemented. Per section 3.4.2, "Organizations MAY choose to implement a compensating control if they are unable to implement a baseline control or when a risk assessment indicates that a compensating control sufficiently mitigates risk in alignment with organizational risk tolerance. This control MAY be a modification to the normative statements defined in these guidelines or MAY be applied elsewhere in an online service, digital transaction, or service life cycle."

Any cost-based decisions that result in modifications to assessed xALs or baseline controls SHALL be documented in the Digital Identity Acceptance Statement (see Sec. 3.4.4).

Determine if cost-based decisions that result in modification to assessed xALs or baseline controls are documented in the Digital Identity Acceptance Statement (DIAS).

Where compensating controls are implemented, organizations SHALL document the compensating control, the rationale for the deviation, comparability of the chosen alternative, and any resulting residual risks.

Determine if implemented compensating controls are documented, including the rationale for the deviation, comparability of the chosen alternative, and any resulting residual risks.

A compensating control is a management, operational, or technical control employed by an organization in lieu of a normative control (i.e., SHALL statements) in the defined xALs. (Ref. Sec. 3.4.2. A) The purpose of this requirement is to allow the RP to assess and determine the acceptability of the compensating controls for their use cases.(Ref. Sec. 3.4.2. C) Assessment is required when: compensating controls are implemented. Per section 3.4.2, "Organizations MAY choose to implement a compensating control if they are unable to implement a baseline control or when a risk assessment indicates that a compensating control sufficiently mitigates risk in alignment with organizational risk tolerance. This control MAY be a modification to the normative statements defined in these guidelines or MAY be applied elsewhere in an online service, digital transaction, or service life cycle."

CSPs and IdPs that implement compensating controls SHALL communicate this information to all potential RPs prior to integration.

Determine if CSPs and IdPs that implement compensating controls have communicated this information to all potential RPs prior to integration.

A compensating control is a management, operational, or technical control employed by an organization in lieu of a normative control (i.e., SHALL statements) in the defined xALs. (Ref. Sec. 3.4.2. A) The purpose of this requirement is to allow the RP to assess and determine the acceptability of the compensating controls for their use cases.(Ref. Sec. 3.4.2. C) Assessment is required when: compensating controls are implemented. Per section 3.4.2, "Organizations MAY choose to implement a compensating control if they are unable to implement a baseline control or when a risk assessment indicates that a compensating control sufficiently mitigates risk in alignment with organizational risk tolerance. This control MAY be a modification to the normative statements defined in these guidelines or MAY be applied elsewhere in an online service, digital transaction, or service life cycle."

Any supplemental controls SHALL be assessed for impacts based on the same factors used to tailor the organization's assurance level.

Determine if supplemental controls are assessed for impacts based on the same factors used to tailor the organization's assurance level.

Assessment is required when: supplemental controls are identified and implemented.

Any supplemental controls SHALL be documented.

Determine if supplemental controls are documented.

Assessment is required when: supplemental controls are identified and implemented.

Organizations SHALL develop a Digital Identity Acceptance Statement (DIAS) to document the results of the DIRM process for each online service managed by the organization.

Determine if a DIAS was developed that documents the results of the DIRM process for each online service managed by the organization.

See DIRM-1.

Organizations SHALL develop a Digital Identity Acceptance Statement (DIAS) to document the results of the DIRM process for each external online service used to support the mission of the organization.

Determine if a DIAS was developed that documents the results of the DIRM process for each external online service used to support the mission of the organization.

External online services include software-as-a-service offerings (e.g., social media platforms, email services, online marketing services). (Ref. Sec. 3.4.4.A) See DIRM-1

RPs who intend to use a particular CSP/IdP SHALL review the latter's DIAS and incorporate relevant information into the organization's DIAS for each online service.

Determine if the RP reviewed the CSP/IdP's DIAS and incorporated relevant information into the RP's DIAS for each online service.

Assessment is required when: the CSP/IdP used by the RP has created a DIAS.

Organizations SHALL prepare a DIAS for their online service that includes, at a minimum:

(a) Initial impact assessment results; initially assessed xALs.

(b) Tailored xALs and rationale if the tailored xALs differs from the initially assessed xALs.

(c) All compensating controls with their comparability or residual risks.

(d) All supplemental controls.

Determine if the organization's online service DIAS includes, at a minimum, initial impact assessment results, initially assessed xALs, tailored xALs and rationale if the tailored xALs differs from the initially assessed xALs, all compensating controls with their comparability or residual risks, and all supplemental controls.

Assessment is required for a CS{/IdP when: the CSP/IdP deviates from normative guidance and creates a DIAS.

CSPs/IdPs SHALL implement the DIRM process and develop a DIAS for the services they offer if they deviate from the normative guidance in these guidelines, including when supplemental or compensating controls are added.

For CSP/IdPs that deviate from normative guidance, determine if the CSP/IdP has implemented the DIRM process and developed a DIAS for the services they offer.

Assessment is required when: the CSP/IdP deviates from normative guidance, including when supplemental or compensating controls are added. To complete a DIRM of their offered assurance levels and controls, CSPs/IdPs MAY base their assessment on anticipated or representative digital identity services that they wish to support.

The DIAS prepared by a CSP SHALL include, at a minimum:

(a) Claimed xAL, related controls, and rationale for any deviations from normative guidance;

(b) All compensating controls with their comparability or residual risks; and

(c) All supplemental controls.

Determine if the CSP's DIAS includes the claimed xAL, related controls, and rationale for any deviations from normative guidance, all compensating controls with their comparability or residual risks, and all supplemental controls.

Assessment is required when: the CSP/IdP has created a DIAS (see DIAS-4).

The DIRM process for external online services used by the organization SHALL consider relevant inputs from the provider of the service and document the results in a DIAS.

Determine if the DIRM process for external online services includes the results of inputs from the provider of the service are documented in a DIAS.

CSP's trying to meet this requirement should coordinate with the RP for the documentation.

The DIAS prepared by the organization for external online services SHALL include, at a minimum:

(a) Assessed xAL, related controls, and rationale for any deviations from normative guidance;

(b) All compensating controls with their comparability or residual risks; and

(c) All supplemental controls.

Determine if the DIAS for external online services includes assessed xALs, related controls, and rationale for any deviations from normative guidance, all compensating controls with their comparability or residual risks, and all supplemental controls.

Assessment is required when: the CSP/IdP created a DIAS (see DIAS-4)

Organizations SHALL implement a continuous evaluation and improvement program that leverages input from end users who have interacted with the identity management system as well as performance metrics for the online service.

Determine if the organization has implemented a continuous evaluation and improvement program that leverages input from end users who have interacted with the identity management system and performance metrics for the online service.

The purpose of this control is to address the shifting environment in which they operate and more rapidly address service capability gaps.

This program SHALL be documented, including the metrics that are collected, the sources of data required to enable performance evaluation, and the processes in place for taking timely actions based on the continuous improvement process.

Determine if the documentation includes:

(a) the metrics that are collected,

(b) the sources of data required to enable performance evaluation, and

(c) the processes in place for taking timely actions based on the continuous improvement process.

Organizations SHALL monitor the evolving threat landscape.

Determine if the organization is monitoring the evolving threat landscape.

The purpose of monitoring the evolving threat landscape is to stay informed of the latest threats and fraud tactics.

Organizations SHALL regularly assess the effectiveness of current security measures and fraud detection capabilities against the latest threats and fraud tactics.

Determine if the organization regularly assesses the effectiveness of current security measures and fraud detection capabilities against the latest threats and fraud tactics.

At a minimum, evaluation inputs SHALL include:

(a) Integrated CSP, IdP, and authentication functions as well as validation, verification, and fraud management systems, as appropriate;

(b) Customer feedback mechanisms, such as complaint processes, helpdesk statistics, and other user feedback (e.g., surveys, interviews, or focus groups);

(c) Threat analysis, threat reporting, and threat intelligence feeds that are available;

(d) Fraud trends, fraud investigation results, and fraud metrics as available; and

(e) The results of ongoing customer experience assessments and privacy assessments.

Determine if the evaluation inputs include:

(a) Integrated CSP, IdP, and authentication functions as well as validation, verification, and fraud management systems, as appropriate;

(b) Customer feedback mechanisms, such as complaint processes, helpdesk statistics, and other user feedback (e.g., surveys, interviews, or focus groups); (c)Threat analysis, threat reporting, and threat intelligence feeds that are available;

(d) Fraud trends, fraud investigation results, and fraud metrics as available; and

(e) The results of ongoing customer experience assessments and privacy assessments.

The purpose of control EI-1 is to fully understand the performance of their identity system, organizations will need to identify critical inputs to their continuous evaluation process.

RPs SHALL document their metrics, reporting requirements, and data inputs for any CSP, IdP, or other integrated identity service to ensure that expectations are appropriately communicated to partners and vendors.

Determine if the RP has documented their metrics, reporting requirements, and data inputs for any CSP, IdP, or other integrated identity service.

The documentation of metrics, reporting requirements, and data inputs for any CSP, IdP, or other integrated identity service is to ensure that expectations are appropriately communicated to partners and vendors.

RPs and CSPs SHALL enable individuals to convey grievances and seek redress through an issue handling process that is documented, accessible, trackable, and usable by all individuals and whose instructions are easy to find on a public-facing website.

(1) Determine if the RPs and CSPs issues handline process is:

(a) Documented,

(b) Accessible,

(c) Trackable,

(e) Usable by all individuals, and has instructions on an easy-to-find, public-facing website.

RPs and CSPs SHALL institute a governance model for implementing this issue handling process, including documented roles and responsibilities.

Determine if the RPs and CSPs instituted a governance model for implementing the issue handling process that includes documented roles and responsibilities.

The issue handling process SHALL be implemented as a dedicated function that includes procedures for impartially reviewing pertinent evidence.

Determine if the issue handling process is implemented as a dedicated function with procedures for impartially reviewing pertinent evidence.

The issue handling process SHALL be implemented as a dedicated function that includes procedures for requesting and collecting additional evidence that informs the issues.

Determine if the issue handling process is implemented as a dedicated function with procedures for requesting and collecting additional evidence that informs the issues.

The issue handling process SHALL be implemented as a dedicated function that includes procedures for expeditiously resolving issues and determining corrective action.

Determine if the issue handling process is implemented as a dedicated function with procedures for expeditiously resolving issues and determining corrective action.

RPs and CSPs SHALL make human support personnel available to intervene and override issue adjudication outputs generated by algorithmic support mechanisms.

Determine if RPs and CSPs have made human support personnel available to intervene and override issue adjudication outputs generated by algorithmic support mechanisms.

RPs and CSPs SHALL educate support personnel on issue handling procedures for the digital identity management system.

Determine if RPs and CSPs have educated support personnel on issue handling procedures for the digital identity management system.

RPs and CSPs SHALL educate support personnel on the avenues for redress.

Determine if RPs and CSPs have educated support personnel on the avenues for redress.

RPs and CSPs SHALL educate support personnel on the alternatives available to gain access to services.

Determine if RPs and CSPs have educated support personnel on the alternatives available to gain access to services.

RPs and CSPs SHALL implement a process for personnel and technologies that provides support functions to report and address major barriers that end users face and grievances they may have.

Determine if the RP/CSP has implemented a process for personnel and technologies that provides support functions to report and address major barriers that end users face and grievances they may have.

RPs and CSPs SHALL incorporate findings derived from the issue handling process into continuous evaluation and improvement activities.

Determine if the RP/CSP has incorporated findings derived from the issue handling process into continuous evaluation and improvement activities.

Organizations SHALL assess the integrity and performance of their redress mechanisms.

Determine if the integrity and performance of their redress mechanisms are being assessed.

Organizations SHALL implement controls to prevent, detect, and remediate attempted identity fraud involving those mechanisms.

Determine if controls to prevent, detect, and remediate attempted identity fraud involving the redress mechanisms have been implemented.

Organizations SHALL establish consistent mechanisms for the exchange of information between stakeholders that are responsible for critical internal security and fraud prevention.

Determine if consistent mechanisms for the exchange of information between stakeholders that are responsible for critical internal security and fraud prevention have been established.

All data collected, transmitted, or shared by the identity service provider SHALL be subject to a detailed privacy and legal assessment by either the entity generating the data (e.g., a CSP) or the related RP for whom the service is provided.

Determine if all data collected, transmitted, or shared by the identity service provider is subject to a detailed privacy and legal assessment.

The privacy and legal assessment can be done by either the entity generating the data (e.g., a CSP) or the related RP for whom the service is provided.

All uses of AI/ML [in the identity system] SHALL be documented.

Determine if all uses of AI/ML in the identity system have been documented.

All uses of AI/ML [in the identity system] SHALL be communicated to organizations that rely on these systems.

Determine if all uses of AI/ML in the identity system have been communicated to organizations that rely on these systems.

The use of integrated technologies that leverage AI/ML by CSPs, IdPs, or verifiers SHALL be disclosed to all RPs that make access decisions based on information from these systems.

Determine if the use of integrated technologies that leverage AI/ML is disclosed to all RPs that make access decisions based on information from these systems.

All organizations that use AI/ML SHALL provide information to any entities that use their technology [including] the methods and techniques used for training their models.

Determine if methods and techniques used for training AI/ML models have been provided to the entities using the AI/ML technology.

All organizations that use AI/ML SHALL provide information to any entities that use their technology [including] a description of the data sets used in training.

Determine if a description of the data sets used in training the AI/ML models have been provided to the entities using the AI/ML technology.

All organizations that use AI/ML SHALL provide information to any entities that use their technology [including] the frequency of model updates.

Determine if the frequency of AI/ML model updates have been provided to the entities using the AI/ML technology.

All organizations that use AI/ML SHALL provide information to any entities that use their technology [including] the results of all testing completed on their algorithms.

Determine if the results of all testing completed on their AI/ML algorithms have been provided to the entities using the AI/ML technology.

CSPs SHALL evaluate the risks associated with each identity proofing option offered (e.g., identity proofing types, validation sources, assistance mechanisms) and implement mitigating fraud controls, as appropriate.

Confirm that the CSP has assessed the risks associated with each identity proofing option offered and that they have employed appropriate mitigations to address those risks.

CSPs are likely to provide different options for how applicants can complete the identity proofing process. This control ensures a risk assessment process is in place to evaluate these options and identify and address unique risks. It can be done as part of the DIRM process defined in NIST SP 800-63-4 or an organizational specific risk management process.

At a minimum, CSPs SHALL design each option such that the options provide comparable assurance in aggregate.

Confirm that the CSP has designed its identity services so that no identity proofing pathway (sequence of actions) results in a lower level of assurance than another.

CSPs SHALL identify which roles are applicable to their identity service.

Confirm that the CSP has identified the roles that are employed as part of its identity proofing service.

Identity proofing roles are proofing agent, trusted referee, applicant reference, and process assistant.

CSPs SHALL provide training and support resources consistent with the requirements and expectations provided in Sec. 3.

Confirm that individuals with defined identity proofing roles are properly trained and provided with the resources they need to be effective in performing their identity proofing roles.

CSPs SHALL include a government identifier as a part of its core attributes.

Determine that CSPs require the collection of a government identifier.

A government identifier is a unique identifier that is associated with the applicant in government records (e.g., Social Security number, driver's license number, passport number).

The CSP and RP SHALL document all core attributes in trust agreements and practice statements.

Confirm that agreements between CSPs and RPs include the CSP's set of core attributes so that an RP can make risk-based decisions about using a CSP's identity service.

To be considered FAIR, identity evidence SHALL meet all the requirements in Sec. 2.4.1.1.

Confirm that the CSP has documented the types of FAIR evidence it considers acceptable and provided justifications for each based on defined requirements.

To be considered STRONG, identity evidence SHALL meet all the requirements in Sec. 2.4.1.2.

Determine that the CSP has documented the types of STRONG evidence it considers acceptable and provided justifications for each based on defined requirements.

To be considered SUPERIOR, identity evidence SHALL meet all the requirements in Sec. 2.4.1.3.

Determine that the CSP has documented the types of SUPERIOR evidence it considers acceptable and provided justifications for each based on defined requirements.

The CSP SHALL validate the authenticity, accuracy, and validity of presented evidence by confirming that: the evidence is in the correct format and includes complete information for the identity evidence type; the evidence does not show signs of being counterfeit or tampered with; the evidence contains physical or digital security features; and the core attributes and data fields necessary to determine authenticity on the evidence are accurate.

Determine that the CSP validates all collected evidence according to a systematic and repeatable process that ensures its authenticity, accuracy, and validity.

The CSP SHALL validate all core attributes, whether obtained from identity evidence or self-asserted by the applicant, with an authoritative or credible source.

All core attributes are validated against authoritative or credible sources to confirm they are accurate.

The CSP SHALL use authoritative or credible sources that meet [the criteria provided in Sec. 2.4.2.4].

CSPs use appropriate sources to validate core attributes and identity evidence.

An authoritative source is the issuing source of identity evidence or attributes or has direct access to the information maintained by issuing sources. A credible source has access to attribute information that can be traced to an authoritative source or maintains identity attribute information obtained from multiple sources that is correlated for accuracy, consistency, and currency.

The CSP SHALL verify the linkage between the claimed identity to the applicant engaged in the identity proofing process through one or more of the [methods provided in Sec. 2.5.1].

CSPs employ proven methods to perform identity verification.

Acceptable identity verification methods include, Confirmation code verification, Authentication and federation protocols, Transaction verification, Visual facial image comparison for on-site attended, and Visual facial image comparison for remote attended or remote unattended. Additional requirements on acceptable methods are addressed per assurance level.

Knowledge-based verification (KBV) or knowledge-based authentication SHALL NOT be used for identity verification.

Confirm that the CSP does not employ KBV or KBA as part of its identity verification process.

Because KBV can be easily subverted, it is not a suitable method for identity verification. However, CSPs may employ KBV as part of fraud management processes. Note that applicants may provide self-asserted attributes during the identity proofing process. Provided the CSP validates these self-asserted attributes with an authoritative or credible source, they may be used by the CSP as core attributes for identity resolution and communication with RPs. However, the CSP may not use the applicant's knowledge of these attributes as evidence the applicant is who they claim to be.

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.

Confirm that the CSP has documented its procedures to achieve the defined IALs.

The CSP's documented procedures SHALL include a complete service description including the particular steps that it follows to identity-proof applicants at each offered assurance level.

Confirm that the CSP has documented the particular steps it employs to identity proof applicants at each offered assurance level.

Documentation of the complete service description allows CSPs to communicate to RPs and others the scope and components of their services and how they achieve specific IALs.

The CSP's documented procedures SHALL include its 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, and the purposes for collecting, using, and retaining biometrics.

Confirm that the CSP has documented its procedures for providing notice to applicants, as specified in item #2 of Sec. 3.1.

Notice is essential to promoting informed decision-making while conducting identity proofing processes. Since CSPs collect sensitive information, documented set of policies supports informed consent from applicants before engaging with the service.

The CSP's documented procedures SHALL include its policy for ensuring that the identity proofing process concludes in a timely manner once the applicant has met all of the requirements.

Confirm that the CSP has a documented policy for ensuring the identity proofing process concludes in a timely manner.

Lack of timeliness results in the degradation of mission delivery as it affects the ability of the organization to perform mission functions and increases burden on applicants seeking services. Providing policies for the timely completion of identity proofing services sets expectations for RPs and enables communication to applicants about the anticipated timing of the process.

The CSP's documented procedures SHALL include the types of evidence that it accepts and the justification for how the evidence fulfills the strength requirements of the level at which it will be accepted by the CSP.

Confirm that the CSP has documented the types of evidence it accepts and the justification for how the evidence fulfills the strength requirements of the specified IAL.

The policy for identity evidence collection and classification of evidence acceptance allows open communication between the CSP and the RP, which can then be communicated to the applicant to build trust between the applicant and RP as the identity evidence collection is a sensitive process.

The CSP's documented procedures SHALL include its policy and process for validating and verifying identity evidence, including training and qualification requirements for personnel who serve in identity proofing roles.

Confirm that the CSP has documented its policy and process for validating and verifying evidence, including any training and qualification requirements for proofing agents.

The CSP documenting policy and process for validating and verifying identity evidence offers knowledge for the RP that may be employed for communication to the applicant.

The CSP's documented procedures SHALL include the specific technologies that the CSP employs for evidence validation and verification.

Confirm that the CSP documents the technologies it uses for evidence validation and verification.

Documenting the details of specific technologies that the CSP uses opens the doors for the RP to determine if they are adequate for them as well as communicating to the end-user what technology and services will have access to their identity evidence.

The CSP's documented procedures SHALL include its policy and processes for supporting applicants who lack sufficient identity evidence for the required IAL and for addressing identity proofing exceptions and errors.

Confirm that the CSP has documented procedures for exception handling and identity proofing errors, including for the identity proofing of applicants who lack the required identity evidence.

The CSPs outlining support mechanisms for applicants that lack evidence or have exceptions or errors allow the RPs to serve the end-user while ensuring that the identity is valid and informs them of what is required of them.

The CSP's documented procedures SHALL include the attributes that it considers to be core attributes and the authoritative and credible sources it uses for validating those attributes.

Confirm that the CSP has documented the attributes it considers to be core attributes and the validation sources it uses to validate those attributes.

The CSPs outlining support mechanisms for applicants that lack evidence or have exceptions or errors allow the RPs to serve the end-user while ensuring that the identity is valid and informs them of what is required of them.

The CSP's documented procedures SHALL include the CSP's policy for managing and communicating service changes to RPs, such as changes in data sources, integrated vendors, or biometric algorithms.

Confirm that the CSP has documented policies for managing and communicating service changes to the RPs that use its service.

The CSPs outlining support mechanisms for applicants that lack evidence or have exceptions or errors allows the RPs to serve the end-user while ensuring that the identity is valid and informing them of what is required of them.

The CSP's documented procedures SHALL include its approach to fraud management, including its policy and process for identifying and remediating suspected or confirmed fraudulent accounts and communicating such information to RPs and affected individuals.

Confirm the CSP has documented its fraud management procedures, including its policy and process for identifying and remediating suspected or confirmed fraudulent accounts and communicating such information to RPs and affected individuals.

CSP documentation of the fraud management approach allows the RP to be informed on the status of its end users and policies that determine the state of its users' accounts, as well as allowing them to be informed and communicative of any effects that the fraud management process has on the end users' account.

The CSP's documented procedures SHALL include its policy for any conditions that would require reverification of the user.

Confirm that the CSP has documented policies on any conditions that require the reverification of the subscriber already enrolled in its identity service.

Examples of reverification include account recovery, account abandonment, and regulatory "recertification" requirements. Documentation of this allows RPs to inform end-users of these processes, the status of the accounts, what triggers them, and enables the RP to communicate any changes desired to the CSP.

The CSP's documented procedures SHALL include its policy for conducting privacy risk assessments, including the timing of its periodic reviews and specific conditions that will trigger an updated privacy risk assessment.

Confirm the CSP has documented its policy for conducting risk assessments, including the timing of its periodic reviews and specific conditions that will trigger an updated privacy risk assessment.

Communicating this policy ensures that the RPs are aware of the privacy risks that could affect end-users, potentially communicate to them those results, and allows the RPs and CSP to work together on changes based on the results.

The CSP's documented procedures SHALL include its policy for assessing customer experience, including the testing methods employed, timing of its periodic reviews, and any specific conditions that will trigger an out-of-cycle review.

Confirm the CSP has a documented policy for assessing customer experience, including the testing methods employed, timing of its periodic reviews, and any specific conditions that will trigger an out-of-cycle review.

These procedures and the results of them can be used by the RP to determine if any changes need to be made to promote continuous improvement and address concerns, which ultimately improves the end-user experience.

The CSP's documented procedures SHALL include its policy for the retention, protection, and deletion of all personal, sensitive, and biometric data, including the treatment of all such data if the CSP ceases operation or merges or transfers operations to another CSP.

Confirm the CSP has documented policies for the retention, protection, and deletion of all personal, sensitive, and biometric data, including the treatment of all such data if the CSP ceases operation or merges or transfers operations to another CSP.

The CSP's documented procedures SHALL include its policy for reporting and updating performance metrics.

Confirm that the CSP has documented policies for reporting and updating performance metrics.

Meeting performance metrics starts with standardizing how it is reported and updated, as it is critical to RPs in being able to provide an adequate system and interface to the end-user, and communicate any changes as a result.

The CSP's documented procedures SHALL include its policy for accessing or removing a subscriber's account in the event of their death or incapacitation.

Confirm that the CSP has documented policies for the access or removal of a subscriber's account in the event of their death or incapacitation.

CSPs SHALL make their documented procedures or practice statements available to RPs that use their identity service.

Confirm that the CSP makes its practices statement or other documentation available to the RPs that use its services.

CSPs maintaining the transparency and availability of their statements and procedures creates a proactive environment between CSPs and RPs where the end-users are served.

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.

Determine that CSPs proactively manage risks associated with fraud.

A critical aspect of the identity proofing process is to mitigate fraudulent attempts to gain access to benefits, services, data, or assets that are protected by identity management systems. Resolution, validation, and verification processes are designed to mitigate many types of attacks. However, with the constantly changing threat environment, layering additional checks and controls can provide increased confidence in proofing identities and additional protections against advanced and emerging types of attacks. The ability to identify, detect, and resolve instances of potential fraud is a critical functionality for CSPs and RPs.

CSPs SHALL conduct a privacy risk assessment of all fraud checks and fraud mitigation technologies prior to implementation.

Determine that the CSP assesses the privacy risks associated with employing fraud management mechanisms.

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.

Confirm that the CSP provides a mechanism for users to self-report if they believe they have been a victim of fraud or an attempt to compromise their involvement in the identity proofing process.

CSPs SHALL analyze all remote proofing communication channels to look for high-risk indicators (e.g., blocklisted proxies and IP addresses).

Confirm that the CSP monitors ID proofing communication channels for indicators of fraud or attacks.

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.

Determine the measures a CSP takes to prevent attackers from determining the accuracy of self-asserted information that has been compared to authoritative or credible sources as part of the validation step.

This is often called "data washing" and typically occurs when an attacker manipulates or cleans up stolen attribute information to make it appear legitimate by removing inconsistencies or red flags that might trigger fraud detection systems. Data washing can be prevented through a number of methods, depending on the interfaces deployed by a CSP. As such, these guidelines do not dictate specific mechanisms to prevent this practice.

CSPs SHALL monitor the performance of their fraud checks and fraud mitigation technologies to ensure continued effectiveness in mitigating fraud risks.

Determine that the CSP monitors the effectiveness of their fraud mitigation measures in addressing new and changing types of fraud and attacks.

CSPs SHALL establish a technical or process-based mechanism to communicate suspected and confirmed fraudulent events to RPs.

Determine that the CSP has a process for communicating incidents of suspected or confirmed fraud to its 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.

Determine that the CSP checks against a death record repository to confirm that an applicant is not claiming to be someone who has died.

Death records are typically maintained by state and local vital records offices. The Social Security Administration (SSA) also collects and manages death information for its programs, but it does not hold comprehensive records of all deaths in the country. Checking against these repositories can aid in preventing synthetic identity fraud, the use of stolen identity information, and exploitation by a close associate or relative.

For attended proofing processes, CSPs SHALL train proofing agents to detect indicators of fraud and SHALL provide proofing agents and trusted referees with tools to flag suspected fraudulent events for further treatment and investigation.

[If a CSP provides an attended identity proofing process,] confirm that its agents are trained to detect potential fraud and are provided with mechanisms to flag incidents of suspected fraud.

CSPs SHALL implement insider threat controls to detect and prevent collusion involving CSP representatives that are directly involved with or can intervene in proofing processes or decisions.

Determine that the CSP has implemented appropriate insider threat controls to help detect and prevent collusion.

Collusion is possible whenever CSP representatives are directly involved in proofing processes or decisions.

If fraud mitigation measures are employed as compensating controls, they SHALL be documented as deviations from the normative guidance of these guidelines and SHALL be conveyed to all RPs through a Digital Identity Acceptance Statement (DIAS) prior to integration.

Determine if a CSP employs fraud mitigation measures as compensating controls, and if it does, determine that the CSP has documented these controls as deviations from the normative guidance of these guidelines and conveys this information to its RPs through a Digital Identity Acceptance Statement (DIAS).

See SP 800-63-4, section 3.4.4, for more information about DIAS.

CSPs that employ artificial intelligence (AI) or machine learning (ML) as part of their identity service SHALL adhere to the requirements provided in Sec. 3.8 of [SP800-63], as applicable.

Determine if the CSP employs AI or ML as part of its identity service and if it does, confirm that it adheres to all the requirements provided in Section 8 of NIST SP 800-63-4.

RPs SHALL establish a point of contact with whom CSPs can interact and communicate fraud data.

Confirm the RP has established a point of contact to receive fraud and other information from its CSPs.

RPs SHALL conduct a privacy risk assessment (see Sec. 3.3.1) of any CSP fraud checks and mitigation technologies to identify potential privacy risks or unintended harms.

Determine that the RP has conducted a privacy risk assessment of all fraud checks or mitigations used by CSPs.

Federal agency RPs SHALL implement the privacy risk assessment consistent with the requirements contained in Sec. 3.7.

Determine that the Federal agency RP has conducted a privacy risk assessment for all fraud checks and mitigations used by its CSPs in accordance with the requirements provided in section 3.7 of SP 800-63A-4.

RPs SHALL conduct periodic reviews of their CSP's fraud management program, fraud checks, and fraud technologies to adjust thresholds, review investigations into fraud events, and evaluate the effectiveness and efficacy of fraud controls.

Confirm the RP conducts periodic re-reviews of its fraud management program activities to ensure its ongoing effectiveness against existing and emerging risks and threats.

RPs SHALL review all fraud mitigation measures that have been deployed as compensating or supplemental controls by CSPs to align with their internal risk tolerance and acceptance.

Determine that the RP has reviewed and accepted all risks associated with fraud mitigation measures employed by its CSP as compensating controls and confirmed they align with the RP's own risk acceptance profile.

The RP SHALL record the CSP's compensating controls in their own DIAS prior to integration.

Determine if the CSP employs any compensating controls and, if so, determine that the RP as included the controls from the CSP's DIAS into its own DIAS.

From NIST SP 800-63-4: Organizations SHALL develop a Digital Identity Acceptance Statement (DIAS) to document the results of the DIRM process for (i) each online service managed by the organization, and (ii) each external online service used to support the mission of the organization, including software-as-a-service offerings (e.g., social media platforms, email services, online marketing services). RPs who intend to use a particular CSP/IdP SHALL review the latter's DIAS and incorporate relevant information into the organization's DIAS for each online service.

CSPs SHALL establish and document actions and practices related to each of their fraud checks and provide these actions and practices to RPs.

Confirm that the CSP has established and documented actions and practices associated with its fraud checks, and that it communicates this information to its RPs.

CSPs SHALL establish procedures for redress to allow applicants to resolve issues associated with fraud checks and mitigation technologies.

Determine that the CSP has established redress procedures specific to issues associated with its fraud checks and mitigation measures.

See Sec. 3.6 of [SP800-63] for more information about redress.

If trusted referees are offered to applicants who fail fraud checks in unattended remote processes, the trusted referees SHALL be provided with a summary of the results of the fraud failures to inform their risk-based decision-making processes.

Determine if the CSP offers Trusted Referee services to applicants who fail fraud checks and, if it does, confirm that these Trusted Referees are provided with the results of the fraud checks.

The CSP SHOULD offer trusted referee services to applicants who fail fraud checks in unattended remote processes.

The CSP SHALL conduct and document a privacy risk assessment for the processes used for identity proofing and enrollment.

Determine that the CSP has conducted a privacy risk assessment of its identity service processes.

For more information about privacy risk assessments, refer to the NIST Privacy Framework: A Tool for Improving Privacy through Enterprise Risk Management at https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.01162020.pdf.

At a minimum, the privacy risk assessment SHALL assess the risks associated with:

(a) Processing personal information for the purposes of identity proofing, enrollment, or fraud management, including identity attributes, biometrics, images, video, scans, or copies of identity evidence.

(b) Additional steps that the CSP takes to verify the identity of an applicant beyond the mandatory requirements specified herein.

(c) Processing of personal information for purposes outside of the scope of identity proofing and enrollment, except to comply with law or legal processes.

(d) The retention schedule for identity records and personal information.

(e) Processing non-personal information that could be used to identify a person when aggregated or processed by an algorithm.

(f) Personal information that is processed by a third-party service on behalf of the CSP.

Determine that the CSP has assessed the privacy risks associated with all the aspects of its identity service, as specified in item #1 of section 3.3.1.

Based on the results of its privacy risk assessment, the CSP SHALL document the measures it takes to maintain the disassociability, predictability, manageability, confidentiality, integrity, and availability of any personal information it collects or processes.

Determine that the CSP has documented the measures it takes to manage its privacy risks, as identified by the CSP's privacy risk assessment.

NIST IR 8062 provides an overview of predictability, manageability, and disassociability, including examples of how these objectives can be met.

The CSP SHALL reassess privacy risks and update its privacy risk assessment any time it makes changes to its identity service that affect the processing of personal information.

Determine that the CSP has a policy and/or procedure for reassessing its associated privacy risks anytime changes to its identity service affect the processing of personal information.

The CSP SHALL review its privacy risk assessment periodically, as documented in its practice statement, to ensure that it accurately reflects the current risks associated with the collection and processing of personal information.

Determine that the CSP reviews its privacy risk assessment process and/or results to ensure that it accurately reflects the current privacy risks associated with operating its identity service.

The CSP SHALL make a summary of its privacy risk assessment available to any RPs that use its services. The summary SHALL be in sufficient detail to enable such RPs to make reasonable determinations about privacy risks associated with the CSP's services and to complete their own privacy risk assessments.

Determine that the CSP has a process for communicating summarized results of its privacy risk assessment to its RPs and that such summaries are in sufficient detail to allow those RPs to determine if the risks of using the CSP's identity services are acceptable.

The CSP SHALL perform a privacy risk assessment for the processing of any personal information maintained in subscriber accounts.

Determine that the CSP performed a privacy risk assessment of its subscriber accounts.

The processing of personal information SHALL be limited to the minimum necessary to validate the existence of the claimed identity, associate the claimed identity with the applicant, mitigate fraud, and provide RPs with attributes that they may use to make authorization decisions.

Determine that the CSP applies the privacy-protecting principle of data minimization.

The CSP SHALL provide privacy training to all personnel and any third-party service providers who have access to sensitive information associated with the CSP's identity service.

Determine that the CSP provides privacy training to all its personnel and to those third-party service providers who have access to any personal or sensitive information associated with the CSP's identity service operations.

[If the SSN is collected on behalf of a federal, state, or local government agency,] the CSP SHALL provide notice to the applicant for the collection in accordance with applicable laws.

Determine if the CSP collects SSNs, and if it does, confirm that it provides notice to the applicant for the collection.

The CSP MAY collect a Social Security number (SSN) as an attribute when necessary for identity resolution. Knowledge of an SSN is not sufficient to act as evidence of identity, nor is it considered an acceptable method of verifying possession of the Social Security card when used as evidence.

At the time of collection, the CSP SHALL provide explicit notice to the applicant regarding the purpose for collecting any attributes and personal information. Such a notice SHALL include whether the personal information and attributes are voluntary or mandatory to complete the identity proofing process; the specific attributes and other sensitive data that the CSP intends to store in the applicant's subsequent subscriber account; the consequences of not providing the attributes; and the details of any records retention requirement if one is in place, including an applicant's right to request data deletion or engage in other forms of redress.

Determine that the CSP provides explicit notice to the applicant for the collection of attributes and personal information and that such notice includes all the elements provided in item #4 of section 3.3.2.

The CSP SHALL assess the elements of its identity proofing processes to identify processes or technologies that can result in customer experience challenges, particularly if those challenges prevent the CSP from consistently delivering identity proofing services to all users served by an RP.

Determine that the CSP has assessed its identity proofing process and identified any potential customer experience challenges.

CSPs assess the elements of their identity services to identify processes and technologies that may result in customer experience challenges for the populations they serve. If risks to customer experience are identified, CSPs proactively employ mitigations that will reduce or eliminate these issues consistent with their assurance levels and risk posture.

CSPs SHALL provide RPs with a summary of their customer experience assessments that includes information about common challenges or issues faced by users.

Determine that the CSP has a process for communicating the results of its customer experience assessments to the RPs that use its service.

Based on the results of its assessment, the CSP SHALL document any measures it takes to mitigate the possible access challenges.

Determine that the CSP has documented any measures it takes to mitigate the potential customer experience challenges it identified through its customer experience assessment.

The CSP SHALL reassess the customer experience risks periodically and any time the CSP makes changes to its identity service that affect the processes or technologies that impact customer experience.

Determine that the CSP periodically reassesses its customer experience risks (challenges) and any time it makes changes to its identity service that could impact the customer experience.

The CSP SHALL NOT make applicant participation in these risk assessments mandatory.

Confirm that the CSP does not make applicant participation in customer experience risk assessments mandatory.

Each online transaction within the identity proofing process, including transactions that involve third parties, SHALL occur over an authenticated, protected channel.

Determine that all communications are protected by approved cryptography.

An authenticated protected channel is an encrypted communication channel that uses approved cryptography in which the connection initiator (client) has authenticated the recipient (server). Authenticated protected channels are encrypted to provide confidentiality and protection against active intermediaries and are frequently used in the user authentication process. Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) [RFC9325] are examples of authenticated protected channels in which the certificate presented by the recipient is verified by the initiator. Unless otherwise specified, authenticated protected channels do not require the server to authenticate the client. Authentication of the server is often accomplished through a certificate chain that leads to a trusted root rather than individually with each server.

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.

Confirm that the CSP has identified which automated attacks its identity service is vulnerable to and has implemented appropriate attack detection mechanisms.

Behavioral analytics in this context is used to determine whether an interaction is indicative of an automated attack and not an effort to identify or authenticate a specific user based on a captured reference template for that user.

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.

Determine that the CSP protects all identity service data.

The CSP SHALL assess the information security and privacy risks associated with operating its identity service, according to the NIST Risk Management Framework or equivalent risk management guidelines. At a minimum, the CSP SHALL apply appropriate controls consistent with the NIST SP 800-53 moderate baseline, regardless of IAL.

Determine that the CSP has conducted a risk assessment and that it employs appropriate security controls consistent with the NIST SP 800-53 MODERATE baseline or greater.

The CSP SHALL assess risks associated with its use of third-party services and apply appropriate controls, as provided in the Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations.

Determine that the CSP has assessed the risks associated with its user of third-party services and has applied appropriate controls.

The CSP SHALL provide mechanisms for the redress of applicant complaints and problems that arise from the identity proofing process, including proofing failures; delays; difficulties; and the recovery of a compromised subscriber account (e.g., as a result of a scam or fraud).

Determine that the CSP provides a mechanism for applicants to seek redress for errors or harms associated with their use of the CSP's identity service.

See section 3.6 of NIST SP 800-63-4 for more information about redress.

These redress mechanisms SHALL be easy for applicants to find and use.

Determine that the CSP's redress mechanisms are easy to find and use.

The CSP SHALL assess the mechanisms for their efficacy in achieving a resolution of complaints or problems.

Determine that the CSP assesses its redress process and mechanisms to confirm they are effective.

The agency SHALL consult with their Senior Agency Official for Privacy (SAOP) to determine whether the collection of personal information, including biometrics, to conduct identity proofing triggers Privacy Act requirements.

Confirm that the Federal Agency has consulted with its SAOP to determine if the collection of personal information in association with the use of the identity service triggers Privacy Act requirements.

The agency SHALL consult with their SAOP to determine whether the collection of personal information, including biometrics, to conduct identity proofing triggers E-Government Act of 2002 requirements.

Confirm that the Federal Agency has consulted with its SAOP to determine if the collection of personal information in association with the use of the identity service triggers E-Government Act of 2002 requirements.

The agency SHALL publish a System of Records Notice (SORN) to cover such collections, as applicable.

Determine that the Federal Agency has published a SORN, as applicable, for its use of an identity service.

For more information about SORNs, see OPM's System of Records Notice (SORN) Guide(https://www.opm.gov/information-management/privacy-policy/privacy-references/sornguide.pdf).

The agency SHALL publish a Privacy Impact Assessment (PIA) to cover such collections, as applicable.

Determine that the Federal Agency has conducted a PIA for its identity service.

If the agency uses a third-party CSP, the agency SHALL conduct its own PIA and use the CSP's privacy risk assessment as input.

Determine if the Federal Agency uses a third-party CSP and, if it does, confirm it has conducted a PIA and included the CSP's PIA as an input.

Confirmation codes SHALL include at least 6 decimal digits (or equivalent) from an approved random bit generator (see Sec. 3.2.12 of SP800-63B).

Determine if the CSP uses confirmation codes and, if it does, confirm that these codes are comprised of at least 6 digits (or equivalent) from a random bit generator.

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.

A random bit generator (RGB) is a device or algorithm that can produce a sequence of bits that appear to be both statistically independent and unbiased.

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); and 24 hours when sent to a validated email address.

Determine if the CSP uses confirmation codes and, if it does, confirm that they meet the validity requirements specified in section 3.8.

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

Determine if the CSP uses confirmation codes and, if it does, confirm the codes are invalidated upon use.

Continuation codes SHALL include at least 64 bits from an approved random bit generator (see Sec. 3.2.12 of [SP800-63B]).

Determine if the CSP uses continuation codes and, if it does, confirm that these codes are comprised of at least 64 bits from a random bit generator.

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 random bit generator (RGB) is a device or algorithm that can produce a sequence of bits that appear to be both statistically independent and unbiased.

The verification of continuation codes SHALL be subject to throttling requirements, as provided in Sec. 3.2.2 of [SP800-63B].

Determine if the CSP uses continuation codes and, if it does, confirm that the use of these codes is subject to throttling requirements provided in NIST SP 800-63B-4, Sec. 3.2.2.

In the case of continuation codes, throttling is a mechanism that limits the number of failed attempts at entering a continuation code.

Continuation codes SHALL be stored in hashed form using a Federal Information Processing Standards (FIPS)-approved or NIST-recommended one-way function.

Determine if the CSP uses continuation codes and, if it does, confirm that these codes are stored in hashed form, as specified in item #5 of Sec. 3.9.

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

Determine if the CSP uses continuation codes and, if it does, confirm that the codes are invalidated upon use.

Since substantial time may elapse between when an applicant receives their continuation code and when they are able to complete the proofing process, expiry is not defined in these guidelines. Expiry will need to be defined by the CSP based on their processes, technologies, and partnerships.

Notifications of proofing 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.

Confirm that the CSP sends notifications of proofing at IALs 2 and 3 to validated postal addresses or phone numbers.

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. Per Sec. 2.4.2.3, validated postal addresses or phone numbers are those that have been confirmed (validated) with an authoritative source or credible source, such as a mobile network operator or AAMVA.

Notifications of proofing 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.

Confirm that the CSP includes appropriate details about the identity proofing event in its notifications of proofing.

Notifications of proofing SHALL provide clear instructions, including contact information, on actions for the recipient to take if they repudiate their participation in the identity proofing event.

Confirm that the CSP's notifications of proofing include clear instructions for how recipients can deny their participation in an identity proofing event with the CSP.

Notifications of proofing SHALL provide information about how the organization or CSP protects the security and confidentiality of the information it collects.

Confirm that the CSP's notifications of proofing include information about how it protects the security and confidentiality of the recipient's personal information.

Notifications of proofing SHALL provide information about any responsibilities that the recipient has as a subscriber of the identity service.

Confirm that the CSP's notifications of proofing include information about any responsibilities that the recipient has as a subscriber of the identity service.

Examples of subscriber responsibilities may be to not share their account information with anyone else or to report any suspected fraud associated with their account to the CSP as soon as possible.

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.

Confirm that the CSP or RP has a defined policy for responding to subscriber repudiations.

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.

Confirm that the CSP discloses complete information about its uses of biometrics in a way that is clear and understandable to the general public.

CSPs SHALL obtain explicit informed consent to collect and use biometrics from all applicants.

Confirm that the CSP obtains informed consent from applicants prior to the collection and use of their biometric attributes.

CSPs SHALL store a record of the subscriber's consent for biometric use and associate it with the subscriber's account.

Confirm that the CSP stores a record of the subscriber's consent for biometric use and that it is associated with the subscriber's account.

CSPs SHALL have a documented and publicly available deletion process and default retention period for all biometric information. Retention periods SHALL be consistent with applicable regulations, policies, and statutes for the regions and sectors that the CSP serves.

Determine the applicable biometric retention regulations, policies, and statutes applicable to the CSP's identity service and confirm that the CSP has documented and made publicly available its process and default retention period(s) for all biometric information, in accordance with these requirements.

If a CSP does not support biometric deletion requests, it SHALL publicly document the regulatory, statutory, or risk-based justification for their policy.

If the CSP DOES NOT support biometric deletion request, confirm that it has publicly disclosed the regulatory, statutory, and risk-based justification for their policy.

CSPs SHOULD support the deletion of all of a subscriber's biometric information upon the subscriber's request, except where otherwise restricted by regulation, law, or policy.

CSPs SHALL have their biometric recognition and attack detection algorithms periodically tested by independent entities for their performance characteristics, including performance across demographic groups.

Confirm that the CSP periodically employs independent organizations to test its biometric algorithms testing for their performance characteristics, including performance across demographic groups.

In addition, the CSP SHOULD conduct internal testing on biometric algorithms based on the update schedule of the provider.(Ref.Sec.3.11 #6A)

CSPs SHALL assess the performance and demographic impacts of employed biometric technologies in conditions that are substantially similar to the operational environment and user base of the system.

Confirm that the CSP assesses the performance of any employed biometric technologies under conditions that are substantially similar to the operational environment and the user base(s) of the identity service.

The user base is defined by both the expected users and the devices they are expected to use.

When biometric performance assessments include real-world users, participation by users SHALL be voluntary.

Determine if the CSP's biometric performance assessments include real-world users and, if so, confirm that participation by these users is entirely voluntary.

CSPs SHALL meet the following performance thresholds if one-to-one (1:1) comparison algorithms are used for verification against a claimed identity: false match rate: 1:10,000 or better; and false non-match rate: 1:100 or better.

Determine if the CSP employs 1:1 comparison algorithms as part of the identity verification process and, if it does, confirm the algorithms meet the required performance thresholds.

If a CSP uses one-to-many (1:N) scenarios, it SHALL meet a minimum performance threshold for false positive identification of 1:1,000 or better.

Determine if the CSP employs 1:N identification and, if it does, confirm the algorithms meet or surpass the stated performance threshold.

CSPs MAY use one-to-many (1:N) identification in support of resolution or deduplication, pursuant to a privacy risk assessment.

Tests that demonstrate this requirement SHALL employ a gallery no smaller than 90% of the current or intended operational size (N).

Confirm that the tests the CSP uses to test FPIR for 1:N comparisons employs a gallery of at least 90% of the current intended operational size (N).

A 1:N search of an applicant's collected biometric characteristics against a database is done to determine whether the applicant is already present in the database, possibly under a different name. The false positive identification rate (FPIR) refers to the proportion of 1:N searches in which a biometric system incorrectly identifies another person as a match, which is a false positive result. The performance metric of 1:1,000 means that a false positive outcome occurs for no more than 1 in every 1,000 searches.

CSPs that make use of 1:N biometric identification for resolution, deduplication, or fraud detection purposes SHALL NOT decline a user's enrollment without a manual review to confirm the automated search results and confirm that the results are not a false positive identification.

If a CSP employs 1:N biometric identification, confirm that it does not decline a user's enrollment into an identity service based on a positive 1:N comparison match.

One possible reason for a false positive result is twins submitting face photographs for different accounts with the same CSP.

Biometric verification technologies SHALL provide performance for applicants of different demographic types that is no more than 25% worse than the performance for the overall population.

Confirm that the CSP employs biometric verification technologies that have been tested across different demographic groups and whose demonstrated performance differences do not exceed 25%.

For example, if the measured false nonmatch rate (FNMR) for the overall population is 0.006, the FNMR for a specific demographic group cannot exceed 0.0075. Similarly, if the false match rate (FMR) for the overall population is 0.0001, the FMR for each demographic group cannot exceed 0.000125.

The biometric system SHALL be configured with a fixed threshold; it is not feasible to change the threshold for each demographic group.

Confirm that the CSP employs a biometric threshold that is consistent across all demographic groups.

Demographic categories to be considered SHALL include sex, age, and skin tone when these factors affect biometric performance.

Confirm that the CSP considers sex, age, and skin tone as demographic categories for its biometric performance testing.

All biometric performance tests SHALL be conformant to ISO/IEC 19795-1:2021 and ISO/IEC 19795-10:2024, including demographics testing.

Confirm that all biometric performance testing, including demographics testing, employed by the CSP adheres to ISO/IEC 19795-1:2021 and ISO/IEC 19795-10:2024.

CSPs SHALL make the results of their biometric algorithm performance and biometric system operational test results publicly available.

Confirm that the CSP makes the results of its biometric algorithm performance and biometric system operational test publicly available.

The CSP MAY provide these test results in summary form if the results indicate performance against the defined metrics in these guidelines and across the tested demographic groups.

If a CSP collects biometric samples from applicants, it SHALL collect them in a way that provides reasonable assurance that the biometric characteristic is collected from the applicant and not another subject.

Determine if the CSP collects biometric samples from applicants and, if it does, confirm that it has employed mechanisms to increase the assurance that the sample is being collected from the applicant and not a different subject.

Mechanisms that mitigate risks associated with biometric collection fraud include liveness detection, and digital injection and other types of presentation attack detection (such as mechanisms to detect the presence of a foreign object).

When collecting and comparing biometric characteristics remotely, the CSP SHALL implement presentation attack detection (PAD) capabilities that meet the impostor attack presentation accept rate (IAPAR) performance metric of <0.07 to confirm the genuine presence of a live human being and to mitigate spoofing and impersonation attempts.

Confirm that the CSP has employed PAD capabilities that meet the specified IAPAR performance metric for its remote biometric collection or comparison functions.

All biometric presentation attack detection tests SHALL be conformant to ISO/IEC 30107-3:2023.

Confirm that all biometric PAD tests employed by the CSP conform to ISO/IEC 30107-3:2023.

When collecting biometric characteristics on-site, the CSP SHALL have the operator view the biometric source (e.g., fingers, face) for the presence of unexpected non-natural materials and perform such inspections as part of the proofing process.

Confirm that, for on-site biometric collection as part of the identity proofing process, human agents of the CSP examine the source of the biometric (e.g., fingers, face) for the presence of any unexpected, non-natural materials.

Proofing agents and trusted referees SHALL be trained to conduct visual facial image comparison.

Confirm that the CSP trains its proofing agents and trusted referees in how to effectively conduct visual comparisons of facial images.

This training SHALL include techniques and methods for identifying facial characteristics, unique traits, and other indicators of matches or non-matches between an applicant and their presented evidence.

Confirm that the training the CSP provides for its proofing agents and trusted referees includes methods for identifying facial characteristics, unique traits, and other indicators of matches or non-matches between an applicant and their presented evidence.

Proofing agents and trusted referees SHALL be assessed on their ability to conduct visual facial image comparisons.

Confirm that the CSP assesses its proofing agents and trusted referees on their ability to conduct visual facial image comparisons.

Additionally, proofing agents and trusted referees SHALL be reassessed on an annual basis and remedially trained, if needed.

Confirm that the CSP annually reassesses its proofing agents and trusted referees on their ability to conduct visual facial image comparisons and provides remedial training, if needed.

Training SHALL be designed to reflect potential real-world attack scenarios, such as comparing applicants to images of relatives, twins, and individuals with a similar appearance.

Confirm that the CSP designs its visual image comparison training to address real-world scenarios that might result in incorrect visual comparison determinations.

CSPs SHALL provide proofing agents and trusted referees that conduct visual facial comparisons during remote attended transactions with resources that support accurate comparisons, such as high-quality image feeds, high-definition monitors, and image analysis software.

Confirm that the CSP provides its proofing agents and trusted referees that conduct visual facial comparisons during remote transactions with resources that support the accuracy of those comparisons.

CSPs SHALL document their training and assessment procedures for visual image comparisons and make them available to RPs upon request.

Confirm that the CSP has documented its visual image comparison training and assessment procedures and makes them available to their RPs upon request.

These requirements SHALL apply for visual facial image comparisons done as manual reviews for failures of automated biometric comparisons (e.g., failure of 1:N checks conducted for resolution or deduplication).

Confirm that the CSP trains and assesses its proofing agents and trusted referees who conduct manual reviews for failures of automated biometric comparisons, in accordance with the requirements provided in Sec. 3.12.

Also see Sec. 3.11 #11 and Sec. 3.15.2 #2.

Automated evidence validation technology SHALL meet the following performance measures: document false acceptance rate (DFAR) of 0.1 or less; and document false rejection rate (DFRR) of 0.1 or less.

If the CSP employs automated evidence validation technology, confirm that it meets the specified performance metrics.

For the purposes of this document, the DFAR is the proportion of processed, fraudulent documents that the document validation system determined to be valid divided by the number of processed fraudulent documents. For the purposes of this document, DFRR is the proportion of processed, genuine documents that the document validation system determined to be invalid divided by the number of processed genuine documents.

If a Machine Readable Zone (MRZ) or barcode is present on the evidence, the optical capture and inspection SHALL compare the MRZ data to the printed data on the evidence for consistency.

For evidence with MRZs or barcodes, confirm that the CSP employs optical capture and inspection capabilities that compare the MRZ data with the printed data on the evidence.

CSPs SHALL implement live capture of documents during the validation process and SHALL implement passive or active document presence checks (also called document liveness).

Confirm that the CSP employs live capture of documents during its validation process and that the live capture capabilities include document presence checks.

Live capture techniques confirm that the document is physically present and that the image captured during the identity proofing session is not a manipulated digital copy. For additional requirements to prevent the injection of modified media (i.e., digitally generated video or images of evidence), see Sec. 3.14.

CSPs SHALL assess the performance of employed optical capture and inspection technologies in conditions that are substantially similar to the operational environment and the types of evidence presented by the user base of the system.

Confirm that the CSP assesses the performance of any employed optical capture and inspection technologies under conditions that are substantially similar to the operational environment and the types of evidence presented by the user base of the system.

These tests SHALL account for all available identity evidence types that the CSPs allow to be validated using optical capture and inspection technology.

Confirm that the CSP's optical capture and inspection performance testing incorporates all the types of evidence it accepts to be validated using optical capture and inspection capabilities.

If subscribers' documents, personal information, or images are used as part of the testing, it SHALL be on a voluntary basis and with subscriber notification and consent.

If the CSP uses documents, personal information, or images belonging to real users as part of its image capture performance testing, confirm that participation by the user is entirely voluntary and that the CSP first provides notification to the user and obtains their consent.

These requirements apply to technologies that capture and validate images of physical identity evidence. They do not apply to validation techniques that rely on PKI or other cryptographic technologies that are embedded in the evidence itself.

CSPs SHALL make the results of their testing publicly available.

Confirm that the CSP makes publicly available the results of any performance assessments it conducts on its image capture and validation technologies.

CSPs SHOULD have their evidence validation technology periodically tested by independent entities (e.g., accredited laboratories or research institutions) for their performance characteristic.

Proofing agents and trusted referees SHALL be trained and provided with the resources to visually inspect all forms of evidence supported by the CSP. This training SHALL include: authentic layouts and topography of evidence types; physical security features (e.g., raised letters, holographic features, microprinting); techniques for assessing features (e.g., tools to be used, where tactile inspection is needed, manipulation required to view specific features); and common indications of tampering (e.g., damage to the lamination, image modification).

Confirm that the CSP trains its proofing agents and trusted referees and provides them with the resources they need to visually inspect all forms of evidence supported by the CSP and confirm that this training includes all the specified elements.

Proofing agents and trusted referees SHALL be assessed regarding their ability to visually inspect evidence based on their training. Additionally, proofing agents and trusted referees SHALL be reassessed on an annual basis or whenever significant new threats to the evidence validation process are identified and remedially trained as needed.

Confirm that the CSP (1) assesses the ability of its trained proofing agents and trusted referees to visually inspect all types of supported evidence, (2) re-assesses these agents on an annual basis, and (3) provides remedial training as needed.

Proofing agents and trusted referees SHALL be provided with specialized tools and equipment to support the visual inspection of evidence as appropriate for the identity evidence type.

Confirm that the CSP provides its proofing agents and trusted referees with specialized tools that support the visual inspection of supported evidence types.

Specialized tools may include magnifiers, ultraviolet lights, barcode readers, etc.

Proofing agents and trusted referees who conduct visual inspections via remote means SHALL be provided with devices and internet connections that support sufficiently high-quality imagery to be able to effectively inspect presented evidence.

Confirm that the CSP provides its proofing agents and trusted referees who conduct visual inspections in remote scenarios with devices and internet connections that support sufficiently high-quality imagery.

CSPs SHALL document their training and assessment procedures for visual inspections of evidence and make them available to RPs upon request.

Confirm the CSP has documented its training and assessment procedures for visual inspections of evidence and makes them available to its RPs upon request.

CSPs SHALL implement technical controls to increase confidence that digital media is being produced by a genuine sensor during the proofing process.

Confirm that the CSP has implemented technical controls that check for the use of genuine sensors during the identity proofing process.

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

CSPs SHALL analyze all digital media submitted during the identity proofing process for artifacts and indicators of potential modification, manipulation, tampering, or forgery.

Confirm that the CSP employs a mechanism to analyze whether submitted digital media contains artifacts or other indicators of having been modified or forged.

Automated image analysis algorithms SHALL be tested against available attack artifacts and genuine media to provide a baseline of performance and to determine the expected rate of false positives and false negatives generated by the system.

If a CSP employs automated image analysis algorithms, confirm that these algorithms has been tested against available attack artifacts and genuine media and that expected rates of false positives and false negatives have been determined.

The kinds of available attack artifacts that were tested and the corresponding false negative rates SHALL be documented and made available to RPs upon request.

If a CSP employs automated image analysis algorithms, confirm that is has documented the types of attack artifacts that were tested and the corresponding false negatives and that this information has been made available to any of its RPs that request it.

CSPs SHALL only use authenticated protected channels for the exchange of data during remote identity proofing processes.

Confirm that the CSP always employs authenticated protected channels for the exchange of date during remote identity proofing processes.

For remote attended scenarios, CSPs SHALL train proofing agents and trusted referees to look for indications of manipulated media.

Confirm that the CSP trains its proofing agents and trusted referees how to look for indications of digital media fraud in remote attended scenarios.

For remote attended scenarios, CSPs SHALL introduce random "human-in-the-loop" cues into their capture processes to increase the possibility of forged or manipulated media being detected.

Confirm that the CSP introduces random "human-in-the-loop" cues into its capture processes during remote attended scenarios

Examples of "human-in-the-loop" cues include requesting user movements or requesting that the user move objects between the capture sensor and their face.

CSPs SHALL document their operational processes for dealing with errors and handling exceptions.

Confirm that the CSP has documented its error and exception handling processes.

Throughout the identity proofing process, there are many points at which errors or failures may occur. Such exceptions to a standard identity proofing workflow include process failures (e.g., when a user does not possess the required evidence), technical failures (e.g., when an integrated service is not available), and failures due to user error (e.g., when an applicant is unable to capture a clear image of their identity evidence using remote validation tools). These documented processes SHOULD include providing trusted referees to support applicants who are otherwise unable to meet the requirements of IALs 1 and 2. Additionally, CSPs SHOULD support the use of applicant references who can vouch for an applicant's attributes, conditions, or identity.

The CSP SHALL notify the public of the availability of trusted referee services and how such services are obtained.

[If the CSP provides trusted referees], confirm that it notifies the public of their availability and how to obtain their services.

Trusted referees are used to increase access to online services by facilitating the identity proofing and enrollment of individuals who are otherwise unable to prove their identities using the usual identity proofing process for a specific IAL. A non-exhaustive list of examples of individuals who may need the assistance of trusted referees includes those who do not possess and cannot obtain the required identity evidence, persons with disabilities, older individuals, persons experiencing homelessness, individuals with limited access to online services or computing devices, persons without a bank account or with limited credit history, victims of identity theft, individuals displaced or affected by natural disasters, and children under 18. Trusted referees can be provided by the CSP, a third party, or an RP.

The CSP SHALL establish written policies and procedures for the use of trusted referees as part of its practice statement, as specified in Sec. 3.1.

Confirm that the CSP has established written policies and procedures for the use of trusted referees.

The CSP SHALL train and certify its trusted referees to make risk-based decisions that allow applicants to be successfully identity-proofed based on their unique circumstances. At a minimum, such training SHALL include:

(a) Document identification and validation, such as common templates, security features, layouts, and topography (see Sec. 3.13).

(b) Indicators of fraudulent documents, such as damage, tampering, modification, fabrication, or forgery (see Sec. 3.13).

(c) Facial image comparisons to verify applicants against presented documents (see Sec. 3.12).

(d) Indicators of social engineering exhibited by an applicant, such as distress, confusion, or coercion.

(e) An annual review of the trusted referee's abilities to visually inspect evidence and make visual facial image comparisons (see Sec. 3.12).

Confirm that the CSP trains and certifies its trusted referees in accordance to the specified requirements.

The CSP SHALL establish a record of any identity proofing session that involves a trusted referee, including the reasons why a trusted referee was used (e.g., automated process failure, applicant request, established exception policy), the identity of the trusted referee, what evidence was presented, which processes were completed (e.g., validation or verification), and the trusted referee's decision and, if negative, their rationale.

Confirm that the CSP establishes a record whenever a trusted referee is involved in the identity proofing of an applicant, and that this record includes, at the minimum, the details specified in this requirement.

While the details of trusted referee usage will necessarily be associated with the subject being identity proofed, it is expected that some or all of this information will not be visible to the subject through in subscriber account.

These sessions SHALL be consistent with the requirements of these proofing types based on the IAL of the proofing event.

Confirm the CSP's policy on meeting all applicable requirements for identity proofing transactions, regardless of whether or not a trusted referee is involved.

All applicable requirements must be met, regardless of the use of trusted referees.

CSPs SHALL document which types of exceptions and failures are eligible for the use of a trusted referee.

Confirm the CSP has documented the scenarios that are eligible for trusted referee involvement in an identity proofing transaction.

If a CSP offers trusted referees [are offered for failures in completing automated validation processes], the following requirements apply:

(a) CSPs SHALL provide a policy for additional evidence types that may be used to corroborate core attributes or changes in core attributes.

(b) Trusted referees SHALL review additional evidence types for authenticity to the greatest degree allowed by the evidence.

(c) If no authoritative or credible records are available to support validation, the trusted referee MAY compare the attributes on additional pieces of evidence with the strongest piece of evidence available to corroborate the consistency of core attributes.

(d) If there is a partial mismatch of core attributes to authoritative records, the trusted referee SHALL review evidence that supports the legitimacy of the asserted attribute value (e.g., recent move or change of name).

Determine if the CSP offers trusted referees to assist with automated validation failures and, if it does, confirm that their involvement in these scenarios adheres to the specified requirements.

CSPs SHOULD offer trusted referee services for failures in completing automated validation processes, such as mismatched core attributes or the absence of the applicant in a record source.

The CSP SHALL notify the public of the allowability of applicant references and any requirements for the relationship between the reference and an applicant.

Confirm if the CSP provides a notice to the public about the allowability of applicant references to assist in identity proofing transactions along with any requirements for their use.

Applicant references are individuals who participate in the identity proofing of an applicant in order to vouch for the applicant's identity, attributes, or circumstances related to the applicant's ability to complete identity proofing. Applicant references are not agents of the CSP, but rather representatives of the applicant who have sufficient knowledge to aid in the completion of identity proofing when other forms of evidence, validation, and verification are not available. Applicant references are permissible at IAL 1 and IAL 2 only.

The CSP SHALL establish written policies and procedures for the use of applicant references as part of its practice statement, as specified in Sec. 3.1.

Confirm that the CSP has written policies and procedures for the use of applicant references.

The CSP SHALL identity-proof an applicant reference to the same or higher IAL intended for the applicant.

Determine if the CSP allows the use of applicant references and, if it does, confirm that all applicant references are identity-proofed to the same or higher IAL as the applicant or applicants they are supporting.

The CSP SHALL include the information collected, recorded, and retained for identity proofing the applicant references in its privacy risk assessment, as required in section Sec. 3.3.1.

Confirm that the CSP included all personal data associated with the use of applicant references in its privacy risk assessment.

The CSP SHALL record the use of an applicant reference in the subscriber account and maintain a record of the applicant reference and their relationship to the applicant.

Confirm that the CSP records the use of applicant references in the associated subscriber accounts, including their relationship to the applicant.

The RP SHALL conduct a risk assessment to determine the applicability, business requirements, and potential risks associated with excluding or including applicant references for proofing events.

Confirm that the RP has conducted a risk assessment that considers the impacts of both allowing and not allowing the use of applicant references.

If CSPs allow the use of applicant references, the CSPs and the RPs that use their services SHALL document all acceptable uses for applicant references in their contracts or trust agreements.

If CSPs allow for the use of applicant references, confirm that acceptable uses of their services are documented in any contacts or trust agreements with RPs.

In all instances, the CSP SHALL establish a record of the role that the applicant reference played in the process and document these actions sufficient to support any applicable legal and regulatory requirements.

Determine that the CSP has identified any legal or regulatory requirements associated with the use of applicant references, and confirm that it records sufficient details about the use of an applicant reference to support those requirements.

CSPs SHALL make available to the applicant reference clear and understandable information relative to the legal and liability impacts that may result from their participation as an applicant reference.

Confirm that the CSP makes information available to potential applicant references about any legal or liability implications associated with their participation in the identity proofing of an applicant.

The CSP and RP SHALL establish requirements for applicant reference relationship confirmation processes and document them in any contracts or trust agreements.

Confirm that the requirements and process for confirming the relationship between an applicant and their applicant reference is documented in any contracts or trust agreements between CSPs and RPs.

The CSP SHALL make a list of acceptable evidence of relationship available to the applicant reference prior to initiating the relationship confirmation process.

Confirm that the CSP provides a list of acceptable evidence of the relationship between an applicant and their applicant reference prior to initiating the relationship confirmation process.

The CSP SHALL request evidence of the applicant's relationship (e.g., notarized power of attorney, a professional certification).

Confirm that the CSP collects evidence supporting the relationship between an applicant and their applicant reference.

Upon successfully identity proofing an applicant, the CSP SHALL record the evidence used to confirm the applicant reference's relationship to the applicant in the subscriber account.

Confirm that the CSP records the evidence used to confirm the relationship between an applicant and their applicant reference and associates it with the subscriber's account.

The CSP SHALL establish a written policy and procedures as part of its practice statement for identity proofing minors who may not be able to meet the evidence requirements for a given IAL.

Confirm that the CSP has documented its policy and procedures for the identity proofing of minors who are unable to meet the evidence requirements for a given IAL.

When interacting with persons under the age of 13, the CSP SHALL ensure compliance with the Children's Online Privacy Protection Act of 1998 [COPPA] or other laws and regulations that deal with the protection of minors, as applicable.

Confirm that the CSP complies with COPPA and any other laws and regulations that deal with the protection of minors.

CSPs SHALL support the use of applicant references when interacting with individuals under the age of 18.

Confirm that the CSP allows for the use of applicant references for the identity proofing of individuals under the age of 18.

CSPs SHALL document their approved approaches for elevating assurance levels in their practice statements.

If the CSP supports the elevation of subscriber assurance levels, confirm that the CSP has documented its policy and approved approaches for this process.

CSPs SHOULD allow subscribers to elevate IALs related to their subscriber accounts to support higher assurance transactions with RPs.

CSPs SHALL require subscribers to authenticate at the highest authentication assurance level (AAL) available on their account prior to initiating the upgrade process.

If the CSP supports the elevation of subscriber assurance levels, confirm that it requires subscribers to authenticate at the highest 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.

If the CSP supports the elevation of subscriber assurance levels, confirm that it collects, validates, and verifies additional evidence, as needed to meet the requirements of the higher IAL.

CSPs that combine elements of different proofing types SHALL document their hybrid process and state how the applicable requirements for each of the employed proofing types are met.

If the CSP employs a hybrid process, confirm that it is documented, and such documentation includes details about how the applicable requirements for each proofing type are met.

IAL1 identity proofing MAY be delivered through any proofing type, as described in Sec. 2.1.3. CSPs MAY combine proofing types and their stated requirements to create hybrid processes. For example, a CSP might leverage remote unattended identity proofing validation processes in advance of a remote attended session where the verification will take place.

For identity proofing at IAL1, the CSP SHALL collect: one piece of FAIR evidence that can be digitally validated or that includes a facial portrait or other biometric; OR, one piece of STRONG evidence; OR, one piece of SUPERIOR evidence.

Confirm that the CSP collects the specified evidence for identity proofing at IAL 1.

The CSP SHALL collect all core attributes, including at least one government identifier.

Confirm that the CSP collects all core attributes, including at least one government identifier.

Validated evidence is the preferred source of identity attributes. If the presented identity evidence does not provide all of the attributes that the CSP considers to be core attributes, it MAY collect attributes that are self-asserted by the applicant.

Each piece of evidence presented SHALL be validated using one of the methods [provided in Sec. 4.1.4].

Confirm that the CSP validates all collected evidence as specified.

The CSP SHALL validate all core attributes and the government identifier against an authoritative or credible source to determine accuracy.

Confirm that the CSP validates all collected core attributes as specified.

CSPs SHOULD evaluate attributes obtained from different sources (e.g., presented evidence, self-asserted, authoritative or credible sources) for consistency.

CSPs SHOULD validate any reference numbers on the presented identity evidence, if available.

The CSP SHALL verify the applicant's ownership of one piece of evidence using one of the methods [provided in 4.1.6].

Confirm that the CSP verifies the applicant's ownership of at least one piece of collected evidence using one of the specified methods.

If the visual 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.

Confirm that the CSP has implemented PAD and passive and active document liveness checks for the asynchronous visual comparison of an applicant to their identity evidence.

For Remote Attended identity proofing, the applicant SHALL remain in view of the proofing agent during each step of the proofing process.

For remote attended video sessions, confirm the CSP requires that the applicant is visible to the proofing agent for each step of the identity proofing process.

For Remote Attended identity proofing, the video quality SHALL be sufficient to support the necessary steps in the validation and verification processes, such as inspecting evidence and comparing the applicant to the evidence.

For remote attended video sessions, confirm the video quality is sufficient to support the needs of the identity proofing process.

For Remote Attended identity proofing, the proofing agent SHALL be trained to identify signs of manipulation, coercion, or social engineering occurring during the session.

Confirm the CSP trains its agents to identify signs that an applicant has been coerced or manipulated into participating in the identity proofing process.

For Remote Attended identity proofing, if the CSP records a video session, the following further requirements apply:

(a) The CSP SHALL notify the applicant of the recording prior to initiating a recorded session.

(b) The CSP SHALL gain consent from the applicant prior to initiating a recorded session.

(c) The CSP SHALL publish their retention schedule and deletion processes for all video records.

If the CSP records remote attended video identity proofing sessions, confirm that the specified requirements are met.

For Remote Attended identity proofing, the CSP SHALL implement injection protection and modified media controls, as defined in Sec. 3.14.

Confirm that the CSP employs injection protection and controls against modified media.

For Remote Attended identity proofing, the CSP SHALL provide proofing agents with a method or mechanism to flag events for potential fraud.

Confirm the CSP provides its proofing agents with a mechanism to flag potential fraud.

For On-site Attended identity proofing, the CSP SHALL provide a physical setting in which on-site identity proofing sessions are conducted.

Confirm the CSP provides physical location in for on-site attended identity proofing.

For On-site Attended identity proofing, all devices SHALL be protected by appropriate baseline security features comparable to FISMA moderate controls, including malware protection, administrator-specific access controls, and software update processes.

Confirm that the CSP employs security controls comparable to FISMA moderate or higher for all equipment used for on-site attended identity proofing.

For On-site Attended identity proofing, CSP proofing agents SHALL be trained to identify signs of manipulation, coercion, or social engineering occurring during the on-site session.

Confirm the CSP trains its agents to identify signs that an applicant has been coerced or manipulated into participating in the identity proofing process.

For On-site Attended identity proofing, if the CSP records a video session, the following additional requirements apply:

(a) The CSP SHALL notify the applicant of the recording prior to initiating a recorded session.

(b) The CSP SHALL gain consent from the applicant prior to initiating a recorded session.

(c) The CSP SHALL publish their retention schedule and deletion processes for all video records.

If the CSP records remote attended video identity proofing sessions, confirm that the specified requirements are met.

For On-site Attended identity proofing, the CSP SHALL provide proofing agents with a method or mechanism to covertly flag events for potential fraud.

Confirm the CSP provides its proofing agents with a mechanism to flag potential fraud.

For On-site Unattended identity proofing, the CSP SHALL provide a physical setting in which on-site identity proofing sessions are conducted.

Confirm the CSP provides physical location in for on-site attended identity proofing.

For On-site Unattended identity proofing, all devices SHALL be protected by appropriate baseline security features comparable to FISMA moderate controls, including malware protection, administrator-specific access controls, and software update processes.

Confirm that the CSP employs security controls comparable to FISMA moderate or higher for all equipment used for on-site attended identity proofing.

For On-site Unattended identity proofing, all devices SHALL be inspected periodically by trained technicians to deter tampering, modification, or damage.

Confirm that the CSP has a policy for ensuring that all equipment used for on-site attended identity proofing is periodically inspected by technicians who are trained to detect tampering, modification, and damage.

For On-site Unattended identity proofing, if the CSP records a video session, the following additional requirements apply:

(a) The CSP SHALL notify the applicant of the recording prior to initiating a recorded session.

(b) The CSP SHALL gain consent from the applicant prior to initiating a recorded session.

(c) The CSP SHALL publish their retention schedule and deletion processes for all video records.

If the CSP records remote attended video identity proofing sessions, confirm that the specified requirements are met.

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.

Confirm that the CSP sends notifications of proofing to validated addresses for applicants after they have successfully complete identity proofing.

Notifications can be delivered to test accounts and addresses as appropriate based on the capabilities of the assessor or the testing environment available to them and any privacy restrictions on the use of legitimate addresses.

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

(a) 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].

(b) Distribution of a physical authenticator to a validated address.

(c) Distribution or on-site enrollment of an authenticator.

Confirm that the CSP provides the ability for an applicant to bind an authenticator using one of the specified methods.

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:

(a) Return of a continuation code.

(b) Comparison against a biometric collected at the time of proofing.

For authenticators that are bound outside of a single, protection session, confirm that the CSP validates the presence of the intended subscriber through using one of the specified methods.

If such steps are combined, CSPs SHALL document their hybrid process and state how the applicable requirements for each of the employed proofing types are met.

[If the CSP employs a hybrid process], confirm that it is documented, and such documentation includes details about how the applicable requirements for each proofing type are met.

IAL2 identity proofing MAY be delivered through any proofing type, as described in Sec. 2.1.3. CSPs MAY combine proofing types and their stated requirements to create hybrid processes. For example, a CSP might leverage remote unattended identity proofing validation processes in advance of a remote attended session where the verification will take place.

For identity proofing at IAL2, the CSP SHALL collect: one piece of FAIR evidence and one piece of STRONG evidence; OR, two pieces of STRONG evidence; OR, one piece of SUPERIOR evidence.

Confirm that the CSP collects the specified evidence for identity proofing at IAL 2.

The CSP SHALL collect all core attributes, including at least one government identifier. Validated evidence is the preferred source of identity attributes.

Confirm that the CSP collects all core attributes, including at least one government identifier.

If the presented identity evidence does not provide all of the attributes that the CSP considers to be core attributes, it MAY collect attributes that are self-asserted by the applicant.

Each piece of FAIR or STRONG evidence that is presented SHALL be validated using one of the following techniques:

(a) Confirming the authenticity of the digital evidence by interrogating the digital security features (e.g., signatures on assertions or data).

(b) Confirming the authenticity of the physical evidence using automated scanning technology that can detect physical security features.

(c) 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).

(d) Confirming the integrity of any physical security features through physical and tactile inspection by a proofing agent at an on-site location.

Confirm that the CSP validates each piece of FAIR and STRONG evidence as specified.

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.

Confirm that the CSP validates each piece of SUPERIOR evidence as specified.

The CSP SHALL validate all core attributes by either:

(a) Comparing the government identifier and other core attributes against an authoritative or credible source to determine accuracy.

(b) Validating the accuracy of digitally signed attributes that are contained on SUPERIOR evidence through the public key of the issuing source.

Confirm that the CSP validates all collected core attributes as specified.

CSPs SHOULD evaluate attributes obtained from different sources (e.g., presented evidence, self-asserted, authoritative or credible sources) for consistency.

CSPs SHOULD validate any reference numbers on the presented identity evidence, if available.

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.

If the CSP offers more than one verification pathway at IAL2, confirm that it records the employed pathway in its subscriber accounts.

CSPs that offer multiple verification pathways SHALL make that information available to RPs in the assertion, API, or as part of their trust agreement.

If the CSP offers more than one verification pathway at IAL2, confirm that it makes this information available to RPs that use its service.

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.

When the Non-Biometric Pathway is used, confirm the CSP records whether verification was accomplished through a mailed confirmation code or a visual comparison of the applicant against evidence.

If provided as an option at IAL2, CSPs SHALL communicate their use of the Non-Biometric Pathway to all RPs that use their identity service.

Confirm that the CSP communicates its use of the Non-Biometric Pathway to all RPs that use its service.

The IAL2 Non-Biometric Pathway provides verification methods that do not use an automated comparison of biometric samples provided by the applicant. This pathway can still involve the collection and verification of biometric data (e.g., visual comparison to a facial image contained on identity evidence performed by a proofing agent), but such comparisons are done through manual rather than automated means. Additional verification methods that do not require the use of automated biometric comparison are also included in the Digital Evidence Pathway requirements specified in Sec. 4.2.6.2.

For remote attended, remote unattended, and on-site unattended identity proofing, the CSP SHALL verify the applicant's ownership of all pieces of presented identity evidence. For on-site attended identity proofing, the CSP SHALL verify the applicant's ownership of the strongest piece of presented identity evidence.

For the Non-Biometric Pathway, confirm that the CSP meets the evidence ownership verification requirements associated with the identity proofing type.

Approved non-biometric methods for verifying FAIR evidence at IAL2 include:

(a) Confirming the applicant's ability to return a confirmation code delivered to a validated address associated with the evidence (e.g., postal address, phone number).

(b) Visually comparing the applicant's facial image to a facial portrait on the presented evidence (e.g., student or employee ID card) 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).

Approved non-biometric methods for verifying STRONG and SUPERIOR evidence at IAL2 include:

(b) Visually comparing the applicant's facial image to a facial portrait on the presented 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 captured identity proofing event.

For remote attended, remote unattended, and on-site unattended identity proofing, the CSP SHALL verify the applicant's ownership of all pieces of presented identity evidence. For on-site attended identity proofing, the CSP SHALL verify the applicant's ownership of the strongest piece of presented identity evidence.

For the Digital Evidence Pathway, confirm that the CSP meets the evidence ownership verification requirements associated with the identity proofing type.

Approved digital evidence verification methods for FAIR evidence at IAL2 include: (a Confirming the applicant's ability to return a microtransaction value delivered to a validated account (e.g., checking account owned by the applicant that has been validated by an authoritative or credible source).

(b) Confirming the applicant's ability to return a confirmation code delivered to a validated digital address associated with the digital evidence (e.g., MNO/phone account).

(c) Confirming the applicant's ability to successfully complete an authentication and federation protocol equivalent to AAL2/FAL2 to access an account related to the identity evidence.

Approved digital evidence verification methods for STRONG evidence at IAL2 involve 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.

Approved digital evidence verification methods for SUPERIOR evidence at IAL2 include confirming the applicant's possession of the evidence through the use of a local activation factor and the presentation of a cryptographically verifiable attribute bundle.

For remote attended, remote unattended, and on-site unattended identity proofing, the CSP SHALL verify the applicant's ownership of all pieces of presented identity evidence. For on-site attended identity proofing, the CSP SHALL verify the applicant's ownership of the strongest piece of presented identity evidence.

For the Biometric Pathway, confirm that the CSP meets the evidence ownership verification requirements associated with the identity proofing type.

Approved methods for verifying FAIR, STRONG, and SUPERIOR evidence for use in the IAL2 Biometric Pathway include:

(a) 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.

(b) Using automated means to compare a biometric characteristic other than a facial image stored on the identity evidence or in records associated with the evidence to a live sample provided by the applicant.

For Remote Attended identity proofing, during the video session, the applicant SHALL remain in view of the proofing agent during each step of the proofing process.

For remote attended video sessions, confirm the CSP requires that the applicant is visible to the proofing agent for each step of the identity proofing process.

For Remote Attended identity proofing, the video quality SHALL be sufficient to support the necessary steps in the validation and verification processes, such as inspecting evidence and comparing the applicant to the evidence.

For remote attended video sessions, confirm the video quality is sufficient to support the needs of the identity proofing process.

For Remote Attended identity proofing, proofing agents SHALL be trained to identify signs of manipulation, coercion, or social engineering occurring during the session.

Confirm the CSP trains its agents to identify signs that an applicant has been coerced or manipulated into participating in the identity proofing process.

For Remote Attended identity proofing, if the CSP records a video session, the following additional requirements apply:

(a) The CSP SHALL notify the applicant of the recording prior to initiating a recorded session.

(b) The CSP SHALL gain consent from the applicant prior to initiating a recorded session.

(c) The CSP SHALL publish their retention schedule and deletion processes for all video records.

If the CSP records remote attended video identity proofing sessions, confirm that the specified requirements are met.

CSPs MAY record and maintain video sessions for fraud prevention and prosecution purposes pursuant to a privacy risk assessment, as defined in Sec. 3.3.1.

For Remote Attended identity proofing, the CSP SHALL implement injection protection and modified media controls, as defined in Sec. 3.14.

Confirm that the CSP employs injection protection and controls against modified media.

For Remote Attended identity proofing, the CSP SHALL provide proofing agents with a method or mechanism to flag events for potential fraud.

Confirm the CSP provides its proofing agents with a mechanism to flag potential fraud.

For On-site Attended identity proofing, the CSP SHALL provide a physical setting in which on-site identity proofing sessions are conducted.

Confirm the CSP provides physical location in for on-site attended identity proofing.

For On-site Attended identity proofing, all devices SHALL be protected by appropriate baseline security features comparable to FISMA moderate controls, including malware protection, administrator-specific access controls, and software update processes.

Confirm that the CSP employs security controls comparable to FISMA moderate or higher for all equipment used for on-site attended identity proofing.

For On-site Attended identity proofing, CSP proofing agents SHALL be trained to identify signs of manipulation, coercion, or social engineering occurring during the on-site session.

Confirm the CSP trains its agents to identify signs that an applicant has been coerced or manipulated into participating in the identity proofing process.

For On-site Attended identity proofing, if the CSP records a video session, the following additional requirements apply:

(a) The CSP SHALL notify the applicant of the recording prior to initiating a recorded session.

(b) The CSP SHALL gain consent from the applicant prior to initiating a recorded session.

(c) The CSP SHALL publish their retention schedule and deletion processes for all video records.

If the CSP records on-site attended video identity proofing sessions, confirm that the specified requirements are met.

CSPs MAY record and maintain video sessions for fraud prevention and prosecution purposes pursuant to a privacy risk assessment, as defined in Sec. 3.3.1.

For On-site Attended identity proofing, the CSP SHALL provide proofing agents with a method or mechanism to covertly flag events for potential fraud.

Confirm the CSP provides its proofing agents with a mechanism to flag potential fraud.

For On-site Unattended identity proofing, all devices SHALL be safeguarded from tampering through observation by CSP representatives and/or physical and digital tamper prevention features.

Confirm that the CSP safeguards all devices and equipment used for on-site unattended identity proofing at IAL2 are safeguarded from tampering.

For On-site Unattended identity proofing, all devices SHALL be protected by appropriate baseline security features comparable to FISMA moderate controls, including malware protection, administrator-specific access controls, and software update processes.

Confirm that the CSP employs security controls comparable to FISMA moderate or higher for all equipment used for on-site attended identity proofing.

For On-site Unattended identity proofing, all devices SHALL be inspected periodically by trained technicians to deter tampering, modification, or damage.

Confirm that the CSP has a policy for ensuring that all equipment used for on-site attended identity proofing is periodically inspected by technicians who are trained to detect tampering, modification, and damage.

For On-site Unattended identity proofing, if the CSP records a video session, the following additional requirements apply:

(a) The CSP SHALL notify the applicant of the recording prior to initiating a recorded session.

(b) The CSP SHALL gain consent from the applicant prior to initiating a recorded session.

(c) The CSP SHALL publish their retention schedule and deletion processes for all video records.

If the CSP records remote attended video identity proofing sessions, confirm that the specified requirements are met.

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.

Confirm that the CSP sends notifications of proofing to validated addresses for applicants after they have successfully complete identity proofing.

CSPs SHOULD send the notification of proofing to the applicant's postal address. Note to assessors: Notifications can be delivered to test accounts and addresses as appropriate based on the capabilities of the assessor or the testing environment available to them and any privacy restrictions on the use of legitimate addresses.

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

(a) 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].

(b) Distribution of a physical authenticator to a validated address.

(c) Distribution or on-site enrollment of an authenticator.

Confirm that the CSP provides the ability for an applicant to bind an authenticator using one of the specified methods.

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:

(a) Return of a continuation code.

(b) Comparison against a biometric collected at the time of proofing.

For authenticators that are bound outside of a single, protection session, confirm that the CSP validates the presence of the intended subscriber through using one of the specified methods.

IAL3 identity proofing SHALL only be delivered as on-site attended.

Confirm that the CSP only offers on-site attended (Collocated Agent or Kiosk-based) identity proofing for IAL3.

The proofing agent MAY be co-located with the applicant or attend the identity proofing session via a CSP-controlled kiosk or device.

For identity proofing at IAL3, the CSP SHALL collect: one piece of FAIR evidence and one piece of STRONG evidence; OR, two pieces of STRONG evidence; OR one piece of SUPERIOR evidence.

Confirm that the CSP collects the specified evidence for identity proofing at IAL .

The CSP SHALL collect all core attributes, including at least one government identifier.

Confirm that the CSP collects all core attributes, including at least one government identifier.

Validated evidence is the preferred source of identity attributes. If the presented identity evidence does not provide all of the attributes that a CSP considers to be core attributes, the CSP MAY collect attributes that are self asserted by the applicant.

Each piece of FAIR or STRONG evidence that is presented SHALL be validated using one of the following techniques:

(a) Confirming the authenticity of the digital evidence by interrogating the digital security features (e.g., signatures on assertions or data).

(b) Confirming the authenticity of the physical evidence using automated scanning technology that can detect physical security features.

(c) 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).

Confirm that the CSP validates each piece of FAIR or STRONG evidence using the one of the techniques provided in item #1 of Sec. 4.3.4.

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.

Confirm that the CSP validates each piece of presented SUPERIOR evidence through the cryptographic verification of the evidence contents and the issuing source.

The CSP SHALL verify the applicant's ownership of the strongest piece of evidence (STRONG or SUPERIOR) by one of the following methods:

(a) 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.

(b) Comparing the applicant's facial image to the facial portrait on the presented evidence via an automated comparison.

(c) 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.

(d) 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.

Confirm that the CSP verifies the applicant's ownership of the strongest piece of evidence by one of the methods provided in Sec 4.3.6.

For on-site attended identity proofing with collocated agents, the CSP SHALL provide a secure, physical setting in which on-site identity proofing sessions are conducted.

Confirm that the CSP provides a secure, physical setting for on-site attended identity proofing sessions with collocated agents.

For on-site attended identity proofing with collocated agents, the CSP SHALL provide sensors and capture devices for the collection of biometrics from the applicant.

Confirm that the workstations the CSP employs for on-site identity proofing at IAL3 include devices for the secure collection of biometric samples.

For on-site attended identity proofing with collocated agents, the CSP SHALL have the proofing agent view the source of the collected biometric for the presence of any non-natural materials (e.g., putty, glue).

Confirm that the CSP requires its IAL3 proofing agents to view the source of the biometric (applicant's face, fingers, etc.) for the presence of any non-natural materials.

For on-site attended identity proofing with collocated agents, the CSP SHALL have the proofing agent collect the biometric samples in such a way that ensures the sample was collected from the applicant and no other source.

Confirm that the CSP employs practices and mechanisms that ensure that all biometric samples are collected from the intended applicant.

For on-site attended identity proofing with collocated agents, the CSP SHALL ensure that all information systems and technology leveraged by proofing agents and trusted referees are protected consistent with at least FISMA moderate or comparable levels of controls, including physical controls for the proofing facility.

Confirm that the CSP employs security controls comparable to FISMA moderate or higher for all information systems and equipment used for on-site attended identity proofing with collocated agents.

For on-site attended identity proofing with collocated agents, CSP proofing agents SHALL be trained to identify signs of manipulation, coercion, or social engineering occurring during the on-site session.

Confirm the CSP trains its agents to identify signs that an applicant has been coerced or manipulated into participating in the identity proofing process.

For on-site attended identity proofing with collocated agents, if the CSP records a session, the following additional requirements apply:

(a) The CSP SHALL notify the applicant of the recording prior to initiating a recorded session.

(b) The CSP SHALL gain consent from the applicant prior to initiating a recorded session.

(c) The CSP SHALL publish their retention schedule and deletion processes for all video records.

If the CSP records video sessions of on-site attended identity proofing with collocated agents at IAL3, confirm that the requirements specified in Sec. 4.3.7 #7 are met.

CSPs MAY record and maintain video sessions for fraud prevention and prosecution purposes pursuant to a privacy risk assessment, as defined in Sec. 3.3.1.

For on-site attended identity proofing with collocated agents, the CSP SHALL provide proofing agents with a method or mechanism to discretely flag events or actions as potential fraud.

Confirm the CSP provides its collocated proofing agents with a mechanism to flag potential fraud.

For kiosk-based on-site attended identity proofing, the CSP SHALL monitor the entire identity proofing session through a high-resolution video transmission with the applicant.

Confirm that all workstations and kiosks employed by the CSP for kiosk-based on-site attended identity proofing at IAL3 include video cameras that support high-resolution video transmission.

For kiosk-based on-site attended identity proofing, the CSP SHALL have a live proofing agent participate remotely with the applicant for the evidence collection, evidence validation, and verification steps of the identity proofing process.

Confirm that the CSP's proofing agents participate remotely in the evidence collection, evidence validation, and identity verification steps of kiosk-based on-site attended identity proofing at IAL3.

For kiosk-based on-site attended identity proofing, the CSP SHALL require all actions taken by the applicant during the evidence collection, evidence validation, and verification steps to be clearly visible to the remote proofing agent.

Confirm that the CSP designs the workstations used for kiosk-based on-site attended identity proofing at IAL3 so that all specified actions taken by the applicants are clearly visible to proofing agents who are participating remotely.

For kiosk-based on-site attended identity proofing, the CSP SHALL require that all digital validation and verification of evidence be performed by integrated scanners and sensors.

Confirm that the CSP's kiosk-based identity proofing stations employ integrated scanners and sensors.

Scanners and sensors that are built into the

For kiosk-based on-site attended identity proofing, all devices used to support interaction between the proofing agent and the applicant SHALL be safeguarded from tampering through observation by CSP representatives or monitoring devices (e.g., cameras) and through physical and digital tamper prevention features.

Confirm that the CSP employs mechanisms to safeguard the equipment and devices used for kiosk-based on-site attended identity proofing from tampering.

For kiosk-based on-site attended identity proofing, all devices used to support interaction between the proofing agent and the applicant SHALL be protected by appropriate baseline security features that are comparable to at least FISMA moderate controls, including malware protection, administrator-specific access controls, and software update processes.

Confirm that the CSP employs security controls comparable to FISMA moderate or higher for all information systems and equipment used for kiosk-based on-site attended identity proofing.

For kiosk-based on-site attended identity proofing, all devices used to support interaction between the proofing agent and the applicant SHALL be inspected periodically by trained technicians to deter tampering, modification, or damage.

Confirm that the CSP ensures that the devices and stations used for kiosk-based on-site attended identity proofing are inspected periodically by trained technicians.

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.

Confirm that the CSP sends notifications of proofing to validated addresses for applicants after they have successfully complete identity proofing.

CSPs SHOULD send the notification of proofing to the applicant's postal address. Note to assessors: Notifications can be delivered to test accounts and addresses as appropriate based on the capabilities of the assessor or the testing environment available.

The CSP SHALL distribute or enroll the subscriber's initial authenticator during an on-site attended interaction with a proofing agent.

Confirm that the CSP distributes and/or enrolls the subscriber's initial authenticator during an on-site attended session 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.

For initial authenticators that are distributed or enrolled outside a single authenticated protected session with the subscriber, confirm that the CSP compares a biometric sample collected from the subscriber to the one collected at the time of proofing prior to registration of the authenticator.

The CSP 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.

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.

Confirm that the CSP establishes and maintains subscriber accounts for all its active subscribers.

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.

Confirm that the CSP assigns 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;* 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; all authenticators currently bound to the subscriber account, whether registered at enrollment or subsequent to enrollment; and attributes that were validated during the identity proofing process or in subsequent transactions to support RP access.

Confirm that CSP's subscriber accounts include all the specified information.

• Required details about the identity proofing steps completed for the subscriber include:

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

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

Confirm that the CSP provides subscribers with the ability to access their subscriber accounts.

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.

Confirm that the CSP requires subscribers to authenticate to their accounts using registered authenticators and AAL2 or AAL3 processes.

The CSP SHALL provide the capability for a subscriber to request that information be updated in their subscriber account.

Confirm that the CSP provides the ability for subscribers to request updates to the information contained in their accounts.

With the exception of physical addresses, the CSP SHALL validate any changes to core attribute information maintained in the subscriber account.

Confirm that the CSP validates any updated core attribute information maintained in a subscriber's account, with the exception of physical address.

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

Confirm that the CSP notifies its subscribers anytime information in their subscriber accounts changes.

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

Confirm that the CSP provides a mechanism for subscribers to report suspected or confirmed incidents of fraud associated with their accounts.

The CSP SHALL promptly suspend or terminate the subscriber account when [any of events listed in Sec. 5.4 occurs].

Confirm that the CSP suspends or terminates subscriber accounts when any of the specified conditions occurs.

The CSP SHALL notify the subscriber if their account has been suspended or terminated.

Confirm that the CSP notifies subscribers if their subscriber 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.

Confirm that the CSP's account suspension or termination notices include sufficient details about the action and options for redress in the case of 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).

Confirm that the CSP has a documented records retention and disposal policy, and that it deletes all personal information upon subscriber account determination in accordance with this policy.

In the event of a data breach of CSP records, the CSP SHALL provide notification to subscribers whose personal information may have been exposed to unauthorized access.

Confirm that the CSP has a documented policy and process for data breach notifications.

Such notification SHALL include information about the breach and actions for subscribers to take to recover or maintain access to their accounts and to protect against any unauthorized disclosure of their personal information.

Confirm that the CSP's data breach notifications include, at a minimum, information about the breach and any actions the subscriber needs to take with regard to their subscriber account.

The CSP SHALL send such notifications as expeditiously as possible to the subscribers' validated address.

Confirm that the CSP sends its data breach notifications as soon as reasonably possible, and that such notifications are sent to validated addresses for its subscribers.

The CSP SHALL develop and document their process for reviewing and assessing subscribers with multiple accounts to identify possible fraud.

Confirm that the CSP has a policy and process for assessing fraud associated with multiple accounts for a single subscriber.

Some CSPs need to support a single user's ability to interact with the CSP while fulfilling different roles or personas. 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).

The CSP SHALL maintain a mapping of all accounts associated with a unique government identifier or common core attributes.

Confirm the CSP has a mechanism for tracking all subscriber accounts associated with an individual.

The CSP SHALL provide individuals with visibility into the full list of subscriber accounts associated with their identity.

Confirm that the CSP provides a mechanism for subscribers to view a list of all subscriber accounts associated with their identity.

To satisfy the requirements of a given AAL and be recognized as a subscriber, a claimant SHALL authenticate to an RP (or IdP, as described in [SP800-63C]) with a process whose strength is equal to or greater than the requirements at that level.

Authentication requirements meet the requirements of assessed AALs.

Federal agencies SHALL select a minimum of AAL2 when personal information is made available online.

Comply with Section 3 of Executive Order 13681 requiring multifactor authentication

Applies to federal agencies only.

CSPs or verifiers SHALL assess their use of indicators of potential fraud for efficacy and to identify and mitigate potential negative impacts on their user populations.

Minimize fraud and potential negative impacts on authentication where possible.

CSPs or verifiers SHALL include fraud indicators in the authentication privacy risk assessment.

Minimize potential privacy impacts stemming from use of fraud indicators.

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

(a) Password (Sec. 3.1.1): A memorizable secret typically chosen by the subscriber.

(b) 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.

(c) Out-of-band device (Sec. 3.1.3): A secret sent or received through a separate communication channel with the subscriber.

(d) Single-factor one-time password (OTP) (Sec. 3.1.4): A one-time secret obtained from a device or application held by the subscriber.

(e) 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.

(f) 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.

(g) 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.

Identify acceptable authenticator types at AAL1.

Authenticators used at AAL1 SHALL use approved cryptography.

Use secure cryptographic algorithms.

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

Protect the exchange of authenticator information between the verifier and the claimant.

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.

Use validated cryptographic modules and components.

Applies to federal agencies and those acting on their behalf (e.g., contractors) only.

Periodic reauthentication of subscriber sessions SHALL be performed, as described in Sec. 5.2.

Mitigate theft of session secrets, session hijacking, and unauthorized use of open session.

A definite reauthentication overall timeout SHALL be established, which SHOULD be no more than 30 days at AAL1.

Mitigate theft of session secrets, session hijacking, and unauthorized use of open session.

At AAL2, authentication SHALL use either a multi-factor authenticator (MFA) or a combination of two separate authentication factors.

Enforce MFA at AAL2.

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:

(a) Look-up secret (Sec. 3.1.2)

(b) Out-of-band device (Sec. 3.1.3)

(c) Single-factor OTP (Sec. 3.1.4)

(d) Single-factor cryptographic authentication (Sec. 3.1.6)

Enforce MFA at AAL2.

Applies when multiple authenticators are used to achieve AAL2.

Authenticators used at AAL2 SHALL use approved cryptography.

Use secure cryptographic algorithms.

Cryptographic authenticators procured by federal agencies SHALL be validated to meet the requirements of [FIPS140] Level 1.

Authenticators procured by or on behalf of government agencies use validated cryptographic modules and components.

Applies to authenticators procured by federal agencies only.

At least one authenticator used at AAL2 SHALL be replay-resistant, as described in Sec. 3.2.7.

Prevent attackers from reusing stolen or observed authentication data to hijack accounts.

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

Determine that the communication channel meets the requirements of an authenticated protected channel as defined in SP 800-63B-4 Appendix D.

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 operated by or on behalf of government agencies are required to be validated to meet FIPS 140 requirements. The FIPS 140 requirements generally apply to cryptographic modules (both hardware and software).

Applies to federal agencies and those acting on their behalf (e.g., contractors) only.

Verifiers SHALL offer at least one phishing-resistant authentication option at AAL2, as described in Sec. 3.2.5.

Ensure that phishing-resistant authentication methods are available to subscribers who wish to use them.

Federal agencies SHALL require their staff, contractors, and partners to use phishing-resistant authentication to access federal information systems.

Ensure phishing resistance for applications used by federal staff, contractors, and partners.

Applies to federal agencies only.

Periodic reauthentication of subscriber sessions SHALL be performed, as described in Sec. 5.2.

Determine that appropriate expiration of sessions occurs to mitigate theft of session secrets or use of a forgotten session.

AAL3 authentication SHALL require an authenticator combination consisting of either multi-factor cryptographic authentication (Sec. 3.1.7); or single-factor cryptographic authentication (Sec. 3.1.6) used in conjunction with either a password (Sec. 3.1.1) or a biometric comparison.

Require use of highest security authenticators at AAL3.

Authenticators used at AAL3 SHALL use approved cryptography.

Determine that only secure, well-vetted cryptographic algorithms are being used.

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

Determine that the communication channel meets the requirements of an authenticated protected channel as defined in SP 800-63B-4 Appendix D.

The cryptographic authenticator used at AAL3 SHALL have a non-exportable private key.

Require use of high-security authenticators at AAL3.

The cryptographic authenticator used at AAL3 SHALL provide phishing resistance, as described in Sec. 3.2.5.

Require use of phishing resistant authenticators at AAL3.

The cryptographic authentication protocol SHALL be replay-resistant.

Ensure that the authentication transaction cannot be replayed by an attacker.

All authentication and reauthentication processes at AAL3 SHALL demonstrate authentication intent from at least one authenticator, as described in Sec. 3.2.8.

Ensure that authentication is actively requested, and not accidental.

Cryptographic authenticators used at AAL3 SHALL use public-key cryptography to protect the authentication secrets from compromise of the verifier.

Avoid the use of shared authentication secrets that could be compromised by an attacker.

Single-factor and multi-factor authenticators used at AAL3 SHALL be validated to meet the requirements of [FIPS140] Level 1 or higher overall.

Cryptographic authenticators at AAL3 are required to be validated to meet FIPS 140 requirements. The FIPS 140 requirements generally apply to cryptographic modules (both hardware and software).

Syncable authenticators SHALL NOT be used at AAL3.

Ensure that syncable authenticators, which have exportable authentication keys, are not used.

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

Verifiers operated by or on behalf of government agencies are required to be validated to meet FIPS 140 requirements. The FIPS 140 requirements generally apply to cryptographic modules (both hardware and software).

Periodic reauthentication of subscriber sessions SHALL be performed, as described in Sec. 5.2.

Determine that appropriate expiration of sessions occurs to mitigate theft of session secrets or use of a forgotten session.

At AAL3, the overall timeout for reauthentication SHALL be no more than 12 hours.

Establish upper bound on session lifetime.

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.

Determine compliance with relevant overall security controls.

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.

Determine compliance with records retention policy requirements.

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.

Verify justification for records retention not covered by mandatory requirements.

Non-mandatory records retention.

The verifier SHALL employ appropriately tailored privacy controls defined in [SP800-53] or an equivalent industry standard.

Determine compliance with relevant overall privacy requirements.

If CSPs or IdPs process attributes for purposes other than identity services (i.e., identity proofing, authentication, or attribute assertions), related fraud mitigation, or compliance with laws or legal processes, they SHALL implement measures to maintain predictability and manageability commensurate with the privacy risks that arise from the additional processing.

Determine compliance with relevant privacy requirements for supplemental services.

Applies when there is non-identity use of identity attributes.

When CSPs or IdPs use consent measures, they SHALL NOT make consent for the additional processing a condition of the identity service.

Ensure that consent measures are voluntary.

Applies when consent is requested from subscriber.

The agency SHALL consult with their Senior Agency Official for Privacy (SAOP) and conduct an analysis to determine whether the collection of personal information to issue or maintain authenticators triggers the requirements of the Privacy Act of 1974 [Privacy Act] (see Sec. 7.4).

Determine when Privacy Act requirements are triggered.

Applies to federal agencies and others acting on their behalf.

The agency SHALL publish a System of Records Notice (SORN) to cover such collections, as applicable.

Determine that a SORN is published when required.

Applies to federal agencies only.

The agency SHALL consult with its SAOP and conduct an analysis to determine whether the collection of personal information to issue or maintain authenticators triggers the requirements of the E-Government Act of 2002 [E-Gov].

Determine when E-Government Act requirements are triggered.

Applies to federal agencies only.

The agency SHALL publish a Privacy Impact Assessment (PIA) to cover such collection, as applicable.

Determine that a PIA is published when required.

Applies to federal agencies and others providing services to federal agencies.

The verifier and associated CSP or IdP SHALL provide mechanisms for the redress of subscriber complaints and problems that arise from subscriber authentication processes, as described in Sec. 5.6 of [SP800-63].

Determine that useful redress for authentication problems is provided.

These mechanisms SHALL be easy for subscribers to find and use.

Ensure that redress mechanisms are usable by the population of subscribers.

The CSP or IdP SHALL assess the mechanisms for efficacy in resolving complaints or problems.

Ensure that redress mechanisms are sufficient to resolve expected authentication problems.

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

Establish acceptable methods of password creation (e.g., no default passwords).

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.

Prohibit use of passwords expected to be commonly chosen.

Other composition requirements for passwords SHALL NOT be imposed.

Prohibit composition rules (e.g., requirement for specific character types).

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.

Require passwords to be long enough to provide baseline security.

Verifiers and CSPs SHOULD accept Unicode [ISO/IEC 10646] characters in passwords. Each Unicode code point SHALL be counted as a single character when evaluating password length.

Allow use of characters memorable to the subscriber, even if they use a language not represented by ASCII.

Verifiers and CSPs SHALL NOT impose other composition rules (e.g., requiring mixtures of different character types) for passwords.

Prohibit composition rules (e.g., requirement for specific character types)

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.

Prohibit password rotation, which has been shown to cause selection of weaker passwords.

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.

Prohibit use of password hints, which greatly weaken security.

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.

Prohibit use of KBA, which greatly weakens security.

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

Require use of the entire password for authentication to maximize the security benefit of the whole password.

When processing a request to establish or change a password, verifiers SHALL compare the prospective secret against a blocklist that contains known commonly used, expected, or compromised passwords.

Require use of a blocklist to prevent selection of excessively weak passwords.

The entire password SHALL be subject to comparison, not substrings or words that might be contained therein.

Ensure that the entire password is verified so that the full security benefit of long passwords is realized.

If the chosen password is found on the blocklist, the CSP SHALL require the subscriber to select a different secret and SHALL provide the reason for rejection.

Require selection of a different password if a weak one is chosen.

Verifiers SHALL offer guidance to the subscriber to help the subscriber choose a strong password. This is particularly important following the rejection of a password on the blocklist as it discourages trivial modifications of listed weak passwords [Blocklists].

Require coaching of the subscriber on selection of better passwords if a weak one is initially chosen.

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

Strengthen verifier against online password guessing attacks.

Verifiers SHALL allow the use of password managers and autofill functionality.

Allow subscriber to use a password manager, which aids in the use of strong and unguessable passwords.

Verifiers and CSPs SHALL use approved encryption and an authenticated protected channel when requesting passwords.

Ensure that the communication channel to the verifier is secure against eavesdropping.

Verifiers SHALL store passwords in a form that is resistant to offline attacks.

Require strong storage to protect against offline attacks.

Passwords SHALL be salted and hashed using a suitable password hashing scheme.

At a minimum, require salting and hashing of passwords as protection against offline attacks should the verifier be breached.

The salt SHALL be at least 32 bits in length and chosen to minimize salt value collisions among stored hashes (i.e., to prevent multiple subscriber accounts from having the same hashed password).

Require use of a salt sufficient to ensure that two subscribers with the same password do not hash to the same value in the verifier.

Both the salt value and the resulting hash SHALL be stored for each password.

Describes the use of a salt.

If used, this key value SHALL be generated by an approved random bit generator, as described in Sec. 3.2.1.2.

For keyed hashing, require appropriate selection of the key.

Applies when keyed hashing is used.

The secret key value SHALL be stored separately from the hashed passwords.

Require separate storage for a keyed hash key so it is not also breached if the hashed passwords are.

Applies when keyed hashing is used.

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.

Require selection of sufficiently random look-up secrets

CSPs that create look-up secret authenticators 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).

Ensure that eavesdroppers and other intermediaries do not have access to look-up secrets being delivered to the subscriber.

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.

Ensure that online delivery of look-up secrets is sufficiently secure.

Applies when look-up secrets are delivered online.

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.

Verify that look-up secrets are sufficiently long to provide adequate security.

Verifiers of look-up secrets SHALL prompt the claimant for a secret from their authenticator.

Verify appropriate authentication flow.

A secret from a look-up secret authenticator SHALL be used successfully only once.

Ensure that look-up secrets are replay resistant.

Verifiers SHALL store look-up secrets in a form that is resistant to offline attacks.

Require strong storage to protect against offline attacks.

All lookup secrets SHALL be stored in a hashed form using an approved hashing function.

Require use of a hashing function known to be sufficiently secure.

Look-up secrets SHALL be at least six decimal digits (or equivalent) in length, as specified in Sec. 3.1.2.1.

Verify that look-up secrets are sufficiently long to provide adequate security.

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.

Require salting for look-up secrets that are at risk of collision with other secrets.

Applies to look-up secrets shorter than 112 bits.

The salt value SHALL be at least 32 bits in length and arbitrarily chosen to minimize salt value collisions among stored hashes.

Require use of a salt sufficient to ensure that two subscribers with the same look-up secrets do not hash to the same value in the verifier.

Applies to look-up secrets shorter than 112 bits.

Both the salt value and the resulting hash SHALL be stored for each lookup secret.

Describes the use of a salt.

Applies to look-up secrets shorter than 112 bits.

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.

Strengthen verifier against online look-up secret guessing attacks.

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

Ensure that online delivery of look-up secrets is sufficiently secure.

The out-of-band authenticator SHALL establish a separate channel with the verifier to retrieve the out-of-band secret or authentication request.

Verify that a separate channel is used to communicate with the verifier.

Communication over the secondary channel SHALL use approved encryption unless sent via the public switched telephone network (PSTN).

Establish that delivery of the out-of-band secret is delivered securely.

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

(a) Access using only a password.

(b) Interception in transit or at intermediate mail servers.

(c) Rerouting attacks, such as those caused by Domain Name System (DNS) spoofing.

Prohibit the use of email for delivery of out-of-band secrets because of multiple security vulnerabilities.

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

(a) 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.

(b) Authenticate to a public mobile telephone network using a SIM card or equivalent secret that uniquely identifies the subscriber. This method SHALL only be used if a secret is sent from the verifier to the out-of-band device via the PSTN (i.e., SMS or voice) or an encrypted instant messaging service; use a wired connection to the PSTN that the verifier can call and dictate the out-of-band secret. For the purposes of this definition, "wired connection" includes services such as cable providers that offer PSTN services through other wired media and fiber via analog telephone adapters.

Confirm that out-of-band secrets are delivered only to authenticated devices.

If the out-of-band authenticator requests approval over the secondary communication channel rather than by presenting a secret that the claimant transfers to the primary communication channel, it SHALL accept a transfer of the secret from the primary channel and send it to the verifier over the secondary channel to associate the approval with the authentication transaction.

Ensure that authentication approval over the secondary channel requires transfer of a secret from the primary channel to avoid approval fatigue attacks.

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.

Ensure that, should the verifier be compromised, any active out-of-band secrets are protected from disclosure.

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

(a) 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.

(b) 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.

Ensure that one of the approved authentication flows involving the transfer of a secret from one device or application to another is used.

In all cases, the authentication SHALL be considered invalid unless completed within 10 minutes.

Make sure that out-of-band secrets are only valid for the short term.

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.

Verify that out-of-band secrets are replay resistant.

The verifier SHALL generate random authentication secrets that are at least six decimal digits (or equivalent) in length.

Verify that out-of-band secrets are sufficiently long to provide adequate security.

The verifier SHALL generate random authentication secrets using an approved random bit generator as described in Sec. 3.2.12.

Require selection of sufficiently random look-up secrets.

If the authentication secret is less than 64 bits long, the verifier SHALL implement a rate-limiting mechanism that effectively limits the total number of consecutive failed authentication attempts that can be made on the subscriber account as described in Sec. 3.2.2.

Ensure that out-of-band authentication is sufficiently protected against online guessing attacks.

Generating a new authentication secret SHALL NOT reset the failed authentication count.

Ensure that obtaining a new out-of-band secret does not bypass the rate limiting mechanism.

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.

Invoke restricted authenticator provisions.

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.

Defend against attackers who attempt to change the pre-registered telephone number.

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.

Ensure that subscribers understand the risks associated with PSTN out-of-band authentication.

Each use of the authenticator SHALL require the presentation of the activation factor.

Ensure that a previously activated authenticator cannot be coopted by an attacker.

Authenticator activation secrets SHALL meet the requirements of Sec. 3.2.10.

Invoke requirements for activation secrets.

A biometric activation factor SHALL meet the requirements of Sec. 3.2.3, including limits on the number of consecutive authentication failures.

Invoke requirements for biometric authentication factors.

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.

Ensure that the activation factor cannot be used or extracted following an authentication operation.

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

Ensure that the key used to generate the OTP is of sufficient size to be secure.

The nonce SHALL be of sufficient length to ensure that it is unique for each operation of the authenticator over its lifetime.

Ensure that the nonce is large enough that the OTP sequence doesn't repeat.

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.

Ensure that the nonce of a time-based OTP changes frequently enough.

Applies to time-based OTP authenticators.

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.

Protect against attacks on verifier.

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.

Determine that only secure, well-vetted cryptographic algorithms are being used.

The verifier SHALL use approved encryption and an authenticated protected channel when collecting the OTP.

Determine that only secure, well-vetted cryptographic algorithms and protocols are being used.

Verifiers SHALL accept a given OTP only once while it is valid to provide replay resistance, as described in Sec. 3.2.7.

Ensure that OTP use is replay resistant.

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.

Ensure that OTP will not fail prematurely due to clock drift.

Applies to time-based OTP authenticators.

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.

Protect against OTP guessing attacks

Applies when authenticator output if less than 64 bits in length.

Each use of the authenticator SHALL require the input of the activation factor.

Ensure that all use of the authenticator is protected by the activation factor.

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

Ensure that the key used to generate the OTP is of sufficient size to be secure.

The nonce SHALL be of sufficient length to ensure that it is unique for each operation of the authenticator over its lifetime.

Ensure that the nonce is large enough that the OTP sequence doesn't repeat.

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.

Ensure that the nonce of a time-based OTP changes frequently enough.

Applies to time-based OTP authenticators.

Authenticator activation secrets SHALL meet the requirements of Sec. 3.2.10.

Invoke requirements for activation secrets.

Authenticator uses activation secrets.

A biometric activation factor SHALL meet the requirements of Sec. 3.2.3, including limits on the number of consecutive authentication failures.

Invoke requirements for biometric authentication factors.

Authenticator uses biometric activation.

The unencrypted key and 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 immediately after an OTP has been generated.

Ensure that the activation factor cannot be used or extracted following an authentication operation.

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.

Protect against attacks on verifier.

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.

Determine that only secure, well-vetted cryptographic algorithms are being used.

The verifier SHALL use approved encryption and an authenticated protected channel when collecting the OTP.

Determine that only secure, well-vetted cryptographic algorithms and protocols are being used.

Verifiers SHALL accept a given OTP only once while it is valid to provide replay resistance, as described in Sec. 3.2.7.

Ensure that OTP use is replay resistant.

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.

Ensure that OTP will not fail prematurely due to clock drift.

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.

Protect against OTP guessing attacks

Single-factor cryptographic authenticators used at AAL3 SHALL use public-key cryptography to protect the authentication secrets from compromise of the verifier.

Avoid the use of shared authentication secrets that could be compromised by an attacker.

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.

Protect against attacks on authenticator.

Applies to exportable authentication keys.

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

Protect against attacks on authenticator.

Applies to non-exportable authentication keys.

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

Ensure integrity of endpoint-authenticator connection.

Applies to non-embedded cryptographic authenticators.

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.

Protect against attacks on verifier.

Applies when symmetric authentication keys are used.

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

Ensure that the authentication key is of sufficient size to be secure.

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

Provide strong protection against replay attacks.

The verification operation SHALL use approved cryptography.

Determine that only secure, well-vetted cryptographic algorithms and protocols are being used.

Multi-factor cryptographic authenticators used at AAL3 SHALL use public-key cryptography to protect the authentication secrets from compromise of the verifier.

Avoid the use of shared authentication secrets that could be compromised by an attacker.

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

Ensure that authenticator enforces use of an activation factor.

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.

Protect against attacks on authenticator.

Applies to non-exportable authentication keys.

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.

Protect against attacks on authenticator.

Applies to exportable authentication keys.

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

Ensure integrity of endpoint-authenticator connection.

Applies to non-embedded cryptographic authenticators.

Each authentication event SHALL require input and verification of the local activation factor.

Ensure that a previously activated authenticator cannot be coopted by an attacker.

Authenticator activation secrets SHALL meet the requirements of Sec. 3.2.10.

Invoke requirements for activation secrets.

Authenticator uses activation secrets.

A biometric activation factor SHALL meet the requirements of Sec. 3.2.3, including limits on the number of consecutive authentication failures.

Invoke requirements for biometric authentication factors.

Authenticator uses biometric activation.

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.

Ensure that the activation factor cannot be used or extracted following an authentication operation.

Requirements for a multi-factor cryptographic verifier are identical to those for a single-factor cryptographic verifier.

Ensure baseline requirements for cryptographic verifiers are met.

If a flag indicating use of an activation factor is present and indicates that an activation factor was not used, the authentication SHALL be treated as single-factor.

Ensure that an activation factor was used if indication was provided.

Access to the private key SHALL require an activation factor.

Ensure that authenticator enforces use of an activation factor.

Authenticator activation secrets SHALL meet the requirements of Sec. 3.2.10.

Invoke requirements for activation secrets.

Authenticator uses activation secrets.

Biometric activation factors SHALL meet the requirements of Sec. 3.2.3, including limits on the number of consecutive authentication failures.

Invoke requirements for biometric authentication factors.

Authenticator uses biometric activation.

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.

Ensure that the activation factor cannot be used or extracted following an authentication operation.

Authentication processes using subscriber-controlled wallets SHALL be used with a federation process as detailed in Sec. 5 of [SP800-63C].

Ensure that subscriber-controlled wallets are used in connection with federation requirements.

Assertions that lack a valid signature from the wallet or an audience restriction SHALL NOT be considered phishing-resistant.

Ensure that wallets satisfy applications requiring phishing resistance.

Assertions SHALL also include sufficient information to determine the nature of the activation method used to activate the wallet.

Ensure that activation information is provided to relying parties.

CSPs SHALL provide subscriber instructions for appropriately protecting the authenticator against theft or loss.

Ensure that subscribers understand their responsibilities for protecting authenticators.

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.

Ensure that subscribers have a meaningful way to report authenticator issues and that appropriate action is taken.

When required by the authenticator type descriptions in Sec. 3.1, the verifier SHALL implement controls to protect against online guessing attacks.

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

Set overall upper limit on consecutive failed authentication attempts.

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.

Address excessive authentication failures involving more than one authenticator.

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.

Ensure that disabled authenticators are treated as unbound to the subscriber account.

If the retry count of an authenticator is reset following a successful authentication, the maximum AAL of the authenticator being reset SHALL not exceed the AAL of the session from which it is being reset.

Prevent AAL escalation due to authenticator retry count reset.

Applies to verifiers that reset the unsuccessful authentication count after successful authentication.

If the subscriber cannot authenticate at the required AAL, the account recovery procedures in Sec. 4.2 SHALL be used.

Require account recovery in the event that authenticator rebinding is unavailable.

Biometrics SHALL only be used as part of multi-factor authentication with a physical authenticator (i.e., "something you have").

Block use of biometric comparison as a single factor or with only a password.

The biometric characteristic SHALL be presented and compared for each authentication operation.

Do not allow biometric characteristics to be cached.

An alternative nonbiometric authentication option SHALL always be provided to the subscriber.

Require alternatives in the event that a biometric characteristic cannot be presented for some reason.

Biometric data SHALL be treated and secured as sensitive personal information.

Ensure that biometric data is sufficiently protected.

The biometric system SHALL operate with an FMR [ISO/IEC2382-37] of one in 10000 or better for all demographic groups.

Ensure biometric comparison is sufficiently secure against false matches.

Demographic categories to be considered SHALL include sex and skin tone when these factors affect biometric performance.

Ensure biometric comparison works for a wide demographic range.

This FMR SHALL be achieved under the conditions of a conformant attack (i.e., zero-effort impostor attempt), as defined in [ISO/IEC30107-1].

Define test conditions for false match rate test.

Biometric performance SHALL be tested in accordance with [ISO/IEC19795-1].

Define test conditions for false match rate test.

The biometric system SHALL be configured with a fixed threshold; it is not feasible to change the threshold for each demographic.

Require consistent match criteria for all demographic groups.

The biometric system SHOULD implement PAD for iris and fingerprint modalities and SHALL implement PAD for facial recognition.

Require PAD for facial recognition to counter deepfakes.

Applies to facial recognition modality.

Biometric comparison based on voice SHALL NOT be used.

Prohibit use of voice recognition due to ease in spoofing.

Applies to voice recognition modality.

The biometric system SHALL allow no more than five consecutive failed authentication attempts or 10 consecutive failed attempts if PAD is implemented and meets the above requirements.

Limit opportunity to spoof biometric comparison.

Once that limit has been reached, the biometric authenticator SHALL impose a delay of at least 30 seconds before each subsequent attempt with an overall limit of no more than 50 consecutive failed authentication attempts or 100 if PAD is implemented due to the mitigation of presentation attacks.