Identity Proofing Requirements

This section is normative.

This section provides requirements for CSPs that operate identity proofing and enrollment services, including requirements for identity proofing at each of the IALs. This section also includes additional requirements for federal agencies, regardless of whether they operate their own identity service or use an external CSP.

Sections 4.1, 4.2, and 4.3 provide the requirements and guidelines for identity proofing at a specific IAL. Section 4.4 includes a summarized list of these requirements by IAL in Table 1.

Identity Service Documentation and Records

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

1. A complete service description, including the particular steps that the CSP follows to identity-proof applicants at each offered assurance level
2. The CSP’s policy for providing notice to applicants about the types of identity proofing processes available, the evidence and attribute collection requirements for the IALs offered by the CSP, the purpose for collecting personal information (see Sec. 3.3.2), and the purposes for collecting, using, and retaining biometrics (see Sec. 3.1.11)
3. The CSP’s policy for ensuring that the identity proofing process concludes in a timely manner once the applicant has met all of the requirements
4. The types of evidence that the CSP accepts and the justification for how the evidence fulfills the strength requirements of the level at which it will be accepted by the CSP
5. The CSP’s policy and process for validating and verifying identity evidence, including training and qualification requirements for personnel who serve in identity proofing roles, as provided in Sec. 2.1.2
6. The specific technologies that the CSP employs for evidence validation and verification
7. The CSP’s policy and processes for supporting applicants who lack sufficient identity evidence for the required IAL (Sec. 3.15) and for addressing identity proofing exceptions and errors
8. The attributes that the CSP considers to be core attributes (Sec. 2.2) and the authoritative and credible sources it uses for validating those attributes (Sec. 2.4.2.4)
9. The CSP’s policy for managing and communicating service changes to RPs, such as changes in data sources, integrated vendors, or biometric algorithms
10. The CSP’s approach to fraud management (see Sec. 3.2), including its policy and process for identifying and remediating suspected or confirmed fraudulent accounts and communicating such information to RPs and affected individuals
11. The CSP’s policy for any conditions that would require reverification of the user (e.g., account recovery, account abandonment, regulatory “recertification” requirements)
12. The CSP’s policy for conducting privacy risk assessments, including the timing of its periodic reviews and specific conditions that will trigger an updated privacy risk assessment (see Sec. 3.3.1)
13. The CSP’s 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 (see Sec. 3.4)
14. The CSP’s 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
15. The CSP’s policy for reporting and updating performance metrics, as described in Sec. 3.5.2 of SP 800-63
16. The CSP’s policy for accessing or removing a subscriber’s account in the event of their death or incapacitation (see Sec. 5)

CSPs SHALL make their documented procedures or practice statements available to RPs that use their identity service. CSPs SHOULD make a summarized version of their documented procedures or practice statements publicly available.

SP 800-63C describes the use of trust agreements to define requirements between an identity provider (IdP), CSP, and RP in a federated relationship. CSP practice statements MAY be included directly in these agreements.

Fraud Management

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

CSP Fraud Management

