Identity Proofing vs Identity Verification: What Each Term Means in Onboarding and Recovery

Teams buying an "identity verification" service and teams writing a NIST-aligned proofing policy are often describing different scopes with the same word, and the gap shows up later as weak account recovery and unclear assurance claims. In NIST SP 800-63A-4, identity verification is one step inside identity proofing: the step that confirms the applicant is the genuine owner of the evidence. In the identity verification (IDV) market, in anti-money laundering rules and in everyday speech, "verification" often means the whole check, and sometimes a later re-check of an existing customer. This guide maps where the terms diverge, what each meaning covers, and how that changes onboarding, step-up and recovery flows. It is for identity architects, fraud and KYC owners, and anyone writing requirements for an IDV integration. For the requirements themselves, see the NIST SP 800-63A-4 Identity Proofing (IAL) Guide; for the end-to-end pipeline and KYC context, see the Identity Proofing and KYC Guide.

Key takeaways

• In NIST terms, verification is a step, not the process. SP 800-63A-4 proofing has resolution, evidence validation, attribute validation and identity verification, followed by enrolment. Verification is only the link between the person and the evidence.
• In the market, "verification" usually means the whole flow. An IDV product that checks a document and a selfie is performing validation and verification, and sometimes resolution and fraud checks, under one label.
• Regulators use their own vocabulary. US Customer Identification Program rules talk of identity verification procedures, and UK GPG 45 scores validity and verification separately and still gives knowledge-based checks a verification score, which SP 800-63A-4 forbids for verification.
• Re-verification is a recovery decision, not a sign-in. SP 800-63B-4 lists repeated identity proofing as one account recovery method; authentication only proves possession of authenticators bound at enrolment.
• Write requirements by step, not by label. Specify which steps, which evidence strength and which verification method each flow must perform, and map vendor outputs to those steps.

The short answer

Identity proofing is the whole process of establishing that a claimed identity is real, unique and belongs to the person claiming it, ending in enrolment of a subscriber account. Identity verification has two common meanings: the narrow NIST meaning (one step of proofing, confirming the applicant is the rightful owner of the evidence) and the broad market meaning (the entire remote check, often used as a synonym for proofing). Authentication is neither: it confirms that a returning user controls authenticators that were bound to an already proofed account.

Where the terms diverge, source by source

NIST SP 800-63A-4

Section 2.1.1 sets out the sequence: identity resolution, evidence validation and attribute validation, identity verification, then enrolment once the first three succeed. Verification methods are specific: returning a confirmation code sent to a validated address, returning a microtransaction value sent to a validated account, completing an authentication and federation protocol, visual facial comparison, or automated biometric comparison against a portrait on the evidence. Knowledge-based verification (KBV) shall not be used to verify identity, although it may still feed fraud management. The result is graded as an identity assurance level (IAL1, IAL2 or IAL3), and proofing can be remote unattended, remote attended, on-site unattended or on-site attended.

UK GPG 45

The UK government good practice guide on proving and verifying identity splits checking into five parts: get evidence of the claimed identity, check the evidence is genuine or valid, check the claimed identity has existed over time, check if it is at high risk of identity fraud, and check that the identity belongs to the person claiming it. Each part is scored separately (strength, validity, activity history, identity fraud, verification) and the scores are not added together. The final part is the verification step in the NIST sense. Unlike SP 800-63A-4, GPG 45 still allows knowledge-based verification, at verification scores 1 and 2, with biometric matching under controlled conditions at the top. Confidence levels run low, medium, high and very high rather than IAL1 to IAL3. The statutory UK scheme built around certified providers calls them digital verification services; see the UK Digital Verification Services Trust Framework Guide.

US Customer Identification Program

For banks, 31 CFR 1020.220 requires risk-based procedures for verifying each customer's identity "to the extent reasonable and practicable", within a reasonable time after the account is opened, using documentary methods (such as an unexpired government-issued photo ID) or non-documentary methods (such as comparing information against a consumer reporting agency or public database). Here "verification" covers what NIST would call evidence and attribute validation, and it does not necessarily require the NIST-style link between the person and the evidence. A CIP-compliant check can therefore fall short of IAL2 if it never binds the live person to the document.

