Solving for the Gap Between a Verified Identity and a Trusted Interaction

What the Login.gov findings reveal about point-in-time identity verification, and why trust must persist beyond onboarding

There is an uncomfortable truth about the act of validating an identity: it can pass every prescribed identity check and still be fraudulent.

That is the important lesson in a recent U.S. Government Accountability Office (GAO) finding about Login.gov, the federal government’s shared sign-on and identity verification service. According to GAO, Login.gov’s Anti-Fraud Team determined that suspected fraudulent accounts had passed its Identity Assurance Level 2 (IAL2) workflow. The team also warned that the sophistication of these attempts would increase and that the platform faced greater exposure without another verification layer.

The finding should not be read as proof that identity verification does not work. It shows something more precise: compliance with a proofing workflow is not the same as durable confidence in the person operating an account. Identity evidence can be valid. The attributes can resolve to a real person. A document can authenticate. A phone number can match records. Yet the applicant presenting those signals may still be an impostor, a coerced legitimate user, a member of an organized fraud ring, or an attacker using compromised identity assets.

For government agencies, financial institutions, and digital platforms, the implication is that identity cannot be treated as a one-time check. Organizations must not only determine whether the submitted data belongs to a real person; they must also establish that the person associated with that identity is actually present and in control of the enrollment or application event. That requires multiple independent signals, including cryptographic proof of possession correlated to the identity, followed by continuous evaluation as the account moves through its lifecycle.

What GAO actually found, and what it did not disclose

The GAO’s July 2026 testimony states that a May 2025 contract modification reported suspected fraudulent accounts passing Login.gov’s IAL2 workflow. Investigators reviewed the accounts and found fraud indicators (the GAO did not publish the number of accounts, the agencies or benefits involved, the loss amount, the precise signals that were defeated, or a forensic description of each attack).

The GAO did explicitly identify the broader fraud outcomes associated with compromised identity data: new-account fraud, existing-account fraud and account takeover, government-benefits fraud, and synthetic identity fraud. It also told agencies to assume that personally identifiable information such as Social Security numbers, driver’s license data, dates of birth, and addresses may already be compromised.

How a fraudulent actor can pass technically valid checks

Remote identity proofing generally performs three different jobs: 

• Resolution identifies which real-world identity is being claimed. 
• Validation determines whether the submitted evidence is genuine, current, and consistent with authoritative records. 
• Verification attempts to establish that the applicant is the person associated with that evidence.

A system can perform the first two jobs correctly and still reach the wrong conclusion on the third. The problem is not always false data, but increasingly, it is real data presented by the wrong actor. Closing that gap requires more than confirming that the data resolves to a legitimate identity. The system must establish that the rightful person is actually participating in the interaction and possesses a trusted device or cryptographic key correlated with that identity. This introduces a signal that cannot simply be reproduced from stolen personally identifiable information or a copied identity document.

The Login.gov process described by the GAO uses document authentication, identity validation against records, driver’s-license data verification, phone validation, and account authentication. Login.gov’s current fraud-control documentation also describes one-to-one facial matching with liveness detection, tenure and porting checks for phone numbers, and the exchange of downstream security events through a RISC API. These are meaningful controls, but no control should be treated as a singular source of truth, and the value of each signal depends on its provenance, independence, freshness, and resistance to attacker manipulation.

Stolen identity packages can satisfy knowledge and record checks

Criminal marketplaces do not sell isolated data points. They sell identity packages: names, addresses, dates of birth, Social Security numbers, phone information, credential images, credit-header data, and answers to common knowledge-based questions. When a workflow asks whether submitted attributes correspond to a real person, a well-assembled stolen identity may produce a technically correct match.

This is classic impersonation-based new-account fraud. The identity is real; the applicant is not the rightful owner. A record match therefore proves that the identity exists, not that the human controlling the session is entitled to use it.

Authentic documents can be presented by an unauthorized person

Document authentication is designed to detect tampering and counterfeiting. It is less decisive when the attacker possesses a genuine stolen document, has access to a high-quality image of one, or recruits a mule whose legitimate identity can be used to create an account for someone else’s benefit.

Even strong document and face checks can face presentation attacks, digital injection, manipulated capture environments, replayed media, look-alike fraud, and synthetic media. Modern liveness and injection defenses materially raise the cost of these attacks, but the defensive question cannot stop at whether an image looks real. It must also ask whether the capture originated from a trusted environment, whether the device and network history are coherent, and whether the identity has behaved consistently over time.

Phone possession is not the same as rightful identity possession

A code delivered to a phone establishes access to a communication channel at a moment in time. It does not, by itself, establish durable control by the rightful identity owner. Fraudsters can use newly activated numbers, ported numbers, SIM swaps, compromised family plans, malware, phishing and real-time code relay, call forwarding, or social engineering to gain access to that channel.

Account ownership and phone tenure checks add valuable context. Network-level signals can go further by evaluating the relationship among the person, phone number, SIM, device, and carrier history. But SMS possession should remain one input to a broader decision, not the final proof of identity.

Mule and first-party fraud can make every identity signal look legitimate

Some fraud is committed by the person whose identity is being verified. A mule may willingly open an account and surrender access, or an applicant may misrepresent eligibility while presenting completely authentic identity evidence. A legitimate beneficiary may be manipulated into authorizing a change that benefits a criminal.

No document check can solve intent, and that’s an important point of distinction. Detecting these schemes requires cross-session and cross-account intelligence: repeated device use, shared infrastructure, anomalous velocity, coordinated application patterns, unusual beneficiary changes, inconsistent geolocation, and downstream behavior that diverges from the identity’s established history.

