Why image-based checks need reinforcement
Remote identity proofing often combines a document image, a photo or video of the applicant, and checks against external records. Generative AI makes forged media and impersonation a more serious challenge, but it does not make every document-based process obsolete. NIST's current guidance explicitly addresses injected and manipulated media, genuine-source checks, and error handling. The operational lesson is to test what the system actually validates. Does it inspect pixels, verify evidence against the issuer, establish that the applicant controls the credential, or combine those checks?
A convincing image must not become the only evidence supporting a high-consequence decision. Equally, a tool that blocks more applicants is not necessarily a tool that detects more fraud. NIST SP 800-63-4: Digital Identity Guidelines.
DHS's Remote Identity Validation Rally provides a useful testing reference: the program facility describes tracks for presentation-attack detection, identity-document validation, and selfie-to-document matching. Those tests address different components of proofing; performance on one should not be represented as proof that the entire identity service is secure. RIVR program.
What a cryptographic credential actually proves
A signed digital credential changes part of this problem. Generating an image of a driver's license does not generate a valid issuer signature. The issuer's private signing key belongs to the issuing infrastructure; a holder's device key, when used, is a separate key proving possession or binding to that device. Conflating the two obscures the security model. Mobile driver's license standards and implementation profiles define how evidence is presented and checked; NIST SP 800-63A-4 addresses proofing, while SP 800-63B-4 addresses authentication. A valid signature alone cannot prove that issuance was honest, that a device is uncompromised, or that a benefits claim is accurate.
H.R. 7270 proposes federal support for digital identity work; introduced bill language should not be treated as enacted funding or a procurement mandate. The strength of the credential depends on the entire enrollment, issuance, presentation, validation, and recovery chain.
California illustrates shared identity infrastructure
California's Identity Gateway illustrates the shared-infrastructure approach. It existed before July 2026, including transit-discount use cases; CDT's June 2026 tech alert announced Digital Identity Services through the gateway effective July 1. CDT describes a vendor-agnostic service for identity and eligibility attribute verification, with consent and privacy safeguards. The alert asks interested departments to enroll and specifies a 15 percent pass-through fee on applicable vendor charges. The enrollment model leaves room for agencies to join as their use cases and integrations are ready.
Architecturally, a shared gateway can let agencies use common integrations and assurance policies while retaining responsibility for their own service and eligibility decisions.
Separate identity, authentication, and eligibility
Identity and access management contains several distinct decisions. Proofing asks who a person is; authentication asks whether the returning user controls an approved authenticator; federation conveys assertions between systems; program eligibility asks whether the verified person qualifies for a service. Treating those as interchangeable creates blind spots. A resident may have a real credential and still submit false wage information. An attacker may steal a genuine account without forging a document. Fragmented portals can duplicate sensitive records and investigations while leaving inconsistent recovery rules. A shared platform can improve consistency, but it can also concentrate outages and security exposure.
States should define minimal attribute sharing, retention, agency access rights, audit events, and fallback procedures rather than assume centralization is automatically safer.
NASCIO's 2026 priorities reflect both dimensions: identity and access management ranks seventh among policy and management priorities and fourth among technologies and tools. The ranking identifies CIO attention; it does not rank attack frequency or prove a particular procurement choice. NASCIO priorities.
Buy an operating model, not only a verification widget
The procurement choice is therefore larger than a document-scanning product renewal. A platform investment needs an accountable service owner, sustainable funding, interoperable interfaces, agency onboarding, and a staged plan for legacy systems. Existing portals can migrate incrementally; a single statewide rewrite is not a prerequisite for stronger credential verification. Ask vendors to demonstrate protection against replay, forged media, fraudulent enrollment, and recovery abuse using the population and devices the state actually serves. Independent evaluation should include both fraud resistance and the experience of legitimate residents.
Measure completion, false rejection, support demand, time to resolve an exception, and confirmed fraud by attack type. Those measures provide a stronger basis for investment than a claim that cryptography or AI detection will make fraud impossible.
Questions for the next identity procurement
Use these questions to move the vendor conversation from feature claims to the behavior of the complete service.
- Inventory every route into an account. Include initial enrollment, password reset, device replacement, help-desk recovery, and changes to payment details.
- Test the real attack paths. Evaluate forged documents, injected video, stolen genuine credentials, replay attempts, and social engineering; measure false acceptance and rejection separately.
- Validate the full trust chain. Check issuer trust, signature validity, credential status, holder binding where required, and the relying agency's intended assurance level.
- Protect legitimate residents. Provide assisted and non-smartphone options, accessible appeals, and a recovery route that does not become the weakest authentication path.
- Keep eligibility separate. Identity verification alone does not establish all current facts required for eligibility; validate income, residency or work requirements against appropriate current sources.
Test recovery with the same seriousness as enrollment
Consider a hypothetical resident who successfully enrolled with a signed credential, then lost the phone used to access the service. The help desk needs a route back into the account. An attacker may attempt that same route while claiming to be the resident. Strong initial proofing does not answer the separate question of who should be allowed to replace an authenticator.
NIST SP 800-63B-4 addresses account recovery. For procurement, ask the supplier and agency operator to walk through the complete recovery journey. The following are recommended acceptance questions:
- What evidence is required to restore access, and how does the process handle a person who cannot use the original device?
- Which employee or service can approve recovery, and what prevents that authority from being used to bypass the intended assurance level?
- How are replacement authenticators bound to the account, how are affected prior authenticators handled, and what notifications reach the legitimate account holder?
- How does a reviewer investigate a disputed recovery without exposing unrelated personal records?
- What route remains available during an outage of a shared identity provider, and what decisions should wait until assurance can be restored?
Use authorized test accounts to exercise legitimate recovery, an impersonation attempt and an unavailable dependency. Include service staff in the test, not only security specialists. A theoretically secure process can still fail its public-service purpose if authorized users cannot complete it or staff cannot resolve an exception. The answer is a controlled exception process with evidence and ownership, rather than an undocumented shortcut.
Choose what to share before choosing where to centralize
The case for shared infrastructure should specify which capabilities are shared. Agencies might share trust in approved issuers, a gateway that validates credentials, authentication services, or technical interfaces while retaining separate program records. Those choices have different operating and privacy consequences. A common gateway does not require every agency to copy every underlying identity document into one statewide repository.
For a hypothetical service that needs to know whether an applicant satisfies an age condition, ask whether the workflow can use a verified attribute rather than retaining an entire credential. Confirm that the attribute, its source and its freshness are adequate for the actual rule. A minimized response is useful only if it still supports the decision and any applicable recordkeeping obligations.
A staged integration is a credible alternative to a broad platform replacement. Start with a defined service, establish its assurance requirements, test the provider connection and retain an appropriately controlled assisted route. Expansion should depend on evidence about fraud resistance, legitimate completion and support workload. Centralization can simplify operations, but the procurement should also address provider failure, incident response and an exit path.
Make the acceptance decision visible
Require a short decision record that connects the proposed assurance level to the service's risks. It should identify the tested attack paths, legitimate-user exceptions, unresolved limitations and the agency official accepting the remaining risk. Pair security measures with service measures: attempted attacks and confirmed compromises answer different questions from successful legitimate completions, incorrect rejections and unresolved cases.
Set the review period and denominators before interpreting those measures. A higher rejection count can reflect a changed population, a different attack pattern, a stricter threshold or a broken integration. Investigate the cause before claiming a fraud reduction. Keep eligibility outcomes distinct from identity outcomes so that a genuine identity attached to an ineligible claim is not counted as an identity-proofing failure.
The next procurement meeting should end with a defined trust boundary, an owner for recovery and a test the agency can observe. That is a firmer basis for modernization than selecting a credential format and assuming the operating model will follow.
Sources and further reading
- RIVR: program evaluation tracks
- NASCIO: 2026 policy and technology priorities
- NIST SP 800-63-4: Digital Identity Guidelines
- NIST SP 800-63A-4: proofing and forged-media controls
- CDT: July 2026 Digital Identity Services launch
- CDT: Digital Identity Project and earlier deployments
- Congress: H.R. 7270 introduced text
This is the combination of AI consulting, cybersecurity, and engineering that Spartan X brings to modernization: strong evidence at the point of entry, protected data in transit, and an operating process that can resolve the cases automation cannot.
