What is identity proofing? NIST 800-63 in plain English

Identity proofing is the process of establishing that a claimed identity belongs to a real person, and that the person presenting it is that person. It happens before a credential is issued or a sensitive request is granted. Authentication is the separate step that later checks whether someone still controls a credential they were already given.

The two get confused constantly, and it is an expensive confusion. Authentication answers “is this the same account holder as last time.” Proofing answers “who is this, actually.” An attacker who has taken over an account passes authentication every time.

The standard everyone cites

The reference document is NIST Special Publication 800-63, Digital Identity Guidelines. Revision 4 was finalized in July 2025, after a four-year process and roughly 6,000 public comments (NIST, 2025). If you are working from a summary written before that, it describes the previous revision.

800-63 splits into three volumes, and the split matters because the three are routinely mixed up:

When someone says “we’re NIST compliant,” ask which letter they mean. A high AAL says the credential is strong, and leaves two questions open: whether the person who received it was ever correctly identified, and what happens when it gets reset.

Identity proofing is IAL. That is the subject of this page.

What proofing actually consists of

800-63A breaks proofing into steps that are worth separating, because vendors compress them and the compression is where accuracy gets lost.

Resolution narrows a set of attributes down to a single unique person within a population. Two employees named James Whitfield resolve to different identities.

Validation establishes that the evidence presented is genuine and accurate: the driver’s license is a real driver’s license, and that the data on it matches what the issuing source holds.

Verification establishes that the evidence belongs to the person presenting it, rather than to someone whose document they are holding.

Validation and verification are different questions and a product can be good at one and weak at the other. A document reader that inspects security features is doing validation. Confirming the presenter is the subject is verification. Keep them apart when you evaluate anything.

The three identity assurance levels

IAL1

The proofing process supports the real-world existence of the claimed identity and provides some assurance that the applicant is associated with it. Core attributes may be obtained from identity evidence or self-asserted by the applicant (NIST SP 800-63A-4).

Self-asserted is the operative phrase. IAL1 is appropriate where the consequence of being wrong is low.

IAL2

IAL2 adds evidence, validation, and verification requirements specifically to mitigate impersonation attacks and proofing errors relative to IAL1 (NIST SP 800-63A-4).

Two properties of IAL2 are widely misunderstood and both are worth knowing before a vendor conversation.

IAL2 can be done remotely. Revision 4 states that IAL2 proofing “MAY be delivered through any identity proofing type,” which includes remote unattended and remote attended (NIST SP 800-63A-4). Remote does not mean lower assurance here.

IAL2 does not require biometrics. The standard is explicit: “identity verification at IAL2 can be accomplished with or without the use of biometrics,” and it defines an IAL2 Non-Biometric Pathway that “provides verification methods that do not use an automated comparison of biometric samples provided by the applicant” (NIST SP 800-63A-4).

A great deal of vendor material implies the opposite, that a face match is what makes proofing strong. The standard provides a pathway reaching the same assurance level without collecting a biometric sample at all.

IAL3

IAL3 proofing “SHALL only be delivered as on-site attended.” A trained proofing agent must attend the session, either co-located with the applicant or through a provider-controlled kiosk or device (NIST SP 800-63A-4).

This is the level people reach for rhetorically and rarely implement. On-site attended proofing means physical logistics for every user, which is why IAL3 is reserved for genuinely high-consequence populations. Any vendor claiming IAL3 for an unattended remote flow is describing something the standard does not permit.

For most workforce and customer scenarios, IAL2 is the target. ATO Protect verifies to NIST IAL2.

Where document-and-selfie proofing breaks

The dominant remote proofing pattern for the last decade has been: scan a government ID, take a selfie, compare the two, and run a liveness challenge to confirm a live human is present. It worked well against the threat it was designed for, which was a person holding someone else’s physical card.

Generative AI changed the inputs to that flow, and each layer fails differently.

The document. Synthetic and manipulated identity documents are cheap to produce and are getting harder to spot by inspection. A validation step that only examines the artifact is examining something an attacker fully controls.

The selfie and the liveness check. This is the layer that has degraded fastest. Injection attacks feed synthetic video directly into the capture pipeline, bypassing the camera entirely, so the “live” frame the system evaluates was never captured by a camera at all. In a 2025 iProov study of 2,000 US and UK consumers, only 0.1% correctly identified every real and fake sample, and high-quality deepfake video was caught 24.5% of the time even when participants were told to look for fakes (iProov, 2025).

The human fallback. When automated proofing fails, and it fails often for legitimate users with worn cards or poor lighting, the flow escalates to a person. That person is a help desk agent under handle-time pressure, listening to a voice. Mandiant found voice phishing involved in 23% of cloud intrusions, the leading vector in that category, and 11% of intrusions overall (Mandiant, M-Trends 2026).

The pattern across all three is the same. Each layer asks a computer or a person to judge whether something looks real, and generative models are now good at controlling exactly how things look.

Judging appearance versus querying a source