A legitimate account can become fraudulent after proofing

IAL2 identity proofing addresses the association between an applicant and a real-world identity at enrollment. It does not guarantee that the same person controls the account tomorrow. Credential theft, phishing, session hijacking, help-desk manipulation, recovery abuse, SIM swapping, malware, and adversary-in-the-middle attacks can transfer control after a legitimate enrollment.

We can see how this functions as the boundary between identity proofing and authentication and how it operates precisely where fragmented identity systems create risk. If the high-confidence signals collected at onboarding do not inform later login, recovery, profile changes, and high-risk transactions, the trust established at the front door quickly decays.

Standards define assurance requirements, not permanent truth

NIST assurance levels provide essential structure for identity proofing and authentication. They establish requirements for evidence, verification methods, authenticators, and risk but they do not promise that a compliant workflow will produce zero fraud. Nor can they turn a point-in-time event into permanent certainty.

Attackers target the seams between controls. They look for correlated data sources that fail together, fallback paths with weaker evidence, recovery processes that bypass strong enrollment, and downstream agencies that lack visibility into what happened during authentication. The GAO noted that participating agencies had reported issues including high failure rates, insufficient visibility into authentications, and inadequate fraud controls. Those operational gaps are not separate from identity security. They affect whether risk can be observed, shared, and acted upon.

The correct response is not indiscriminately adding more friction. A universal extra challenge may block some fraud, but it also increases abandonment, support demand, accessibility barriers, and pressure to create weaker fallback routes. The goal is to increase the quality and continuity of evidence while reserving active challenges for genuinely ambiguous or high-risk events.

The need to move from point-in-time proofing to persistent identity

Prove’s view is that organizations need to make identity provable across the entire digital relationship. That requires an identity architecture capable of carrying trust forward, detecting relevant changes, and invoking stronger verification when the evidence no longer holds together.

A resilient model has five technical characteristics.

1. Resolve the person using a broad identity graph: Identity resolution should evaluate the relationships among identity attributes rather than merely confirm that each field exists. Name, address, phone, email, device, network, and historical associations should form a coherent identity. Signals should be assessed for tenure, velocity, consistency, reuse, and evidence of compromise.

This makes it harder for an attacker to assemble a passable identity from individually valid but collectively inconsistent components. It also helps distinguish a durable identity from a newly constructed or rapidly changing one.

2. Separate identity validity from applicant possession and control: Three questions should be answered independently:

1. Does this identity exist?
2. Does the submitted evidence belong to that identity?
3. Is the person associated with that identity actually present and in control of the enrollment or application event?

Prove helps answer the third question through a cryptographic possession check that confirms control of a trusted device or key and correlates that possession back to the identity being asserted. Unlike personally identifiable information, which may already be available through a breach or criminal marketplace, cryptographic possession must be demonstrated during the interaction.

Combined with network-derived signals, device continuity, identity history, and appropriate document or biometric controls, this provides stronger evidence that the rightful person, and not simply someone holding the correct data, is at the other end of the interaction.

3. Bind successful verification to phishing-resistant credentials: Once an identity has been established, that assurance should be bound to a device-held cryptographic key or passkey, not repeatedly reconstructed through passwords and SMS codes. Key-based authentication allows a service to verify possession without transmitting a reusable secret, and properly implemented passkeys resist phishing and real-time OTP relay.

SMS can remain an accessibility or recovery option, but it should not be the default trust anchor for every event. Risk-based orchestration can choose the appropriate method based on the user, device, action, and current evidence.

4. Persist and re-evaluate trust across the lifecycle: The signals used at enrollment should inform login, account recovery, profile changes, payment setup, benefits redirection, and other sensitive actions. A trusted identity is not a static badge. It is a relationship that should respond to device changes, SIM changes, credential resets, anomalous behavior, new destinations for funds, and evidence from downstream fraud investigations.

This is particularly important in government benefits and financial services, where a legitimate account may be targeted long after it is opened. Continuous risk evaluation can allow routine activity to remain low-friction while stepping up or blocking a materially changed interaction.

5. Create a closed-loop fraud system: A shared identity provider cannot see every downstream outcome, while a relying agency may not see the full enrollment and authentication context. Both sides need timely, standardized security-event exchange. Login.gov’s use of the OpenID Shared Signals and Events framework through its RISC API is directionally important: a downstream fraud determination should be capable of changing trust upstream, and an upstream suspension should reach relying services quickly.

Organizations should extend that principle internally. Fraud outcomes, manual-review decisions, chargebacks, benefit reversals, recovery events, and confirmed account takeovers should feed identity models and policy. Without that feedback loop, the system repeatedly treats known bad patterns as new applicants.

The GAO validates that adding another check is not the answer

The strongest conclusion from the GAO finding is that no point-in-time identity workflow should be expected to carry the full burden of trust.

When stolen PII can resolve correctly, authentic evidence can be misused, legitimate users can be recruited, and accounts can be taken over after enrollment, identity must be evaluated as a system. The system must connect proofing to authentication, authentication to transaction authorization, and downstream outcomes back to the identity decision.

The future of fraud prevention is not an ever-growing stack of disconnected checks. It is a unified, persistent identity: higher confidence from independent and historical evidence; cryptographic binding after verification; continuous evaluation when risk changes; and shared intelligence that allows trust to be updated or revoked.

A passed check should begin the trust relationship. It should never be the last word.