Identity proofing is the process a system uses to establish that a person is who they claim to be before granting them access to a service, issuing a credential, or recording a legal action in their name. It is distinct from authentication, which confirms that a returning user is the same person who previously enrolled. And it is distinct from authorization, which determines what an authenticated, proofed individual is permitted to do. Government IT leaders who conflate these three often discover the confusion in the wrong place: after a fraud incident, or after building an enrollment flow that collects far more personal information than the service actually requires.
This post covers what identity proofing is, why the level of assurance required varies by service, how NIST Special Publication 800-63A structures those levels, how mobile driver's licenses (mDLs) and verifiable credentials fit into the picture, and what implementation decisions flow from getting the calibration right.
Before getting into assurance levels, it helps to keep the three concepts separate, because systems that blur them tend to either over-collect data or under-protect services.
Identity proofing happens once (or periodically) and answers the question: is this person who they say they are? It involves collecting evidence, validating that evidence against authoritative sources, and verifying that the person presenting the evidence is the same person the evidence describes.
Authentication happens repeatedly and answers a narrower question: is this the same person who was proofed during enrollment? Authentication relies on something the user has, knows, or is. A strong authentication method does not re-prove identity; it confirms continuity with the prior proofing event.
Authorization happens at every transaction and answers: what is this authenticated person allowed to do, see, or change? Authorization decisions can depend on identity, on role, on the sensitivity of the data, or on some combination of these.
A state agency building a new benefits portal needs all three layers. Where things go wrong is when the proofing bar is set to match the authentication mechanism rather than the actual risk of the service. A resident checking on a low-stakes appointment status does not need the same proofing rigor as a resident requesting a duplicate birth certificate or updating direct-deposit banking information. Calibrating each correctly means understanding what NIST's guidelines actually say about the levels.
For a deeper look at where authentication ends and identity proofing begins, SpruceID's explainer on the difference between authentication and identity proofing covers the practical boundary between the two.
NIST SP 800-63A (Digital Identity Guidelines: Enrollment and Identity Proofing) defines three Identity Assurance Levels (IALs). These are not tiers of feature sophistication. They describe the level of confidence a relying party can have that the identity presented corresponds to a real, living person.
IAL1 requires no identity proofing of real-world identity. The user self-asserts who they are. A state agency accepting IAL1 enrollment accepts that the person may not be who they claim to be. For services where that risk is acceptable (anonymous feedback forms, low-stakes informational accounts), IAL1 is appropriate. Applying higher proofing to low-risk interactions is not more secure; it is friction that drives residents away from digital services without reducing meaningful fraud exposure.
IAL2 requires evidence of identity, validation of that evidence against an authoritative source, and verification that the person presenting the evidence is the person it describes. Remote IAL2 is possible and is now the dominant model for government digital services that handle moderate-risk transactions: Medicaid enrollment, professional license applications, voting registration in some states, unemployment claims. It typically involves document capture, automated validation against issuing-authority records, and a liveness check. The liveness check and the document match serve different functions: liveness confirms the person is present and not a photograph or mask; facial matching confirms the live person matches the document photo. Conflating the two in a procurement spec is a common error.
IAL3 requires in-person or supervised remote proofing with a trained operator. It is appropriate for services involving high-value benefits, identity documents themselves (issuing a passport or Real ID), or access to systems with significant security implications. The bar is high by design. Very few routine government digital services need IAL3, and requiring it broadly creates exclusion effects for residents who cannot reach a physical office.
The practical guidance: map your services to their actual risk profile before specifying proofing requirements. Many agencies default to a single proofing level across all services, which either over-burdens low-risk transactions or under-protects high-risk ones.
Remote identity proofing has matured considerably over the past several years, and the current NIST framework accounts for both supervised and unsupervised remote proofing paths. Understanding what "remote" entails operationally matters because the term often appears in RFPs without adequate specification.
At IAL2 via remote unattended proofing, a resident typically:
1. Presents an identity document (a state-issued driver's license, a passport, or in some implementations a mobile driver's license); 2. Has that document validated against the issuing authority's records or against document-authentication services; 3. Completes a liveness check that establishes they are physically present; 4. Has their live image compared against the photo on the document.
The steps sound sequential and automated, but the failure modes are worth understanding. Document validation confirms the document is genuine and matches records; it does not confirm the document belongs to the person presenting it. Liveness detection addresses presentation attacks (photos, masks, deepfakes) but the assurance it provides depends heavily on the algorithm and whether it has been tested against adversarial inputs. Facial matching ties the live person to the document, but matching accuracy varies by demographic group, and a government program has obligations that a commercial service does not when those variances affect benefit access.
Agencies evaluating remote proofing vendors should ask specifically about demographic performance data across all three components, not just aggregate accuracy rates. They should also ask how failure states are handled: a resident who cannot complete automated proofing should have a supervised alternative rather than simply being denied service.
SpruceID's comparison of remote and in-person identity proofing goes into more detail on when each pathway is appropriate and how to design escalation paths between them.
This distinction is worth its own treatment because procurement language often combines them, and the failure modes are different.
Liveness detection answers: is this a live human being presenting now, or a static artifact being replayed? It guards against photograph attacks, screen replays, and (increasingly) AI-generated video. Liveness alone tells you nothing about who the person is.
Facial matching answers: does the live image match the reference photo on the identity document? It guards against the wrong person using a genuine document. Facial matching alone, without liveness, can be defeated by holding up a photo of the document's legitimate owner.
A complete remote proofing flow needs both, sequenced correctly. A system that only performs facial matching can be bypassed with a high-quality photograph. A system that only performs liveness detection confirms a live person is present without knowing which person it is.
For agencies specifying remote proofing requirements, SpruceID's breakdown of liveness checks versus facial matching provides a vendor-evaluation framework grounded in the distinct security objectives of each component.
A mobile driver's license (mDL) issued under ISO/IEC 18013-5 is a digitally signed credential stored on the holder's device. When a resident presents an mDL to a government system, the verifying system can confirm:
- the document was issued by a recognized state DMV; - the cryptographic signature is valid and the document has not been tampered with; - the data fields the resident chose to disclose match what the issuing state records.
This changes the proofing workflow in a meaningful way. An mDL-based presentation is not a photograph of a document; it is a cryptographically bound assertion from the issuing authority. The authenticity question (is this document genuine?) is answered by the cryptographic chain, not by document-authentication image analysis. This raises the assurance floor for the document-validation component of IAL2 remote proofing.
Selective disclosure matters here too. An mDL can be configured to release only the attributes the verifier actually needs. A service confirming that a resident is over 18 does not need their full name, address, or license number. A service confirming state residency does not need date of birth. This is not just a privacy convenience; it is a data-minimization requirement that reduces the attack surface if the verifying system is later compromised. How selective disclosure works in verifiable digital credentials covers this mechanism in detail.
Verifiable credentials more broadly, including credentials issued using the W3C Verifiable Credentials Data Model, follow the same general model: cryptographic proof of issuer, holder binding, and selective disclosure. A verifiable credential issued after a completed IAL2 proofing event can carry that assurance level forward into subsequent interactions, allowing a resident to re-use a prior proofing event rather than re-proving identity from scratch each time they access a new service. This is the architecture behind credential reuse, and it becomes increasingly valuable as agencies build interconnected service portfolios rather than siloed applications.
For background on how verifiable credentials work before applying them to identity proofing, How Do Verifiable Digital Credentials Work? A Non-Technical Explanation provides the foundation.
Two state programs illustrate how these concepts translate into deployed infrastructure.
California's mDL program, in which SpruceID has been involved as a technology provider, makes the state-issued digital driver's license available to residents as a cryptographically verifiable credential on their mobile device. When a resident presents their mDL to a participating verifier, the presentation is device-bound and cryptographically signed, addressing the document-authenticity component of remote proofing without relying on image-based document analysis.
Utah's State-Endorsed Digital Identity (SEDI) program takes a different approach, focusing on creating a state-endorsed trust framework that allows multiple identity providers to operate within a common governance structure. SpruceID provided input to the Utah SEDI RFI on how identity assurance levels should be defined within the framework and how credential portability can be preserved across providers. The SEDI model is notable because it tries to solve the governance problem alongside the technical one: not just what credential format to use, but which entities are authorized to make identity assertions at which assurance levels, and how those assertions can be accepted by state agencies across programs.
SpruceID's explainer on State-Endorsed Digital Identity covers the SEDI framework and what the Utah model means for other states considering similar approaches.
The most consequential identity proofing decision a government IT leader makes is not which vendor to select or which credential format to require. It is the risk calibration that precedes procurement: which services genuinely require IAL2 or IAL3 proofing, which can accept IAL1 with appropriate service design, and which should require in-person proofing as the baseline.
Getting this calibration wrong in either direction has real costs. Requiring IAL3 proofing for a service that only warrants IAL2 remote proofing excludes residents who cannot make an in-person visit, creates operational overhead, and may not meaningfully reduce fraud if the actual attack vectors are downstream of enrollment. Accepting IAL1 for services where benefit value or data sensitivity warrants stronger proofing leaves the program exposed to synthetic identity fraud and impersonation.
NIST's framework is a tool for making this decision systematically. But the framework does not make the decision for you. The risk analysis that maps service characteristics to assurance requirements is a policy and operational judgment, and it needs to happen before requirements are written, not after a vendor is selected.
Once the assurance level is set correctly, the implementation questions (remote versus in-person, document type, liveness specification, credential format) follow from a defined objective. Agencies that get to procurement without having made that foundational decision tend to discover ambiguity in the contract exactly where they least want it.
If you are working through identity assurance requirements for a state digital service program and want to compare approaches, SpruceID works with government teams on identity proofing infrastructure across multiple assurance levels. The underlying architecture questions are worth getting right before the system is built.
Building digital services that scale take the right foundation.
About SpruceID: SpruceID builds digital trust infrastructure for government. We help states and cities modernize identity, security, and service delivery — from digital wallets and SSO to fraud prevention and workflow optimization. Our standards-based technology and public-sector expertise ensure every project advances a more secure, interoperable, and citizen-centric digital future.