The IDV market

Products sold as "identity verification" typically bundle document authenticity checks, data checks, a selfie comparison and liveness or injection detection, and return a single pass, fail or review result. Some also offer "re-verification" or "reauthentication" by selfie for existing customers, which compares a new face capture to the one stored at onboarding. That later check is neither a full proofing event nor an authenticator in the SP 800-63B sense unless it is designed and assessed as one. Product names and result codes vary; map each output to the NIST step it actually evidences.

Why the difference matters: threat models

Threats to proofing as a whole

The threats are synthetic identities (resolution failure), forged or altered documents (evidence validation failure), stolen real identity data (attribute validation passes, verification must catch it) and impostors using a real person's genuine document. Remote unattended flows add injected video and virtual cameras, which SP 800-63A-4 requires CSPs to detect. A programme that buys "verification" without specifying resolution and attribute validation can pass a genuine document held by the wrong person, or a consistent synthetic identity, depending on which checks the product actually ran. The Deepfake-Resistant Identity Verification Guide covers the media attacks in depth.

Threats to re-verification

Re-verification happens after enrolment: account recovery, a high-risk change such as a new payout account or phone number, or an assurance upgrade. The attacker here is usually targeting an existing account, so the questions are different. The attacker may already hold the customer's personal data from breaches, may control the email or phone used for confirmation codes, and may call a help desk instead of using the app. According to the attackers' own account relayed in the MGM Resorts Breach 2023, they found an employee on LinkedIn and called the IT help desk posing as that person; MGM has not confirmed the details. Whatever the specifics, it shows the danger of re-verification that relies on facts an attacker can look up.

Failure modes when the terms are confused

• Assurance overclaim: a vendor "verified" result is recorded as IAL2 although no attribute validation against an authoritative source took place.
• KBV in recovery: a help desk "verifies" a caller with date of birth and postcode, which SP 800-63A-4 would not accept as verification at onboarding, let alone recovery.
• Selfie re-check treated as authentication: a face match against the onboarding portrait is used as a login factor without the presentation attack and injection controls an authenticator needs.
• Recovery weaker than onboarding: proofing at IAL2 followed by recovery through an email link, so the effective assurance of the account is the weaker of the two.
• Repeated full proofing for every change: forcing customers to repeat document capture for minor changes, which drives abandonment and teaches staff to bypass the flow.

How the distinction changes onboarding versus re-verification flows

Two rules from SP 800-63B-4 shape recovery design. Accounts that were never identity proofed cannot be recovered by re-proofing: they must use a saved recovery code, an issued recovery code or a recovery contact. For proofed accounts, CSPs should support recovery by repeating a portion of the proofing process, which means the proofing evidence and verification method used at onboarding need to be recorded well enough to repeat. SP 800-63A-4 also asks CSPs to document the conditions that require reverification, naming account recovery and account abandonment as examples. The Account Recovery and Help Desk Security Guide covers the operational side.

Where authentication takes over

Proofing ends at enrolment, when the CSP creates the subscriber account and binds one or more authenticators to it. From then on, the verifier confirms the binding of authenticators to the account and that the account is active. SP 800-63A-4 recommends that CSPs encourage subscribers to bind at least two separate authenticators, which reduces how often recovery, and therefore re-verification, is needed. The practical consequence is that the strength of authenticators bound at enrolment matters as much as the proofing itself: a carefully proofed IAL2 account protected only by an SMS code is effectively as strong as that code. See the NIST SP 800-63B-4 Authenticator Assurance Levels Guide.

Decision guidance

• Writing an RFP or contract: list the NIST steps (resolution, evidence validation, attribute validation, verification) and fraud checks individually, and ask the vendor to say which it performs, with which sources, and what result each produces. Do not accept "verified" as a single field.
• Claiming an assurance level: record the evidence strength, validation method and verification method per applicant, so an IAL claim can be evidenced. A GPG 45 profile and a NIST IAL are not interchangeable; map them explicitly if you need both.
• Regulated onboarding: a CIP or KYC "verification" may satisfy the regulator without meeting an IAL. Decide whether you also need the person-to-evidence link for fraud reasons, and design for the stricter of the two. The Identity Verification Requirements Map covers jurisdictions.
• Recovery design: match recovery strength to the account's assurance. If onboarding was IAL2, offer repeated proofing or recovery codes, and remove KBV-only recovery.
• Small organisations: a single IDV integration for onboarding plus recovery codes and two bound authenticators covers most needs. Large or regulated organisations need a step-level evidence record and a policy for when to re-verify.

