NIST SP 800-63A: Three Identity Proofing Steps Fraud Teams Can’t Skip

NIST SP 800-63A defines identity proofing as a three-step sequence of identity resolution, identity validation, and identity verification, and sets requirements for Identity Assurance Levels, including IAL2. IAL2 requires verified identity evidence, validation against authoritative sources, and verification that ties that evidence to a living applicant. Below, we cover the operational steps, documentation duties, and privacy safeguards that implementers need to get this right.

TL;DR:

• Use the current fourth edition of NIST’s identity proofing guidance, rather than the superseded 2017 edition and its 2020 updates, for compliance requirements.
• IAL2 permits remote proofing, but organizations must validate evidence with authoritative sources and bind it to applicants using biometric comparison and presentation attack detection.
• Combine visual document checks with independent authoritative queries, because either method alone can leave blind spots that fraudsters can exploit.
• Subscriber records must identify evidence, proofing method, IAL achieved, and any exception process; trusted referees offer an auditable alternative for applicants lacking standard documents.
• Collect only the personal and biometric data required for the chosen IAL; excess information increases privacy exposure and the harm a breach can cause.

Table of Contents

• Where SP 800-63A Fits in the Broader NIST 800-63 Framework
• The Three-Step Proofing Sequence: Resolution, Validation, Verification
• IAL1, IAL2, and IAL3: What Separates Them
• Identity Evidence: Accepted Types and How to Validate Them
• Remote, Supervised Remote, and In-Person Verification Methods
• Biometric Binding, Presentation-Attack Detection, and Privacy Duties
• Documenting Proofing: Subscriber Records and Exception Handling
• Building an IAL2 Workflow Without Losing Applicants
• What Fraud Teams Should Prioritize First
• Deepen Your Proofing Program With Fraud Signals News
• FAQ
• Sources

Where SP 800-63A Fits in the Broader NIST 800-63 Framework

SP 800-63A governs enrollment and identity proofing specifically. It is one piece of a larger suite that separates concerns deliberately: identity assurance (how confidently we know who someone is) sits apart from authentication assurance (how reliably someone proves control of a credential) and federation assurance (how trust is passed between systems). SP 800-63B covers authenticators and lifecycle management. SP 800-63C covers federation. SP 800-63A covers the front door: establishing that the person enrolling is who they claim to be before any credential gets issued.

This separation matters operationally. A fraud team evaluating an identity program should distinguish identity proofing from authentication, which address different parts of digital identity management. An organization can have excellent authenticator hygiene and still issue credentials to a fabricated or stolen identity if proofing controls are weak. SP 800-63A exists to close that gap.

The current normative text, SP 800-63A-4, supersedes earlier versions of the guidance, including the widely cited 2017 edition with its 2020 updates. Organizations that built proofing workflows against the older document should treat that prior version as background context rather than the compliance baseline going forward, since the superseded guidance no longer reflects current normative requirements. The newer publication reflects changes in evidence types (mobile driver’s licenses, verifiable credentials), updated expectations around biometric binding and presentation-attack detection, and sharper language on privacy and customer experience that the earlier version addressed only loosely.

Who actually implements this. Organizations can use SP 800-63A as a framework for identity proofing and enrollment. Credential service providers may help implement proofing workflows. For a fintech onboarding new account holders remotely, or a healthcare system verifying patient identity before releasing records, SP 800-63A provides a tested structure rather than an ad hoc checklist invented in-house. That consistency also matters for insurers, auditors, and partners who need a common reference point when assessing an organization’s fraud controls.

The Three-Step Proofing Sequence: Resolution, Validation, Verification

Every IAL2 or IAL3 workflow runs through the same mandatory sequence, and understanding each step separately is the foundation for everything that follows. NIST describes this as a three-stage process: identity resolution, identity validation, and identity verification.

Identity resolution comes first. This is the process of determining that the applicant is a distinct, real-life person within the population a service serves, not a duplicate account, a synthetic composite, or an entity that already exists under another identity in the system. Identity resolution determines whether the applicant is a real-life person who is unique within the population.

Identity validation comes next. Here, the question shifts from “is this person unique” to “is the evidence they presented authentic and accurate.” Identity validation confirms the authenticity of collected evidence.

Identity verification closes the loop. Identity verification confirms that the applicant presenting the evidence is the same individual to whom it was issued. Verification is what stops a fraudster from using someone else’s stolen, but entirely genuine, documents. Skip this step, and an organization can validate real evidence all day while still onboarding an impersonator.

IAL1, IAL2, and IAL3: What Separates Them

NIST structures Identity Assurance Levels as a progression, each tier adding evidence and verification rigor to counter a more capable threat.

IAL1 limits highly scalable attacks. Organizations should consult NIST’s requirements to determine the appropriate assurance level for their use case.

