NIST SP 800-63A-4 Identity Proofing (IAL) Guide: Proofing Levels, Evidence and Fraud Controls

Most identity proofing programmes that claim to follow NIST SP 800-63A cannot show which evidence combination, validation method and verification pathway each applicant actually went through. Revision 4 of the identity proofing volume, published as final on 31 July 2025, turns proofing into an auditable set of requirements: graded evidence, mandatory fraud management, controls against injected and forged media, measured biometric performance and documented exceptions. This guide works through the volume section by section so that credential service providers (CSPs), relying parties (RPs) and auditors can map a real onboarding flow to it. It assumes the concepts of proofing are familiar; the Identity Proofing and KYC Guide covers those, and the NIST SP 800-63 Digital Identity Guidelines Guide covers the whole suite.

Key takeaways

• Evidence is graded, not counted. SP 800-63A-4 defines FAIR, STRONG and SUPERIOR evidence by how it was issued and protected, and each IAL needs a specific combination.
• Fraud management is now normative. Every CSP needs a documented fraud programme, a death records check for every proofing event and a way to tell RPs about suspected fraud.
• Remote proofing must resist injection. All remote processes have to detect virtual cameras, emulators and jailbroken devices and analyse submitted media for manipulation.
• Knowledge-based verification is out. KBV must not be used to verify identity, although it may still feed fraud checks.
• Deviations travel in writing. Compensating controls are allowed only if documented and given to RPs in a Digital Identity Acceptance Statement (DIAS) before integration.

What it is and who it applies to

NIST SP 800-63A-4, Digital Identity Guidelines: Identity Proofing and Enrollment, supersedes SP 800-63A (revision 3, last updated March 2020). The csrc.nist.gov publication page lists it as Final, released 31 July 2025, after drafts in December 2022 and August 2024. It is one of four volumes: SP 800-63-4 sets the risk process for choosing assurance levels, 63A covers proofing and enrolment, 63B covers authenticators and 63C covers federation.

• Who must follow it: US federal agencies and the CSPs they use for public-facing and workforce identity services. Outside government it is not mandatory, but many identity verification vendors, regulated firms and certification schemes test against it, so it acts as the reference standard for remote proofing.
• Who it addresses: CSPs (which proof and enrol applicants), RPs (which consume the result and carry obligations of their own), and proofing agents and trusted referees (people who run attended sessions and exceptions).
• What it does not cover: the choice of IAL itself (that is the Digital Identity Risk Management process in the base volume), authenticators (63B) and how the proofed identity is asserted to RPs (63C).

The document is split into normative and informative parts. Sections 2 to 5 (overview of proofing, general requirements, IAL-specific requirements and subscriber accounts) are normative; the security, privacy and customer experience considerations and the evidence examples in the appendices are informative.

Structure and key requirements

Proofing roles and types

Section 2.1 defines four proofing types, and a CSP should offer the combination that best fits its population and the RP's risk:

Evidence strength

Section 2.4 grades evidence by how its issuer confirmed identity, how it was delivered and how it is protected. Each tier has a list of requirements the evidence must meet in full:

The examples column is indicative only; whether a specific document qualifies depends on the issuer's procedures, so CSPs should record why each accepted document type was graded as it was. Signed digital evidence such as a Mobile Driving Licence (mDL) can reach SUPERIOR because it is validated cryptographically rather than visually.

Validation and verification

• Evidence validation (Section 2.4.2): the CSP shall confirm evidence is authentic, accurate and valid, using in-person visual and tactile inspection, remote visual inspection, automated document validation or cryptographic verification of digital evidence.
• Attribute validation: all core attributes, whether taken from evidence or self-asserted, shall be validated against an authoritative source (the issuer or a party with direct access to issuer data) or a credible source (traceable to an authoritative source or correlated from several sources, and subject to regulatory oversight).
• Verification (Section 2.5.1): the link between applicant and identity is shown by a confirmation code, an authentication or federation protocol, transaction verification such as a micro-deposit, visual facial comparison or automated biometric comparison.
• KBV: knowledge-based verification shall not be used to verify identity. It may still be used inside fraud management.
• SSNs: a CSP may collect a US Social Security Number for resolution, but knowledge of it shall not be treated as evidence.