Worked scenarios

Scenario 1: fintech onboarding

A lender integrates an IDV product returning "verified" for document plus selfie. Mapping the product's outputs shows evidence validation and verification by automated biometric comparison, but no attribute validation against an authoritative source and no resolution check across existing customers. The lender adds a credit reference data check and a duplicate-identity check, stores per-step results, and records IAL2 only where all steps pass. CIP obligations are met by the data check and document; the IAL2 claim rests on the full set.

Scenario 2: workforce help desk recovery

An employee loses their phone. Previously the help desk asked for employee number and manager name, which are discoverable. The new flow treats this as re-verification: the employee completes a remote attended video session in which the agent compares the employee's face to the portrait on the government ID validated at hiring, then binds a new phishing-resistant authenticator. Employees who registered two authenticators at enrolment use the second one and never reach the help desk. The Workforce and Help Desk Identity Verification Buyer's Guide covers tooling choices.

How to implement: phased approach

1. Build a glossary: adopt the SP 800-63A-4 step names internally, with a column for the vendor's and regulator's names for each.
2. Map current flows: for onboarding, upgrade, recovery, high-risk change and refresh, record which steps actually run and with which evidence.
3. Map vendor outputs: for each result code, record which step it evidences; ask the vendor where unclear.
4. Fix recovery first: remove KBV-only recovery, add recovery codes and second authenticators, and define when repeated proofing is required.
5. Pilot: run the revised flows for a segment, comparing completion rates and early-life fraud against the old flow.
6. Roll out and keep evidence: store per-step results long enough to support recovery, audit and assurance claims, within data protection limits.
7. Rollback: keep the previous flow configurable per segment so a vendor outage or high false rejection rate can be handled without dropping to KBV.

Detection and measurement

• Per-step pass and fail rates: resolution, evidence validation, attribute validation and verification separately, not one "verified" rate.
• Recovery method mix: share of recoveries by method; a high share of help desk recovery signals weak re-verification.
• Account takeover after recovery: compromises within 30 days of a recovery event.
• Early-life fraud: fraud on accounts opened in the last 90 days, by onboarding path.
• Assurance evidence completeness: share of accounts claimed at IAL2 with all step results stored.
• Accounts with two bound authenticators: a leading indicator of fewer recoveries.

Framework mapping

Practitioner checklist

• Adopt NIST step names internally and map vendor and regulator terms to them.
• Never record a vendor "verified" result as an IAL without step-level evidence.
• Remove knowledge-based checks as the means of verification in onboarding and recovery.
• Define in writing which events trigger re-verification, including recovery and abandonment.
• Make recovery at least as strong as onboarding for the account's assurance level.
• Encourage two bound authenticators at enrolment to reduce recoveries.
• Keep per-step proofing records sufficient to repeat part of proofing at recovery.
• Treat selfie re-checks as a designed control with liveness and injection detection, not as a login factor by default.
• Report per-step pass rates and post-recovery takeover, not a single verification rate.

Standards and references

• NIST: SP 800-63A-4 Identity Proofing and Enrollment
• NIST: SP 800-63-4 Digital Identity Guidelines
• NIST: SP 800-63B-4 Authenticator Event Management and Account Recovery
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• GOV.UK: How to prove and verify someone's identity (GPG 45)
• GOV.UK: UK digital identity and attributes trust framework
• eCFR: 31 CFR 1020.220 Customer identification program requirements for banks

Related NHI Mgmt Group resources: NIST SP 800-63A-4 Identity Proofing (IAL) Guide · Identity Proofing and KYC Guide · Identity Verification Buyer's Guide · Customer IAM (CIAM) Guide · Account Recovery and Help Desk Security Guide