NIST IAL2 Identity Verification An Updated Review of Requirements
Four parts of NIST 800-63 include identity guidelines, identity proofing, authentication, and federation documents. The NIST page provides a good overview of each section, and you can explore the guidelines for granular details further. As each covers a massive amount of information, we will only select the 800-63A, titled Enrollment and Identity Proofing. Trust Swiftly fits perfectly in this section, and we have meticulously built our tool to comply with this requirement. The guidelines have gone through multiple iterations throughout the years but now are at a point where they are clear and valuable for anyone trying to follow them. Many regulated industries, such as government and healthcare (EPCS), will specifically require a business to complete Identity Assurance Level 2 (IAL2) as part of an onboarding process. Identity assurance means the level of confidence you have about a person after verifying them. The other assurance levels are not explored thoroughly at Trust Swiftly as we focus on a solution that complies with level 2. IAL1 is too weak to be considered worthwhile for most business cases, and IAL3 would require an in-person check, which can only be partially automated with a solution like Trust swiftly.
No public requirements traceability for identity verification solutions are available, and most have to rely on an auditor to provide this certification. Kantara has a similar requirements list. If you look at their Excel documents for SoCA in the Component Services, here is the Trust Status List: Approved Kantara Trust Mark Holders and More. These are also from the older version of NIST but can provide a good guideline on requirements for adherence to the lAL2 standard. The downside is you do not see many details or proof of their past reason and must rely on the assessor and solution as trustworthy. To create a more open environment, we can tailor a solution for clients that will adhere to NIST IAL2 while having clear proof of traceability to the original NIST document. No two companies will fulfill the same IAL2 requirements as each may adjust their configuration and processes to meet their business and regulatory needs. For example, if you plan to audit your NIST 800-63A process by a big four company like Deloitte, you must be prepared with documentation and live solution walk-throughs by an external auditor. Lastly, certifications and audits alone are no longer a way to stay ahead of identity-related fraud. The NIST standards should be a baseline, and you need to work with solutions that develop secret and innovative features that will continuously challenge bad actors. Fraudsters quickly canvas solutions that stay static, and they eventually become bypassed, as detailed in countless posts.
Adhering to the normative sections of the NIST framework is not just important, it's crucial for maintaining the required level of assurance. While there are other best practices and tips for Credential Service Providers (CSP), most of them are already followed, and others apply to specific needs that software solutions cannot cover solely so they may be out of scope. The following nine sections provide a high-level overview of the steps and structure of the document. At the bottom is a table of each NIST 800-63A requirement that should be followed along with our comments and traceability to Trust Swiftly’s solution.
1. Identity Resolution - Collect multiple documents.
2. Evidence Collection - Extract evidence and classify it.
3. Evidence Validation - Verify data accuracy.
4. Identity Verification - Selfie and document checks.
5. Binding - Authenticator checks.
6. Fraud Detection - Up-to-date AI and fraud mitigation.
7. Privacy and Security - Security processes and controls.
8. Usability - UI interfaces.
9. Compliance - Review of NIST guidelines.
| ID | NIST 800-63-4 (SP800-63A) Requirements | General Comments | Trust Swiftly Traceability |
|---|---|---|---|
| 4.2.1 | Proofing Types | States that multiple entry points can be used to achieve IAL2. Unattended remote means the user completes the task without human oversight. The attended one means a person is guiding them through the process. Onsite is the last option, where a person physically guides them through the session. Any of these methods are allowed. | The application (Trust Swiftly) has the flexibility to meet all types of this requirement. i.e., if you want to do unattended, our system can automatically verify a person. Otherwise, you can use our Live video option to have an agent join the session or even set up an in-person process. Typically, the attended option is only used as an out-of-band option to help users who have trouble with the automated process. If you choose the in-person process, you must employ and train your agents, as Trust Swiftly can only provide the technology, not any physical referees or reviewers. |
| 4.2.2 | Evidence Collection | Clarifies the two groupings of verification methods in identity proofing. The process allows for different categories of evidence strength levels, with the requirement to meet the minimum. The first grouping involves one fair evidence and one strong method, while the second allows for one superior evidence document, such as a cryptographic passport check. A table of more example evidence and their strength can be seen here: https://pages.nist.gov/800-63-4/sp800-63a.html#EvidenceExamples | Trust Swiftly offers configurable verification templates that empower you to select the verifications that meet IAL2 compliance. For instance, a Driver's License and a carrier phone verification can serve as strong and fair evidence. Our system's adaptability to various methods allows you to increase the number of users who meet this requirement. We've observed that certain evidence groups work better in specific industries, underscoring the importance of planning and adjusting the verification templates when deploying an IAL2 solution. For example, medical professionals have a higher rate of passport ownership, which can expedite and enhance document collection. |
| 4.2.3 | Attribute Collection | Stresses the importance of collecting and validating multiple identity data points, such as names, addresses, phones, ID numbers, and SSNs. While collecting the data is essential, the preferred path is to validate it, as this helps to prevent potential misrepresentation. | Trust Swiftly allows for the validation of numerous attributes about a person. While the main attributes should be validated, any additional data points can be self-asserted, contributing to the overall proofing of an identity. For instance, a DL number and all other text on an image can be extracted and compared with more authoritative data sources. These attributes can be later used for fraud detection and other security measures, underscoring the comprehensive nature of the verification process. |
| 4.2.4 | Evidence Validation | Underlines the thoroughness of the evidence validation process, stating that any provided evidence should be rigorously validated for authenticity and integrity. This differs from attribute validation as it refers to markers like digital signatures and cryptographic checks. For example, the certificate of a US passport is meticulously checked using an NFC, and then the ICAO Public Key Directory (PKD) is used to validate it. This thorough validation process instills a sense of security and confidence of the identity. | The application supports evidence validation through multiple digital checks and ensures no tampering with submitted documents. Also, we can check NFC identities to verify their cryptographic authenticity. If you plan to use any in-person guided types, as mentioned in 4.2.1, you must adequately train agents to look for any physical checks, such as checking the ID security features of raised lettering. |
| 4.2.5 | Attribute Validation | States all core attributes must be validated either through an authoritative or credible data source. Core attributes are first, middle, and last name, government identifier, and physical address. The attributes should be tracked with the evidence that was provided to them so each step is audited. Reference numbers should be checked, too, if the evidence gives them. | The application can connect to multiple governments and third-party data sources to verify authenticity. For example, a DL number must be checked with a DMV to verify the name and ID match what is stored in their database. Also, Trust Swiftly can verify superior documents by using the public key to check a government passport. The system also automatically correlates which evidence is linked with the identity attribute. |
| 4.2.6 | Verification Requirements | It states there should be multiple pathways for a user to complete verifications, considering various scenarios. There should be more than one method to use for each scenario determined. | The application natively supports this functionality and has multiple templates to meet this requirement. High-risk environments can use specific verification methods to ensure high levels of security. Trust Swiftly is not limited to a set of pathways but has hundreds of combinations that can lead to IAL2. |
| 4.2.6.1 | IAL2 Verification - Non-Biometric Pathway | States that verification can be completed using non-biometric methods of evidence verification. It is not limited to facial biometrics and there are non-biometric methods such as one time codes to a physical address. | The application supports both non-biometrics methods mentioned in the requirements. For fair evidence, we support all three examples mentioned: email, phone, and postal address. Next, Trust Swiftly can turn off any automatic biometric checks and maintain maximum privacy for your users as long as you staff an agent to properly compare the biometrics during one of the proofing types mentioned earlier. Lastly, we can send physical letters to an address with a unique code from the evidence and validated with an authoritative source. |
| 4.2.6.2 | IAL2 Verification - Digital Evidence Pathway | It states that verifications can use digital methods, which allows for greater automation. The fair, strong, and superior evidences each have further requirements to verify an account. | The application provides options for each level of evidence to support IAL2. Micro-transactions can be done against a financial account for the fair level. Also, the OTP to a phone is another option. Lastly, the connection and authentication of a bank account is another option that meets superior evidence as long as the bank fulfills AAL3/FAL2 requirements. Trust Swiftly can gather bank account identity information such as name, phone, and address. |
| 4.2.6.3 | IAL2 Verification - Biometric Pathway | This requirement is similar to 4.2.6.1 but allows automation using a system that compares face biometrics. For example, the Driver's License evidence has the portrait image, which then is compared to a live facial image taken during the verification process. Another comparison method can be using non-facial biometric evidence or ones from an authoritative database. | The application allows for automated biometric checks, which vectorize faces to compare each piece of evidence. The system is able to adjust for various scoring levels of comparison and can even add a combination of biometric and non-biometric oversight pathways. There should be another check of the values for strong and superior checks to verify their records with the original evidence. |
| 4.2.7 | Remote Attended Requirements | The requirement is for agents to guide a user through proofing processes. Specific checks include agreements, recording, fraud, and deepfake prevention. | The application supports each requirement through a high-definition video connection with the support for recording through privacy-preserving methods. Our solution allows the scheduling of remotely attended sessions and the recording of decisions about the evidence presented. The agent must be trained to spot fraud and create a structured process to verify a person properly. |
| 4.2.8 | Onsite Attended Requirements | States that a person can be proofed at a physical location. The proofing agents will guide the person through each step and be properly trained. There can be a recording of the onsite session. | The application can be used as a tool to aid an onsite verification process. The agents will need to be separately trained, but they can use Trust Swiftly on an approved device in person. The agent would walk the user through each step, state the different consent requirements, and be responsible for recording the interaction. |
| 4.2.9 | Onsite Unattended Requirements (Devices & Kiosks) | States a onsite device or kiosk can be used to complete the proofing process. The device should be appropriately secured and locked down to prevent tampering. The device would then be used to complete evidence collection and the verifications. | An onsite device or kiosk can load the application for verifications. Trust Swiftly can be embedded as part of an application with secure sessions. Each new person must have a separate verification session, and the device loads the proofing steps. The CSP is responsible for using a secure device and locking it down so no tampering is allowed during the session. For example, an iPad in a secure kiosk stand can be used with a custom application that starts the proofing process. |
| 4.2.10 | Notification of Proofing | States that a person should be notified through email, mail, or phone about the status of their proofing. It should provide details about the identity proofing event and give subscribers options about false verifications or other privacy concerns. | Trust Swiflty can notify the user through email about proofing their identity once they complete all the steps. There is a customizable email that can include each requirement and provides methods to contact the organization. Notifications can also be triggered through SMS and email to start the proofing process. It is essential to use notifications in multiple methods to prevent socially engineered verifications and provide the next steps in the process. |
| 4.2.11 | Initial Authenticator Binding | It states that the user can be granted an authenticator upon completion of the identity-proofing process. They are initially referred to as an applicant but then a subscriber in the system as proof. An authenticator can be bound to the account, and it should be distributed in a secure manner to the device or address verified in previous steps. | The application supports binding a device authenticator through Passkeys. The passkey can be restricted to a FIDO2 compliant device with certificate verifications. This will require a biometric authentication for the device. If you need to use a physical authenticator, it should be mailed by the organization only to the validated address used during the proofing process. |
| 3.1.1 | Identity Service Documentation and Records | These general requirements are multiple policy and documentation audits to oversee the IAL2 process. This includes assessments and other training that improve the overall identity-proofing process. | The application includes multiple ways to address proofing errors and documents each action through an audit trail of events. The system also provides privacy agreements and click-through acceptance of biometric checks. Lastly, there are tools in place to support fraud checks and reviewing verifications out of the cycle. |
| 3.1.2 | Fraud Management | This is a vital requirement that requires a solution to do multiple fraud checks. For example, duplicate accounts and other device checks can be used to prevent overall fraud during verifications. A process should be in place to handle fraud, and training is required to handle different scenarios. | Trust Swiftly employs a comprehensive set of fraud detection measures, using multiple signals and data points to detect any fraudulent activity. The system implements many suggested fraud detection techniques, such as sim swap indicators, geolocation checks, device activity monitoring, and liveness checks. This robust approach, including N:1 face duplicate detection, ensures that repeated fraud identities and personas are effectively prevented, providing a high level of security. |
| 3.1.3 | General Privacy Requirements | The privacy requirements detail steps that applicants should take to be notified about the proofing process, PII collected, and retention policies. Lastly, policies and documentation should outline the PII collected and provide risk assessments. | The application supports the configuration of multiple privacy options. For example, PII can be stored in regulated storage locations, and data can be redacted or turned into anonymous identifiers. Custom privacy notifications and agreements can be placed in the flow prior to the identity-proofing process. |
| 3.1.4 | General Equity Requirements | Emphasizes the importance of the equity requirement, ensuring that solutions meet the needs of multiple communities. Any discrimination or bias in a solution is rigorously checked and tested to ensure equity in the tool. This commitment to inclusivity makes the audience feel included and valued, knowing that their needs are being considered in the identity proofing process. | The application supports multiple custom identity proofing processes and exception handling for automated decisions. The solution is adaptable to allow trusted referee options and is monitored by an agent to ensure the process is equitable. |
| 3.1.5 | General Security Requirements | The security requirement is a general list of best practices to protect the proofing process. Automated attempts and other fraud mitigation should be applied, and security settings should be enabled, such as a WAF. The security requirement covers suppliers and requires assessing the risks to create appropriate controls. | The application is securely audited and protected against many types of attacks. Automated identity-proofing attacks are the top measure to stop. We can check duplicate identifiers and enable captchas and firewalls to stop abusers. Bots are also blocked, and traffic analysis is performed to rate limit attempts. More information about our security can be found here: https://security.trustswiftly.com. |
| 3.1.6 | Redress Requirements | The redress requirement means the person can retry or correct their identity-proofing steps. There should also be a method to contact the CSP for help or resolving issues. | The application supports multiple retry options and an override or rejection method for agents. If proofing fails, the system can prompt the person to provide additional evidence. There also is a self-help option for the user to select a different verification pathway automatically. Lastly, live chat and support links are available to increase pass rates and resolve problems. |
| 3.1.8 | Requirements for Confirmation Codes | The confirmation code requirement is to check the random decimals sent for a proofing process. Each method allows different validity times. For example, a text with a code should only work within 10 minutes. | The application, by default, meets all confirmation code requirements by expiring codes in the appropriate timeframe. The codes can also be sent via multiple methods, such as postal address, email, and phone. |
| 3.1.9 | Requirements for Continuation Codes | The continuation code requirement is a checkaround for transferring an incomplete session or using a new proofing type. The codes should be throttled and securely generated. | The application supports QR codes to transfer a session from one device to the next in a secure manner. For example, if a verification requires a transfer to a phone for an attended verification, the user can scan a QR code on their PC to continue the session. |
| 3.1.11 | Requirements for the Use of Biometrics | The biometrics requirements detail various methods to verify based on a person. It can include voice, facial, or other behavior based on the person. The biometrics should be tested to keep false match rates low and account for other privacy requirements. Anti-fraud techniques should be applied to ensure biometric accuracy and not another person. | The application allows for custom consent messages about the collection of biometric data. It also has multiple methods that NIST has tested to ensure the algorithms correctly match facial attributes. The solution also has secure measures to prevent spoofing and other deepfakes. |
| 3.1.12 | Requirements for Evidence Validation Processes (Authenticity Checks) | The evidence authenticity requirement includes additional steps to verify a document. Automated or visual inspection checks will be used depending on the proofing type. Documents with MRZ or barcode should be matched against the visual text portion. | The application supports multiple authenticity checks to verify a document. Virtual cameras are detected, and checks are made to match a PDF417 barcode with the front of a driver's license. Live document capturing is also supported to prevent saved images from being uploaded. |
| 3.1.13 | Exception and Error Handling | The exception and error handling requirement requires processes to remediate failures during proofing. Trusted referees can be used to aid in completing or reviewing any errors in evidence documents. An applicant reference can also vouch for a person's different core attributes. | The application can handle exceptions and errors during the proofing process. For example, if the user takes a blurry or too-dark image, the system will inform them of the issue and require another clear image. There are exceptions upon errors where a trusted referee can guide a user during proofing. The training of the referees is up to the organization and is staffed by their team to ensure the privacy and security of the process. |
| 5.1 | Subscriber Accounts | The subscriber account requirements cover various details about the person once they have completed a proofing process. It provides guidelines on their ability to access and maintain their account. Lastly, it details the suspension or termination of the account due to various circumstances. | The application automatically keeps each subscriber account separate and unique during enrollment and proofing. Each account is assigned a unique identifier, which also supports reference IDs. The application supports additional authentications and updates through the submission of authenticated requests. The option to terminate an account is also available, as well as reactivate it if the suspension is temporary. |