Requirements by IAL (Section 4)

For IAL3 this guide states only what the published text sets out in its IAL overview (attended on-site session, biometric collection, bound authenticators). Check Section 4.3 of the final text for the exact evidence combinations before claiming IAL3 conformance.

Confirmation codes, continuation codes and notifications

Fraud management (Section 3.2)

This is the largest change for many CSPs. The CSP shall:

• maintain a documented fraud programme covering identification, detection, investigation, reporting and resolution;
• complete a privacy risk assessment of fraud checks before switching them on;
• run a death records check for all proofing;
• analyse every remote channel for high-risk indicators such as blocklisted proxies and IP addresses;
• stop unsuccessful applicants from inferring whether their data was accurate;
• monitor fraud check performance, train agents to spot fraud and give them a way to flag events;
• apply insider-threat controls against collusion between agents and applicants;
• tell RPs about suspected and confirmed fraud, and give victims a way to report and get help.

Recommended (SHOULD) checks include SIM swap detection, device and account tenure, mailing address checks (for example virtual PO boxes), device fingerprinting, transaction analytics and velocity, red-team testing and real-time sharing of fraud events with RPs through shared signalling (the volume points to SP 800-63C Section 4.8); the Shared Signals Framework is one way to do that.

Biometrics, injection and forged media (Sections 3.11 to 3.14)

Recommended additions are passive forgery detection, sensor authentication or device attestation, analysis for generative AI and deepfake signatures, and manual review of algorithmic decisions. The Deepfake-Resistant Identity Verification Guide covers these techniques in depth.

Exceptions: trusted referees and applicant references (Section 3.15)

• Trusted referees: the CSP shall announce their availability, train and certify them (document validation, fraud and social engineering indicators, facial comparison, annual reassessment) and record every session: reason, referee identity, evidence, steps completed and decision with rationale.
• Applicant references: if supported at IAL1 or IAL2, the reference shall be proofed to the same or a higher IAL, and the role and relationship recorded.
• Minors: a written policy is required, with COPPA compliance for under-13s and support for applicant references for under-18s.

Identity and NHI requirements

SP 800-63A-4 is about people. It does not proof service accounts, workloads or AI agents, and treating it as if it did creates false assurance. Three points still matter for non-human identity programmes:

• Agents acting for people: an AI agent or automation that acts on behalf of a proofed subscriber inherits nothing from that proofing. Its own identity and credentials need their own lifecycle; see the Agent Delegation Chains Guide.
• The proofing pipeline is full of machine credentials: API keys to document verification vendors, authoritative source connectors and fraud data services. Section 3.5 requires the SP 800-53 moderate baseline and SP 800-161 supply chain controls for the CSP, which covers these integrations. Treat the vendor API keys as high-value NHIs: rotate, scope and monitor them. See the NIST SP 800-161 Cyber Supply Chain Risk Management Guide.
• Bots and automated applicants: Section 3.5 requires automated attack protection (bot management, web application firewall, traffic analysis). Scripted onboarding is a non-human attacker, and synthetic identity farms rely on it.

Implementation steps

1. Confirm the target IAL per service. Take the IAL from the Digital Identity Risk Management assessment in SP 800-63-4, not from the vendor's default flow. Record any tailoring.
2. Build an evidence register. List every document and digital credential accepted, its strength grade with justification, and the validation method used for it.
3. Map each pathway to Section 4. For every proofing journey (remote unattended, remote attended, on-site), write down the evidence combination, attribute validation source and verification method. This is the artefact auditors ask for first.
4. Stand up the fraud programme. Document it, add the death records check, run the privacy risk assessment of each fraud check, wire SIM swap and device signals, and agree a fraud contact with every RP.
5. Test injection and PAD controls before go-live. Use an independent lab report for PAD to ISO/IEC 30107-3, and run your own red-team tests with virtual cameras and emulators against the real capture SDK in production configuration.
6. Design exceptions. Publish the trusted referee route, train referees and create the session record template. Offer referee review when unattended proofing fails.
7. Pilot with a monitored cohort. Run the new flow for a slice of applicants, compare pass rates, abandonment and early-life fraud with the old flow, and keep the old flow available as rollback until the metrics hold for a full fraud cycle (typically 60 to 90 days of account behaviour).
8. Publish the practice statement and DIAS inputs. Give RPs the practice statement, the privacy and customer experience assessment summaries, and any compensating controls.