1. 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.
2. CSPs SHALL conduct a privacy risk assessment of all fraud checks and fraud mitigation technologies prior to implementation.
3. 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.
4. CSPs SHALL analyze all remote proofing communication channels to look for high-risk indicators (e.g., blocklisted proxies and IP addresses).
5. 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.¹
6. CSPs SHALL monitor the performance of their fraud checks and fraud mitigation technologies to ensure continued effectiveness in mitigating fraud risks.
7. CSPs SHALL establish a technical or process-based mechanism to communicate suspected and confirmed fraudulent events to RPs.
8. CSPs SHALL implement a death records check for all identity proofing processes by confirming with a credible, authoritative, or issuing source that the applicant is not deceased. Such checks can aid in preventing synthetic identity fraud, the use of stolen identity information, and exploitation by a close associate or relative.
9. CSPs SHOULD implement the following fraud checks for their identity proofing processes based on their available identity proofing types, selected technologies, evidence, and user base:
   • SIM swap detection: Confirm that the phone number used in the identity proofing process has not been recently ported to a new user or device. Such checks can provide an indication that a phone or device was compromised by a targeted attack.
   • Device or account tenure check: Evaluate the length of time a phone service subscription or other account (e.g., email account) has existed without substantial modifications or changes. Such checks can provide additional confidence in the reliability of a device or piece of evidence used in the identity proofing process.
   • Mailing address check: Determine whether the mailing address is a known virtual Post Office (PO) Box or has other high-risk characteristics.
   • Device fingerprinting: Incorporate device fingerprinting checks to protect against scaled and automated attacks and enrollment duplication. Device fingerprinting is the process of collecting and analyzing the hardware and software characteristics of a device in order to create a unique identifier (i.e., fingerprint) for the device.
   • Transaction analytics: Evaluate anticipated transaction characteristics (e.g., IP addresses, geolocations, transaction velocities) to identify anomalous behaviors or activities that can indicate a higher risk or a potentially fraudulent event. Fraud velocity checks monitor the frequency and pattern of transactions over a specific period of time to identify unusual activity associated with transaction data. Such checks can protect against scaled and automated attacks, as well as indicate whether specific attack patterns are being executed on identity systems.
   • Fraud indicator check: Evaluate records (e.g., reported, confirmed, or historical fraud events) to determine whether there is an elevated risk related to a specific applicant, applicant’s data, or device. Such checks can indicate identity theft or compromise. Where such information is collected, aggregated, or exchanged across commercial platforms and made available for use by RPs and other CSPs, users SHALL be made aware of any privacy implications based on a privacy risk assessment. This also applies to all websites that report user activity to federal RPs.
10. CSPs SHOULD periodically employ independent testing (e.g., red teaming exercises) to validate the effectiveness of their fraud mitigation measures.
11. CSPs SHOULD consider the recency of fraud-related data when factoring such data into fraud prevention capabilities and decisions.
12. 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.
13. Collusion is possible whenever CSP representatives are directly involved in proofing processes or decisions. 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.
14. CSPs SHOULD communicate fraud events in real time to RPs through methods such as shared signaling, as described in Sec. 4.8 of [SP800-63C].
15. CSPs MAY employ KBV as part of its fraud management program.
16. CSPs MAY implement fraud mitigation measures as compensating controls. When this is done, these 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. See Sec. 3.4.4 of [SP800-63] for more information about the 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.

RP Fraud Management

1. RPs SHALL establish a point of contact with whom CSPs can interact and communicate fraud data.
2. 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. Federal agency RPs SHALL implement this consistent with the requirements contained in Sec. 3.7.
3. RPs SHOULD include any requirements for fraud checks and fraud mitigation technologies in trust agreements with their CSPs.
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.
5. 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. The RP SHALL record the CSP’s compensating controls in their own DIAS prior to integration.
6. Pursuant to applicable laws and regulations, RPs SHOULD establish a mechanism to communicate the outcomes of fraud reports and investigations, including both positive and negative results, to CSPs and other partners in order to allow them to improve their own fraud identification, mitigation, and reporting capabilities.
7. RPs SHOULD establish a fraud management program for digital identity management consistent with their mission, regulatory environment, systems, applications, data, and resources.
8. Informed by risks identified in a privacy risk assessment, the RP MAY also request additional attributes beyond what a CSP provides as its core attributes to combat fraud or to support other business processes.

Treatment of Fraud Check Failures

The effectiveness of fraud checks and mitigation technologies will vary based on numerous contributing factors, including the data sources used, the technologies used, and — perhaps most importantly — the applicant population. Therefore, it is critical to have well-structured and documented processes addressing failures that arise from the fraud management measures. The following requirements apply to handling these failures:

1. CSPs SHALL establish and document actions and practices related to each of their fraud checks and provide these actions and practices to RPs.
2. CSPs SHALL establish procedures for redress to allow applicants to resolve issues associated with fraud checks and mitigation technologies. See Sec. 3.6 of [SP800-63] for more information about redress.
3. The CSP SHOULD offer trusted referee services to applicants who fail fraud checks in unattended remote processes. 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.

General Privacy Requirements

The following privacy requirements apply to all CSPs that provide identity services at any IAL.

Privacy Risk Assessment

1. The CSP SHALL conduct and document a privacy risk assessment for the processes used for identity proofing and enrollment.² At a minimum, the privacy risk assessment SHALL assess the risks associated with:
   1. 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
   2. Additional steps that the CSP takes to verify the identity of an applicant beyond the mandatory requirements specified herein
   3. Processing of personal information for purposes outside of the scope of identity proofing and enrollment, except to comply with law or legal processes
   4. The retention schedule for identity records and personal information
   5. Processing non-personal information that could be used to identify a person when aggregated or processed by an algorithm (e.g., AI or ML tools)
   6. Personal information that is processed by a third-party service on behalf of the CSP
2. 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.³ In determining such measures, the CSP SHOULD apply relevant guidance and standards, such as the NIST Privacy Framework [NIST-Privacy] and NIST SP 800-53 [SP800-53].
3. 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.
4. 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.
5. 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 CSPs services and to complete their own privacy risk assessments.
6. The CSP SHALL perform a privacy risk assessment for the processing of any personal information maintained in subscriber accounts (see Sec. 5).

Additional Privacy Protective Measures

1. 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.
2. 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.
3. 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. 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.
4. 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.
5. CSPs SHOULD implement techniques that protect an applicant’s privacy based on the privacy considerations in Sec. 7.

General Customer Experience Requirements

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.

The following requirements apply to all CSPs that provide identity services at any IAL:

1. 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.
2. CSPs SHALL provide RPs with a summary of their customer experience assessments that includes information about common challenges or issues faced by users.
3. Based on the results of its assessment, the CSP SHALL document any measures it takes to mitigate the possible access challenges.
4. 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.
5. The CSP SHALL NOT make applicant participation in these risk assessments mandatory.

General Security Requirements

1. Each online transaction within the identity proofing process, including transactions that involve third parties, SHALL occur over an authenticated protected channel.
2. 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.
3. 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.
4. The CSP SHALL assess the information security and privacy risks associated with operating its identity service, according to the NIST Risk Management Framework [NIST-RMF] or equivalent risk management guidelines. At a minimum, the CSP SHALL apply appropriate controls consistent with the NIST SP 800-53 [SP800-53] moderate baseline, regardless of IAL.
5. The CSP SHALL assess risks associated with its use of third-party services and apply appropriate controls, as provided in the [SP800-161] Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations.

Redress Requirements

1. 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).
2. These redress mechanisms SHALL be easy for applicants to find and use.
3. The CSP SHALL assess the mechanisms for their efficacy in achieving a resolution of complaints or problems.

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

Additional Requirements for Federal Agencies

The following requirements apply to federal agencies, regardless of whether they operate their own identity service or use an external CSP as part of their identity service:

1. 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.
2. 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 [E-Gov] requirements.
3. The agency SHALL publish a System of Records Notice (SORN) to cover such collections, as applicable.⁵
4. The agency SHALL publish a Privacy Impact Assessment (PIA) to cover such collections, as applicable.
5. The agency SHOULD consult with public affairs and communications professionals within their organization to determine whether a communications or public awareness strategy should be developed to accompany the implementation of any new process or update to an existing process, including requirements associated with identity proofing. Such strategies should consider the use of materials that describe how to use the technology associated with the service, a Frequently Asked Questions (FAQs) page, prerequisites to participate in the identity proofing process (e.g., required evidence), or media (e.g., webinars, live or pre-recorded information sessions) to support adoption of the identity service and provide applicants with a mechanism to communicate questions, issues, and feedback.
6. 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.

Requirements for Confirmation Codes

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

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

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

