A Password Can Be Changed. Your Driver’s License Cannot.
Passwords can be reset. Tokens can be revoked. Keys can be rotated.
The information on a government-issued ID is different. Your name, date of birth, photograph, driver’s-license number, and other identifying information are not things you can easily replace after a breach.
That is part of what makes identity verification effective, but it is also what makes the data behind it so attractive.
In early September, identity verification provider IDScan.net disclosed that an unauthorized third party may have accessed or copied information stored within customer accounts on its cloud platform, including names and driver’s-license or other government-issued identification numbers.
The disclosure followed reports about a dark-web service claiming access to more than 153 million U.S. and Canadian driver’s-license records and other identity documents. That number has not been independently confirmed, and the investigation into the actual scope is still ongoing.
Regardless of where the final number lands, the incident raises a question that deserves more attention in CIAM projects.
Once you have successfully verified that a customer is who they claim to be, how much of the evidence used during that process do you still need?
Verification and Retention Are Separate Decisions
There are plenty of legitimate reasons to ask a customer for a government-issued ID. Financial institutions have regulatory obligations. Rental companies need to validate licenses. Age-restricted services may need stronger proof than a date entered into a form.
The fact that the document was necessary during verification, however, does not automatically mean a copy needs to exist indefinitely afterward.
There may be legal, fraud, audit, or dispute-resolution requirements that call for retaining certain information. The point is not that identity documents should never be stored. The point is that retention should be an intentional decision with a defined purpose and lifespan.
During identity proofing, the document is evidence used to make a decision. Once that decision has been made, every copy that remains becomes sensitive data the organization has to defend.
That distinction can get lost during implementation. A team integrates an identity verification service, gets the journey working, confirms that fraud checks are passing, and moves on. The retention behavior of the verification provider can easily become whatever the default happens to be.
For data this sensitive, the default should not be making the decision for you.
Stronger Proof Can Create More Valuable Breach Data
There is an uncomfortable tradeoff here.
Organizations are asking for stronger identity evidence because fraud is getting harder to detect. Better document validation, biometric comparisons, device signals, and fraud intelligence can all make it more difficult for an attacker to impersonate a legitimate customer.
But stronger evidence also becomes more useful if someone steals it.
A copy of a driver’s license can help with social engineering, fraudulent account creation, or account recovery elsewhere. Combined with other breached data, it can make an attacker much more convincing.
This creates a strange cycle. Businesses collect better evidence to fight identity fraud. Attackers then target the systems holding that evidence and potentially reuse it to commit more identity fraud.
That does not mean identity proofing is the wrong approach. It means proofing architecture should include a serious discussion about what survives after the verification is complete.
In many cases, the business may need to know that the customer passed verification, when it happened, which method was used, and what assurance was achieved. It may not need to keep the original document image available indefinitely.
Sometimes it will. Sometimes it will not. What matters is knowing why.
What Does the Application Actually Need?
This is a useful question to ask during CIAM design because it changes the conversation from “What information can we collect?” to “What information does the business need to retain?”
If the objective is to confirm that a customer is over 21, does the application need a permanent copy of the entire license?
If an identity verification service has already confirmed that a document is valid and belongs to the person presenting it, does every downstream application need access to the original images?
If the business only needs a verified status and a few validated attributes, should the raw proofing evidence remain part of the customer profile?
There is no universal answer. Regulatory and business requirements vary considerably. But those are architecture decisions, not implementation details.
NIST’s Digital Identity Guidelines take a similar approach by emphasizing privacy risk assessments and limiting identity information to what is necessary for proofing, fraud mitigation, and related identity functions.
There is also a very practical security benefit to collecting and retaining less.
Information that no longer exists in your environment does not need to be encrypted, monitored, governed, produced during discovery, evaluated during an incident, or included in the scope of a future breach.
A Third-Party Verification Service Does Not Make the Risk Disappear
Identity verification is commonly outsourced, and for good reason. Specialized providers can offer document validation, biometric comparison, fraud detection, and other capabilities that would be difficult for many organizations to build themselves.
From the customer’s perspective, the experience may be as simple as scanning an ID and taking a selfie.
Behind that experience is a much larger data flow.
The document has to be captured somewhere. Images are processed. Information may be extracted. Fraud checks are performed. APIs exchange results. Logs and metadata are created. Depending on the architecture and configuration, copies of the evidence may remain in more than one system.
That makes the data lifecycle part of the vendor integration.
Where is the original document processed? How long does it remain there? Does the provider retain a copy after verification? What comes back to the relying application? Can the business keep the verification result without also keeping the evidence behind it?
Those questions should be answered before the journey goes live.
At Navar, this is part of how we look at CIAM architecture. Getting the verification step working is only one piece of the design. We also want to understand what data the journey creates, which systems receive it, what is actually necessary for the business, and what risk remains once the customer has been verified.
A successful API response does not necessarily mean the overall data architecture is sound.
Stolen Identity Evidence Can Undermine Other Controls
Retention also matters because identity information rarely stays relevant to only one system.
A document collected by one company may contain exactly the information another company uses during customer support or account recovery.
That means stolen proofing data can potentially make an attacker more believable somewhere else.
This is especially important as organizations strengthen their login flows with passkeys, adaptive authentication, and other phishing-resistant controls. Attackers do not have to defeat the strongest part of the authentication architecture if they can convince a weaker recovery or support process that they are the legitimate customer.
A government-issued ID can be strong evidence when it comes from a trusted customer during a well-designed proofing process. The same document in an attacker’s hands is a different problem entirely.
CIAM teams should be thinking about both sides of that equation.
CIAM Does Not End at Login
Customer identity programs naturally spend a lot of time on the visible parts of the experience: registration, authentication, MFA, passkeys, account recovery, and consent.
The data created by those journeys needs the same attention.
As more organizations add document verification, biometrics, device intelligence, and fraud services to their customer experiences, identity architecture increasingly has to account for the full lifecycle of that information.
What are we collecting?
Why do we need it?
Where does it go?
Who can retrieve it?
How long should it exist?
What is the deletion process?
The objective should not be to build the most detailed identity profile possible. The objective is to establish enough trust to make the business decision safely.
Where Navar Helps
Navar helps organizations design and implement CIAM environments across the full customer identity lifecycle, including registration, identity proofing, authentication, recovery, fraud controls, authorization, and the integrations supporting those journeys.
Part of that work is understanding what identity evidence is actually necessary and how third-party verification services fit into the broader architecture. It also means looking at what gets retained, where sensitive information flows, how recovery processes use identity evidence, and whether the controls around that data match the risk it creates.
Identity proofing should increase confidence in the customer.
It should not quietly create a repository of sensitive information that nobody has revisited since the integration was first deployed.
Prove the Identity. Keep What You Need.
As identity verification gets stronger, the evidence supporting it becomes more valuable to both the business and an attacker.
The IDScan.net incident is a useful reason for organizations using document verification to revisit a simple question:
After we prove the customer’s identity, what are we keeping, and why?
If there is a regulatory, fraud, or business reason to retain something, then retain it deliberately and protect it accordingly.
If there is not, keeping some of the most sensitive information a customer can provide may be adding risk without adding trust.
Prove the identity. Keep what you actually need. And when the evidence has finished its job, there should be a good reason for it to still exist.