Evidence and assessment

Metrics that show the controls work:

• early-life fraud rate: accounts confirmed fraudulent within 90 days of proofing, per pathway;
• injection and PAD detections per 10,000 sessions, and the share later confirmed by manual review;
• trusted referee use rate and referee approval rate, watched for drift that may signal social engineering;
• completion rate by pathway and demographic segment, to catch exclusion;
• time to notify RPs of confirmed fraud;
• disputes raised from proofing notifications, a direct signal of identities proofed without the owner's knowledge.

Mapping to other frameworks

CIS Controls v8.1 touch proofing only indirectly, through Control 5 (Account Management) and Control 6 (Access Control Management, including 6.1 Establish an Access Granting Process).

Common pitfalls

• Claiming IAL2 for a selfie-and-document flow without injection controls. PAD alone is not enough: Section 3.14 applies to all remote proofing, and a capture SDK that accepts frames from a virtual camera fails it.
• Proofing at onboarding, then resetting by phone. Proofing assurance collapses if the help desk can reset authenticators after a convincing call. The MGM Resorts breach began with a call to the IT help desk impersonating an employee found on LinkedIn. Recovery must re-proof or use bound recovery methods; see the Account Recovery and Help Desk Security Guide.
• Keeping KBV as a verification step. Many legacy flows still ask out-of-wallet questions to "verify" the applicant. Under revision 4 that is a fraud signal at most.
• Using vendor marketing figures as test evidence. Section 3.11 asks for independent lab testing, demographic results and performance measured in conditions like the operational environment.
• Undocumented compensating controls. If a fraud check is skipped or replaced, the deviation has to be in the DIAS given to RPs before integration. Silent tailoring is a finding.
• Error messages that leak. Telling a failed applicant which attribute did not match helps attackers tune synthetic identities, and breaks the Section 3.2 requirement that applicants cannot infer data accuracy.

Practitioner checklist

• Record the target IAL and the DIRM assessment behind it for each service.
• Grade every accepted evidence type FAIR, STRONG or SUPERIOR, with a written justification.
• Document each proofing pathway against the Section 4 combinations and log the pathway used per applicant.
• Remove knowledge-based questions from verification steps.
• Run a death records check and the other Section 3.2 fraud controls, and name a fraud contact with each RP.
• Obtain independent PAD (ISO/IEC 30107-3) and biometric (ISO/IEC 19795) test reports, including demographic results.
• Test the production capture path against virtual cameras, emulators and replayed media.
• Publish the trusted referee route and keep complete session records.
• Check confirmation code lifetimes against the Section 3.8 limits.
• Publish the practice statement and give RPs the DIAS inputs, including compensating controls.

Standards and references

• NIST: SP 800-63A-4 Digital Identity Guidelines: Identity Proofing and Enrollment
• NIST: SP 800-63A-4 online edition
• NIST: SP 800-63B-4 Authentication and Authenticator Management
• NIST: SP 800-63C-4 Federation and Assertions
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• NIST: Cybersecurity Framework 2.0
• MITRE ATT&CK: Spearphishing Voice

Related NHI Mgmt Group resources: Identity Proofing and KYC Guide · NIST SP 800-63B-4 Authenticator Assurance Levels Guide · NIST SP 800-63C-4 Federation Assurance Levels Guide · Deepfake and AI Impersonation Guide