Confirmation codes SHALL be valid for at most:

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

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

Requirements for Continuation Codes

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

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

If continuation codes are used, the following requirements apply:

1. Continuation codes SHOULD be delivered in-session but MAY be delivered out-of-band to a physical mailing address, phone number, or email address.
2. Continuation codes SHALL include at least 64 bits from an approved random bit generator (see Sec. 3.2.12 of [SP800-63B]).
3. The continuation code MAY be presented as numeric or printable ASCII representation for manual entry or as a machine-readable optical label (e.g., QR code).
4. The verification of continuation codes SHALL be subject to throttling requirements, as provided in Sec. 3.2.2 of [SP800-63B].
5. Continuation codes SHALL be stored in hashed form using a Federal Information Processing Standards (FIPS)-approved or NIST-recommended one-way function.
6. Upon its use, the CSP SHALL invalidate the continuation code.

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. This will need to be defined by the CSP based on their processes, technologies, and partnerships.

Requirements for Notifications of Identity Proofing

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

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

1. 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
2. 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
3. SHALL provide clear instructions, including contact information, on actions for the recipient to take if they repudiate their participation in the identity proofing event
4. SHALL provide information about how the organization or CSP protects the security and confidentiality of the information it collects
5. SHALL provide information about any responsibilities that the recipient has as a subscriber of the identity service
6. SHOULD provide instructions on how to access their subscriber account or information about how the subscriber can update the information contained in that account

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

Requirements for the Use of Biometrics

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

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

1. 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.
2. CSPs SHALL obtain explicit informed consent to collect and use biometrics from all applicants.
3. CSPs SHALL store a record of the subscriber’s consent for biometric use and associate it with the subscriber’s account.
4. 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.
5. 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 that do not support biometric deletion requests SHALL publicly document the regulatory, statutory, or risk-based justification for their policy.
6. CSPs SHALL have their biometric recognition and attack detection algorithms periodically tested by independent entities (e.g., accredited laboratories or research institutions) 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.
7. 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. The user base is defined by both the expected users and the devices they are expected to use. When such assessments include real-world users, participation by users SHALL be voluntary.
8. 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
   • False non-match rate: 1:100 or better
9. CSPs MAY use one-to-many (1:N) identification in support of resolution or deduplication, pursuant to a privacy risk assessment. In 1:N scenarios, CSPs SHALL meet a minimum performance threshold for false positive identification of 1:1,000 or better.
10. 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. Tests that demonstrate this requirement SHALL employ a gallery no smaller than 90 % of the current or intended operational size (N).
11. 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 (e.g., twins submitting face photographs for different accounts with the same CSP).
12. 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. For example, if the measured false non-match 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. Demographic categories to be considered SHALL include sex, age, and skin tone when these factors affect biometric performance.
13. All biometric performance tests SHALL be conformant to ISO/IEC 19795-1:2021 and ISO/IEC 19795-10:2024, including demographics testing.
14. CSPs SHALL make the results of their biometric algorithm performance and biometric system operational test results 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.

\clearpage

The following requirements apply to CSPs that collect biometric characteristics from applicants:

1. CSP SHALL collect biometric characteristics in a way that provides reasonable assurance that the biometric characteristic is collected from the applicant and not another subject.
2. 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. All biometric presentation attack detection tests SHALL be conformant to ISO/IEC 30107-3:2023.
3. 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.

Requirements for Visual Facial Image Comparison

Proofing agents and trusted referees that support identity verification will need to be able to compare the facial portraits on presented evidence to the applicant claiming the identity represented in that evidence. As such, when CSPs offer this visual facial image comparison as a verification option, the following requirements apply:

1. Proofing agents and trusted referees SHALL be trained to conduct visual facial image comparison. 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.
2. Proofing agents and trusted referees SHALL be assessed 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. 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.
3. 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.
4. CSPs SHALL document their training and assessment procedures for visual image comparisons and make them available to RPs upon request.
5. 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).

Requirements for the Validation of Physical Evidence