IAL2 is where most fraud-sensitive U.S. organizations need to operate, and it is also where implementation gets genuinely demanding. IAL2 requires more rigorous evidence and identity verification to protect against scaled and targeted attacks and evidence falsification. The threat model at IAL2 covers scaled and targeted attacks along with evidence falsification, meaning the controls have to withstand a motivated fraudster using convincing fake or stolen documents, not just an opportunistic bot.

IAL2 may use remote or in-person proofing. Organizations should consult the applicable requirements when choosing a proofing method. The tradeoff is that the controls substituting for physical presence need to be genuinely robust, not a checkbox photo upload with no validation behind it.

IAL3 adds on-site attended proofing by a trained agent and biometric collection to mitigate advanced fraud threats. Most commercial organizations will never need IAL3, but regulated sectors handling particularly sensitive access, or those with a documented history of sophisticated fraud attempts, should evaluate it deliberately rather than default to IAL2 out of convenience.

Choosing the right IAL is a risk decision, not a compliance checkbox. Organizations should map their fraud exposure, the cost of a false enrollment, and their user base’s access to acceptable evidence types before settling on a target level, and that mapping should be revisited as fraud patterns evolve.

Identity Evidence: Accepted Types and How to Validate Them

SP 800-63A does not treat all identity evidence as equal. Evidence strength depends on the issuing process, the security features embedded in it, and how reliably it can be checked against an authoritative source.

NIST lists examples of identity evidence and issuance processes, including PIV, PIV-I, CAC, mobile driver’s licenses, and digital verifiable credentials. See its identity evidence examples.

Validating this evidence is where many organizations under-invest. A visual review of security features, holograms, microprint, correct font usage catches only unsophisticated forgeries. Meeting IAL2 validation standards generally requires checking physical security features alongside automated queries: confirming an MDL’s mobile security object against the issuing authority’s signature, running passport data against issuer records, or querying DMV systems directly where those integrations exist. For digital credentials, this means certificate chain validation and, where applicable, checking against revocation lists to confirm the credential has not been invalidated since issuance.

The practical recommendation here is multi-source validation rather than reliance on a single check. An organization that validates evidence only against one database, or only through visual inspection, leaves itself exposed to whatever blind spot that single method has. Layering a document-authenticity check with an independent authoritative-source query catches a wider range of forgery techniques than either approach alone, and it is the difference between a proofing program that merely looks compliant and one that actually resists a motivated fraudster.

Remote, Supervised Remote, and In-Person Verification Methods

SP 800-63A describes proofing methods, and organizations should choose an approach that meets the requirements for their assurance level.

Remote unattended proofing happens entirely through self-service, typically a mobile app or web flow where the applicant captures their own document images and a selfie with no human supervision. This is the most common method for IAL2 at scale, and it depends heavily on automated document validation and biometric comparison to carry the assurance burden that a human agent would otherwise provide.

For remote attended proofing, organizations should consult SP 800-63A for the applicable requirements and document their chosen process.

On-site attended proofing is part of IAL3, which also adds biometric collection.

For IAL2, organizations should follow NIST’s applicable evidence and identity verification requirements when designing their proofing process.

Biometric Binding, Presentation-Attack Detection, and Privacy Duties

Biometric comparison is the primary mechanism SP 800-63A relies on for identity verification at IAL2 and the mandatory mechanism at IAL3. In practice, this means comparing a live facial capture against the photo on validated evidence to confirm the applicant is the person the document describes. Binding evidence to a live person this way is what distinguishes genuine identity verification from a process that merely confirms a document exists.

Biometric comparison alone is not sufficient, however, without presentation-attack detection (PAD). A photo of a photo, a mask, or a deepfake video can defeat a naive face-match check that never confirms liveness. Organizations should assess presentation-attack risks when designing identity proofing controls. Our earlier coverage of liveness detection for fraud teams walks through how replay and injection attacks specifically target weak liveness implementations.

Privacy obligations run alongside every biometric decision. NIST requires that organizations collect only the data necessary for the IAL they are targeting, since excess biometric or personal data collection increases both privacy exposure and the damage potential of a future breach. In practice, organizations should collect only the information necessary for the required IAL, since excess personal or biometric data raises privacy concerns and increases the vulnerability of stored data. A proofing program that collects more than its IAL requires is not more secure, it is simply carrying more liability.

Documenting Proofing: Subscriber Records and Exception Handling

Every proofing decision needs a paper trail, and SP 800-63A treats this as a compliance requirement rather than a best practice. Subscriber account records must capture enough detail for a relying party or auditor to reconstruct exactly how an identity was proofed.

At minimum, each subscriber account record should document:

1. Evidence types used, including which documents or credentials were presented.
2. Proofing method applied, remote unattended, supervised remote, or on-site attended.
3. The identity proofing details needed to support auditability and relying-party risk decisions.
4. Whether exception handling was used, and if so, what form it took.

