Skip to content

Build1 publisher2 min readPublished

NIST's revised SP 800-63A defines six expected outcomes of identity proofing

The identity proofing volume of NIST's digital identity suite lists six outcomes an enrollment flow has to produce, and each one is written as a check that can pass while another fails.

The Engineer · Build desk

What happened

  • The abstract of NIST SP 800-63A states that the publication supersedes NIST Special Publication 800-63A, and that it defines technical requirements for each of three identity assurance levels.
  • The guidance enumerates six expected outcomes of identity proofing, running from identity resolution through evidence and attribute validation, identity verification and identity enrollment.
  • Scope covers federal agencies, third-party credential service providers and other organizations that provide or use identity proofing services, whether proofing happens over a network or in person.

Compiled by The EngineerSomething wrong?How this is made

Why it matters

  • constraint Resolution is bounded to the population a provider already serves, so a dedupe design has to be unique inside one subscriber set and does not have to reach across providers to satisfy the outcome.
  • decision Teams onboarding organizations get no requirements from this volume, because subject and person are restricted to natural persons, and a business-verification design needs a different authority.
  • exposure Fraud mitigation is its own outcome and demands detection, response and prevention of access using a fraudulent identity, which puts an ongoing obligation on the provider well past the enrollment event.
  • precedent A service that does no proofing now has a named tier to declare, with the condition that any attribute validation it does elsewhere in the business is not counted as a gate on access.

Identity resolution comes with a scope qualifier, and the qualifier decides how much engineering it costs. The document defines that outcome as determining that the claimed identity corresponds to a single, unique individual within the context of the population of users served by the credential service provider or online service [7]. That uniqueness only has to hold within that population: deduplication has to work inside your own subscriber set, and the outcome asks nothing about whether the same person is already enrolled somewhere else.

Three of the outcomes are separate checks that one submitted document can pass unevenly. Evidence validation confirms that the supplied identity evidence is genuine, authentic, and accurate [8]. Attribute validation confirms the accuracy of the core attributes [9]. Identity verification confirms that the applicant is the genuine owner of the presented evidence and attributes [10]. A pipeline that authenticates a passport image and matches the name and date of birth against a source of record has produced the first two; binding the person in the session to that passport is a third requirement with its own name.

Core attributes are defined as the minimum set of attributes required to complete identity proofing and provide services [9], and the guidance pairs the outcomes with privacy-enhancing principles such as data minimization plus usability practices that reduce the burden on applicants [14].

The examples the document gives of activity that needs a reliable link to a real person include executing financial transactions, meeting the financial industry's Customer Identification Program requirements, and changing the release rate of water from a dam [19].

The level enumeration begins with a tier called no identity proofing, where there is no requirement to link the applicant to a specific real-life person, evidence collection is not required, and identity verification is not conducted [16]. Attributes may still be validated as part of other business processes at that tier, and validation is simply not required for access [17]. At IAL1, core attributes are obtained from identity evidence or self-asserted by the applicant [18], and all core attributes are validated against authoritative sources; the retrieved text breaks off mid-word at that point [23].

The published text does not carry a change list. Its version history is a single sentence in the abstract saying the publication supersedes NIST SP 800-63A, with no statement of which requirements moved [2][22]. Each successive IAL builds on the requirements of the levels below it [15], so a requirement that changed at IAL1 changed at IAL2 and IAL3 as well. The page carries a date of 26 August 2025 and no compliance deadline [20][22].

What to watch

  • Section 2.2, referenced by the IAL1 text as the definition of core attributes, is not in the retrieved page.
  • The companion volumes SP800-63, SP800-63B and SP800-63C, which carry the authenticator and federation requirements paired with this one.
  • Whether federal audit programs begin citing the six outcomes individually instead of citing an IAL as a whole.
Loading claim ledger
Loading source directory links
Loading share composer
Loading topic controls
Loading related stories