The One Big Beautiful Bill Act (Public Law 119-21, signed July 4, 2025) requires states to verify Medicaid and SNAP beneficiary identity and program eligibility more rigorously than current processes allow. That is a legitimate policy objective. But the implementation question most states are wrestling with is more specific: how do you achieve the required level of assurance without turning identity verification into a new condition of eligibility that some people simply cannot satisfy?
The answer requires distinguishing four functions that are often collapsed in system design: identity proofing, authentication, evidence verification, and eligibility determination. These are separate problems. They require separate architecture. A system that conflates them will either under-protect the program or over-burden the beneficiary.
Identity proofing establishes that a real person exists and that the person presenting credentials is actually that person. It typically happens once, at enrollment. NIST SP 800-63A-4 defines three Identity Assurance Levels: IAL2 requires remote proofing with document verification and biometric comparison or supervised in-person proofing; IAL3 requires in-person proofing with additional controls.
Authentication is distinct: it verifies at a subsequent interaction that the person accessing a system is the same person originally proofed. NIST SP 800-63B defines Authenticator Assurance Levels for this purpose.
Evidence verification confirms that a document or data record is genuine and was issued by an authoritative source. A pay stub, a W-2, a digital credential from a state workforce agency: all must be evaluated for authenticity and accuracy. This answers "is this document real?" not "is this person who they claim to be?"
Eligibility determination is the downstream decision: given verified evidence evaluated under program-specific rules, does this person qualify?
States that treat these four functions as a single "identity verification" step will build systems that apply IAL2-level friction uniformly to transactions that may not require it.
When federal guidance emphasizes "identity verification," state teams often hear "build an identity proofing step." That is understandable, but it overstates the requirement. What most HR1 verification provisions actually require is that the state have sufficient confidence that the person claiming benefits is the person to whom the evidence applies, and that the evidence itself is trustworthy. In many interactions, a state-issued account with appropriate authentication controls can satisfy the assurance requirement without repeating a full IAL2 proofing event at every reverification.
The distinction matters because the populations most affected by Medicaid work requirements and SNAP eligibility changes are also less likely to have ready access to the documents and devices required for high-friction remote identity proofing. If states require every beneficiary to complete an IAL2-equivalent flow as a prerequisite to submitting any evidence, they will face both legal accessibility challenges and practical program administration problems.
Risk-based assurance design asks: what level of assurance is proportionate to the risk of this specific transaction?
For a first-time Medicaid enrollment where the state has no prior record and the evidence is entirely self-reported, strong identity proofing may well be appropriate. For a returning beneficiary with an existing state account, a biometric-authenticated session provides substantial assurance without repeating the proofing event. For a beneficiary submitting updated employment evidence through an assisted channel, the assurance model looks different again.
Remote and in-person identity proofing serve overlapping but not identical populations. States that design only for remote IAL2 will exclude beneficiaries without reliable internet access, smartphones, or qualifying identity documents. A well-designed system offers multiple pathways that each satisfy the appropriate assurance level for the transaction type.
Mobile driver's licenses, where available, can support identity proofing and authentication in ways that are both higher-assurance and lower-friction than traditional document-plus-selfie flows. An mDL issued under ISO/IEC 18013-5 carries cryptographic proof of issuer authority and attribute integrity. As of mid-2026, more than 20 states have active mDL programs, though integration with benefits eligibility systems remains early-stage in most jurisdictions.
Once identity assurance is handled, evidence verification requires its own architecture. Paper documents and PDF uploads can be fabricated, modified, or misrepresented, and the eligibility system has no reliable way to verify authenticity without contacting the issuing organization directly.
Medicaid work requirements represent a verification infrastructure challenge precisely because the evidence required is distributed across thousands of employers, training programs, and volunteer organizations, most of which have no data-sharing relationship with state Medicaid agencies. Direct data matches work well for large employers and federal data sources; they cover a much smaller share of the low-wage, part-time, and gig employment that characterizes the beneficiary population subject to work requirements.
Verifiable digital credentials issued by authoritative sources offer a different architecture: the issuer signs the credential at issuance, the beneficiary holds it in a digital wallet, and the state verifier confirms the cryptographic signature without requiring a live query back to the issuer. The issuer does not learn when the credential was presented. The state receives authenticated evidence of the specific claims needed, nothing more. This architecture is explored in Medicaid and SNAP Need Different Rules, Not Separate Verification Infrastructure.
This does not mean states should wait for verifiable digital credential infrastructure to mature before implementing HR1 requirements. It means systems designed today should accommodate credential-based evidence as that infrastructure becomes available, rather than locking into document-upload architectures that will require replacement.
A common framing positions accessibility as being in tension with program integrity. That framing is partially wrong. Well-designed identity and evidence systems can be more rigorous and more accessible than paper-document processes, because they eliminate manual review error, reduce processing time, and create auditable records supporting both fraud detection and beneficiary appeals. The tension is not between rigor and accessibility; it is between high-friction uniform processes and proportionate adaptive ones.
What governments actually need is a system that routes different transaction types through appropriate assurance pathways and still produces a consistent, auditable eligibility record. A beneficiary who completes remote IAL2 proofing using an mDL and submits a verifiable employment credential should arrive at the same eligibility determination as a beneficiary who completes supervised in-person proofing with a caseworker and submits paper documentation. The evidence and assurance records differ; the eligibility decision is made against the same program rules.
Separating the four functions operationally means several concrete architecture decisions.
Identity proofing should be a one-time or low-frequency event, not a requirement at each evidence submission. States with strong authentication on state-issued accounts can leverage them for ongoing authentication without repeating the proofing event.
Evidence verification should be architecturally independent from identity proofing. The state's ability to confirm that a pay stub is authentic should depend on the provenance and integrity of the document itself, not on whether the submitter completed remote or in-person proofing.
Eligibility determination should be rule-based and auditable, applied to verified evidence rather than raw documents.
Nondigital pathways must remain available and genuinely functional. HR1 does not and cannot require that all beneficiaries use digital identity tools. Assisted proofing through caseworkers, community organizations, and service centers is not a fallback for a failed digital process; it is a required channel.
States facing HR1 implementation deadlines have practical pressure to move quickly. The risk is building systems that satisfy near-term federal guidance but create problems downstream: accessibility challenges under the ADA and Section 504 of the Rehabilitation Act, inequitable burden on populations with lower technology access, and systems expensive to retrofit when guidance shifts.
The NIST Digital Identity Guidelines (SP 800-63-4), finalized in 2025, provide a useful framework for assurance levels proportionate to transaction risk. They are not mandatory for state Medicaid programs, but they represent the most authoritative framework for the design decisions states need to make.
The clearest path to a durable HR1 verification architecture treats program integrity and resident accessibility as co-requirements: design for the assurance level the transaction actually requires, use evidence integrity controls that match the evidence source, preserve multiple pathways, and build toward credential-based evidence as the infrastructure becomes available. That is not a compromise between rigor and accessibility. It is what rigorous, proportionate design looks like.
If your team is working through HR1 verification architecture and wants to discuss how to separate identity assurance from evidence verification in practice, talk with SpruceID about your program's specific design questions.
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.