The alternative is to stop assessing the artifact and query the authority behind it.

A driver’s license works as a pointer to a record held by the state that issued it, more than as a picture. Confirming that the record exists and matches is a different class of check from deciding whether the card looks genuine, because the attacker does not control the state’s database.

In the United States, that check runs against state DMV records over the AAMVA network. A forged document has no matching record, and the quality of the forgery becomes irrelevant. This is validation against an authoritative source rather than against the evidence itself, and it is what 800-63A’s validation step is reaching for.

Two more signals strengthen the verification half without collecting a biometric:

SIM swap and port-out detection. The mobile network operator knows if a number moved to a new SIM recently. A number that changed hands the same day as a password reset request tells the agent more than anything else available in that conversation.

Man-in-the-middle and anti-replay detection. These confirm the session is live and direct rather than relayed or replayed from an earlier capture, the mechanism behind most injection attacks. Trusona’s implementation is patented (US Pat. 10,601,859).

That is what makes the no-selfie position a design decision. ATO Protect runs no liveness challenge, because generative AI defeats those, and the standard provides for verification at IAL2 without an automated biometric comparison.

The gap between proofing at onboarding and proofing at recovery

Assurance levels do not describe this problem, and it is where most real losses occur.

800-63A governs proofing at enrollment. That is when organizations take it seriously: a new employee or customer goes through document checks, background screening, and an identity flow that someone designed carefully and can point to during an audit. The assurance level is documented and defensible.

Then the person is issued a credential, and from that moment on the organization stops proofing and starts authenticating. That is the correct design, right up until the credential stops working.

At that point the user needs account recovery, and recovery is proofing again. The organization has to re-establish who this person is, because the credential that used to answer the question is unavailable. Recovery is very often handled at a far lower assurance level than the original enrollment: a help desk call, a few knowledge questions, a code to an alternate address that may itself be compromised.

An organization can proof at IAL2 on day one and recover at something closer to IAL1 for the rest of the relationship. The effective assurance of the account is set by the weakest path into it, and attackers pick paths.

This is why account recovery deserves the same proofing rigor as onboarding, and why the population that cannot complete a standard recovery flow matters so much. “I can’t use my MFA” is both the most common legitimate support request and the standard opening line of the attack.

Choosing a level

A short version of the reasoning:

Most organizations reading this are looking at IAL2 for the help desk and for customer account recovery. Those are the requests that move money and grant access, and they are the requests attackers make.

One more consideration that the levels do not capture: proofing is worth very little if it can be skipped. Every proofing deployment has an override path for when the flow fails. If that override is a phone call to a person who can approve a reset on their judgment, the effective assurance level of the system is the assurance level of that phone call, whatever the vendor’s datasheet prints.

Identity proofing is the control that decides who gets a credential and who gets it back. ATO Protect verifies a person’s government-issued ID against the authority that issued it, in real time, to NIST IAL2, with no selfie, no liveness challenge, no pre-registration, and no PII retained after the session. See ATO Protect use cases, or Premium IDV for the layer-by-layer version of why legacy proofing is breaking.

Frequently asked questions

What is identity proofing? Identity proofing is the process of establishing that a claimed identity corresponds to a real person and that the person presenting it is that person. It covers resolution (narrowing to one unique identity), validation (confirming the evidence is genuine), and verification (confirming the evidence belongs to the presenter).

What is the difference between identity proofing and authentication? Proofing establishes who someone is, usually before a credential is issued or a sensitive request is approved. Authentication checks whether someone controls a credential they already hold. Authentication cannot detect an attacker who has taken over the account, because the credential is valid.

What are the NIST identity assurance levels? IAL1 supports the real-world existence of a claimed identity and permits self-asserted attributes. IAL2 adds evidence, validation, and verification requirements to mitigate impersonation, and may be delivered remotely. IAL3 requires on-site attended proofing by a trained agent. They are defined in NIST SP 800-63A, part of SP 800-63 Revision 4, finalized July 2025.

Does IAL2 require a biometric or a selfie? No. NIST SP 800-63A-4 states that identity verification at IAL2 can be accomplished with or without biometrics, and defines a non-biometric pathway using verification methods that do not perform automated comparison of biometric samples.

Can IAL2 identity proofing be done remotely? Yes. Revision 4 permits IAL2 proofing through any proofing type, including remote unattended and remote attended. IAL3 is the level that requires on-site attendance.

What identity assurance level does ATO Protect reach? ATO Protect verifies to NIST IAL2, delivered remotely and without an automated biometric comparison, both of which SP 800-63A-4 permits at that level.

Why is document-and-selfie proofing losing effectiveness? Each layer evaluates appearance. Synthetic documents are cheap, injection attacks feed generated video past the camera into the capture pipeline, and the human fallback is a help desk agent judging a voice that may be cloned. Verification against an authoritative source does not depend on how convincing the artifact looks.

Proofing runs before trust is granted, which is what makes it worth the effort. Get it wrong and every control downstream is protecting the wrong person.