The validation of physical evidence can be conducted by optical capture and inspection (often called document authentication or “doc auth”) or via visual inspection by a trained proofing agent or trusted referee. CSPs can employ either or both processes to evaluate the authenticity of identity evidence.

The following requirements apply to CSPs that employ optical capture and inspection for the purposes of determining document authenticity:

1. Automated evidence validation technology SHALL meet the following performance measures:
   • Document false acceptance rate (DFAR) of 0.1 or less⁶
   • Document false rejection rate (DFRR) of 0.1 or less⁷
2. 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.
3. CSPs SHALL implement live capture of documents during the validation process and SHALL implement passive or active document presence checks (also called document liveness). 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.
4. 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. These tests SHALL account for all available identity evidence types that the CSPs allow to be validated using optical capture and inspection technology. 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.
5. CSPs SHOULD have their evidence validation technology periodically tested by independent entities (e.g., accredited laboratories or research institutions) for their performance characteristics.
6. CSPs SHALL make the results of their testing publicly available.

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

The following requirements apply to CSPs that employ visual inspection of evidence by trained proofing agents or trusted referees for the purposes of determining document authenticity:

1. 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)
   • Common indications of tampering (e.g., damage to the lamination, image modification)
2. 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.
3. Proofing agents and trusted referees SHALL be provided with specialized tools and equipment to support the visual inspection of evidence (e.g., magnifiers, ultraviolet lights, barcode readers) as appropriate for the identity evidence type.
4. 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. In these instances, the visual validation SHOULD be supported by automated document validation technologies that provide additional confidence in the authenticity of the evidence (e.g., submitting and validating evidence in advance of an attended remote session).
5. CSPs SHALL document their training and assessment procedures for visual inspections of evidence and make them available to RPs upon request.

Due to the potential number and permutations of identity evidence, these guidelines do not attempt to provide a comprehensive list of security features. CSPs need to provide evidence validation training that is specific to the types of identity evidence they accept.

Digital Injection Prevention and Forged Media Detection

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

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

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

The following requirements apply to all remote identity proofing processes (i.e., unattended and attended) that make use of optical capture and recognition tools for evidence validation, remote biometric capture, and video sessions:

1. CSPs SHALL implement technical controls to increase confidence that digital media is being produced by a genuine sensor during the proofing process (e.g., detect the presence of a virtual camera, device emulator, or a jailbroken device).
2. CSPs SHALL analyze all digital media submitted during the identity proofing process for artifacts and indicators of potential modification, manipulation, tampering, or forgery. Automated image analysis algorithms SHALL be tested against available attack artifacts (i.e., forged and manipulated images and videos) 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. 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. Algorithmic analysis of media and automated decisioning SHOULD be augmented by manual reviews to address detection errors.
3. CSPs SHALL only use authenticated protected channels for the exchange of data during remote identity proofing processes.
4. CSPs SHOULD introduce a passive means of detecting forged or manipulated media for all capture scenarios.
5. CSPs SHOULD authenticate capture sensors or implement device attestation to increase the confidence in a device being used to transmit digital media as part of a remote identity proofing process.
6. CSPs SHOULD analyze digital media for signatures of generative AI algorithms and deepfake tools that are known to be used to create forged digital media.

The following additional requirements apply to remote attended collection scenarios:

1. CSPs SHALL train proofing agents and trusted referees to look for indications of manipulated media (e.g., high latency, synchronization issues, inconsistent skin tone and resolution).
2. CSPs SHALL introduce random “human-in-the-loop” cues into their capture processes to increase the possibility of forged or manipulated media being detected (e.g., by requesting user movements or requesting that the user move objects between the capture sensor and their face).

Exception and Error Handling

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

In order to increase the accessibility of their identity proofing services and address customer experience challenges, CSPs SHALL document their operational processes for dealing with errors and handling exceptions. 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.

Requirements for Trusted Referees

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 following requirements apply whenever trusted referees are used:

1. The CSP SHALL notify the public of the availability of trusted referee services and how such services are obtained.
2. 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.
3. 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:
   1. Document identification and validation, such as common templates, security features, layouts, and topography (see Sec. 3.13)
   2. Indicators of fraudulent documents, such as damage, tampering, modification, fabrication, or forgery (see Sec. 3.13)
   3. Facial image comparisons to verify applicants against presented documents (see Sec. 3.12)
   4. Indicators of social engineering exhibited by an applicant, such as distress, confusion, or coercion
   5. An annual review of the trusted referee’s abilities to visually inspect evidence and make visual facial image comparisons (see Sec. 3.12)
4. 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.
5. The CSP MAY offer trusted referee services for either on-site attended or remote attended sessions. These sessions SHALL be consistent with the requirements of these proofing types based on the IAL of the proofing event.

Uses of Trusted Referees

Trusted referees offer a critical path for those who are unable to complete identity proofing by other means. However, given the number of possible failures that may occur within the proofing process, it is essential for CSPs to define the uses for which a trusted referee can be applied within their own service offerings. The following requirements apply to defining the integration of trusted referees into the identity proofing process:

1. CSPs SHALL document which types of exceptions and failures are eligible for the use of a trusted referee.
2. CSPs SHOULD offer trusted referee services for failures of automated verification processes (e.g., biometric comparisons).
3. 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. If a CSP offers trusted referees for this purpose, the following requirements apply:
   1. CSPs SHALL provide a policy for additional evidence types that may be used to corroborate core attributes or changes in core attributes.
   2. Trusted referees SHALL review additional evidence types for authenticity to the greatest degree allowed by the evidence.
   3. 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.
   4. 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).

Requirements for Applicant References

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.

If applicant references are supported at IAL1 or IAL2 the following requirements apply:

1. The CSP SHALL notify the public of the allowability of applicant references and any requirements for the relationship between the reference and an applicant.
2. 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.
3. The CSP SHALL identity-proof an applicant reference to the same or higher IAL intended for the applicant. 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.
4. 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.
5. 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.

Uses of Applicant References

Applicant references can take several different actions to support an applicant in the identity proofing process, depending on the circumstances and context of the CSP and RP services. CSPs SHOULD offer the use of applicant references if the risks to the online service of doing so allow for it. 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.

1. The applicant reference MAY vouch for one or more claimed core attributes relative to the applicant as part of the evidence and attribute validation process.
2. The applicant reference MAY vouch for the identity of the applicant in the absence of sufficient identity evidence.
3. The applicant reference MAY vouch for a specific condition or status of an applicant relative to the identity proofing process (e.g., homelessness, disaster scenarios).

This information is intended to support risk determinations relative to the identity proofing event. Use of applicant reference statements to establish eligibility for status or benefits is outside of the scope of these guidelines.

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. This MAY include:

1. Capturing and recording the statements and assertions made by the applicant reference
2. Capturing a digital signature or physical signature of the applicant reference
3. Capturing consent and acknowledgement relative to the legal and liability impacts of the applicant reference’s statements

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.

Establishing Applicant Reference Relationships

In many cases, there will be business, legal, or fraud prevention reasons to confirm the relationship between the applicant and an applicant reference. If such steps are deemed necessary by a risk assessment, the following requirements SHALL apply:

1. The CSP and RP SHALL establish requirements for applicant reference relationship confirmation processes and document them in any contracts or trust agreements.
2. The CSP SHALL make a list of acceptable evidence of relationship available to the applicant reference prior to initiating the relationship confirmation process.
3. The CSP SHALL request evidence of the applicant’s relationship (e.g., notarized power of attorney, a professional certification).
4. 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.

Requirements for Interacting With Minors

The following requirements apply to all CSPs that provide identity proofing services to persons under the age of 18:

1. 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.
2. 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.
3. CSPs SHALL support the use of applicant references when interacting with individuals under the age of 18.

Elevating Subscriber IALs

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

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