Organizations should also consider explaining their proofing process and data practices to applicants.

Exception handling deserves particular attention because some applicants may not be able to meet standard identity evidence requirements. NIST’s guidance requires a documented, formal exception process, often built around trusted referees or applicant references, individuals who can vouch for an applicant’s identity through an alternative, auditable chain of trust. Accounts processed through exception handling should be clearly flagged in subscriber records so relying parties can factor that into their own risk decisions.

Pro Tip: Record when an exception process was used in the subscriber’s account record, so relying parties can make informed risk decisions.

Building an IAL2 Workflow Without Losing Applicants

Meeting IAL2 requirements and keeping completion rates healthy are not opposing goals, but they require deliberate flow design rather than bolting security checks onto an existing onboarding screen.

A practical starting checklist:

• Publish a clear evidence checklist before applicants start, so they know exactly what document types and formats are acceptable.
• Use progressive disclosure, asking for sensitive information only at the step where it becomes necessary rather than front-loading every field.
• Build multi-vendor failover into document and biometric validation, so a single vendor outage or false rejection does not block legitimate applicants.
• Design a fallback rescue flow, routing applicants who fail automated checks into supervised remote review rather than a dead end.
• Monitor completion and exception rates continuously, not just at launch, since fraud patterns and applicant populations both shift over time.

NIST’s customer experience guidance frames this directly: balancing security with usability means giving applicants clear expectations and a transparent exception path, which reduces abandonment without weakening the proofing standard itself.

A workflow worth tracking: the share of applicants who reach the evidence-upload screen but abandon before completing verification is one of the clearest signals that a flow’s friction exceeds what its assurance level actually requires, and it is worth measuring alongside fraud-detection effectiveness and exception incidence as a standing operational metric.

What Fraud Teams Should Prioritize First

If we had to rank priorities for a team building or revising an IAL2 program, documentation comes first, not because it is glamorous, but because an undocumented process cannot be audited, defended, or improved. Pair that with a privacy risk assessment done before deployment, not after a regulator asks for one.

Layered biometric and presentation-attack controls matter more than any single vendor’s marketing claim about accuracy. Exception handling and multiple proofing paths are not a concession to security, they are what keeps a program equitable without lowering its assurance bar. Finally, treat vendor evaluation and federation readiness as ongoing work, since the identity evidence landscape, mobile driver’s licenses especially, is still shifting fast.

— Carlos Ochoa

Deepen Your Proofing Program With Fraud Signals News

We cover the operational reality behind standards like SP 800-63A: what breaks in production, which presentation attacks are defeating weak liveness checks right now, and how fraud teams at banks, fintechs, and healthcare platforms are closing the gaps. Our reporting goes beyond the normative text into the day-to-day decisions that determine whether a proofing program actually resists fraud.

A good next step is our guide on why biometrics satisfy compliance requirements, which expands on biometric binding and operational controls referenced above. We also recommend:

• Why biometrics reduce bank fraud: a 2026 guide for fraud-reduction metrics tied to biometric adoption.
• Prevent a biometric breach for operational privacy controls.
• For organizations evaluating assurance-based identity platforms, DAON is worth reviewing as an established option in this space.

Read our full coverage, and check back as SP 800-63A implementation guidance continues to evolve.

FAQ

What is the difference between NIST 800-63A and 800-63B?

SP 800-63A governs identity proofing and enrollment, confirming who an applicant is before a credential is issued. SP 800-63B governs authenticators and how someone proves control of that credential afterward, so the two address separate stages of the identity lifecycle.

Does IAL2 require in-person identity verification?

No, IAL2 permits remote proofing when appropriate controls are in place, including document validation, biometric binding, and presentation-attack detection. On-site attended proofing becomes a requirement only at IAL3.

What counts as acceptable identity evidence under SP 800-63A?

Accepted evidence includes state-issued driver’s licenses, U.S. passports, mobile driver’s licenses, and federal credentials like PIV and CAC cards. Each must be validated against an authoritative source rather than accepted on visual inspection alone.

How should organizations handle applicants who lack standard identity evidence?

SP 800-63A requires a documented exception-handling process, commonly using trusted referees or applicant references to vouch for identity through an alternative, auditable path. These exception-processed accounts should be flagged in subscriber records so relying parties can factor that into their own decisions.

What must be recorded in a subscriber account under NIST 800-63A?

Subscriber account records must capture the evidence types used, the proofing method applied, the maximum IAL achieved, and whether exception handling was involved. NIST requires this detail to support auditability and give relying parties the information they need for their own risk decisions.

Recommended

• Stop Replay and Injection Fraud: NIST Aligned Liveness for Fraud Teams
• Halt Deepfakes: HL7/NIST Patient ID Verification for Health Admins
• Synthetic Identity Detection Ops Playbook: NIST Proofing, Link Signals
• Customer Identity Proofing Explained for Compliance Leaders