On 31 August 2026 a dark web service called Nexus appeared, offering searchable scans of driver’s licences belonging to 153 million people in the United States and Canada, along with about 10 million ID cards and 579,000 medical cards. Brian Krebs reported it on 2 September and verified the data by finding his own record. The FBI’s New Orleans field office opened an investigation. On 10 September, IDScan.net confirmed that driver’s licences had been stolen from its cloud, including full names, licence numbers, and identity numbers from other government documents such as passports.
Almost every write-up of this has landed in the same place: centralised identity databases are honeypots, this keeps happening, mandates make it worse. All true, and we have written some of that ourselves. But it skips the one number in the story that is actually actionable, and it is a number every platform sets for itself.
IDScan.net performs roughly 21 million verifications a month.
Divide 153 million by 21 million. The stolen pile is about seven months of throughput.
That is not a security finding. That is a retention setting.
The arithmetic nobody does
Be careful with that division, because it is an illustration rather than a measurement. IDScan’s own site says it holds more than 150 million driver’s licence records, and that store is probably years of activity deduplicated down to one record per person, not seven calendar months of raw scans. The company has not published a breakdown and neither reading can be confirmed from outside.
But both readings end in the same place. Either the store is seven months of scans nobody deleted, or it is several years of scans nobody deleted. There is no third reading in which the pile gets that big while the retention policy is working.
This matters because of how breach magnitude is usually discussed. “153 million records” gets treated as a property of the attack, as though a more determined hacker produces a bigger number. It isn’t. Attackers exfiltrate what is there. The size of a breach is the size of the store, and the size of the store is:
records created per day × days each record is kept
Two terms. Neither of them is a security control. Both of them are product decisions, usually made years earlier, usually by someone who was not thinking about breaches at all. A team that checks 700,000 IDs a day and keeps each one for seven months has built a 150 million record breach. It exists whether or not anyone ever attacks it. The attack only determines the date it becomes public.
Run your own numbers before reading further. Verifications per day, multiplied by your retention period in days. If you have never calculated it, the result will be larger than you expect, because retention periods are set in months and volumes are counted in days, and nobody ever multiplies the two.
The infrared tell
There is a detail in Krebs’s reporting that deserves more attention than it got. The stolen data included infrared and ultraviolet scans.
Physical ID scanners, the kind that sit on a bar counter or a dispensary desk, illuminate a document in several spectra. Ultraviolet reveals security printing that is invisible in normal light. Infrared reads features in the laminate. These channels exist for one reason: to tell a real licence from a forged one, in the two seconds while the customer is standing there.
Their presence in a dark web dump tells you the pipeline kept the entire raw multi-spectral capture, not the answer it computed from it.
Think about what that means operationally. The scanner asked one question: is this document genuine and is this person over 21. It answered in about a second. And then it filed the ultraviolet channel of a stranger’s driver’s licence, forever, on the chance that someone might want it later. Nobody wanted it later. Nobody has ever wanted it later. The scans were kept because keeping is the default and deleting requires someone to write a job.
This is the most common failure in identity engineering, and it is not a security failure. It is a modelling failure. The system was built to store what it read instead of what it decided. A decision record is small, boring, and useless to an attacker: over 21, checked on this date, by this method, at this confidence. A raw capture is a copy of a government document with the security features included. The pipeline that produces the first and the pipeline that produces the second look almost identical in a design review, and they differ by about eight orders of magnitude in breach cost.
The same pattern showed up in February 2026, when security researchers found a Persona frontend exposed on a public server. Among the 2,456 files was the detail that IP addresses, device fingerprints, government ID numbers, phone numbers, faces and even selfie backgrounds were analysed and retained for up to three years. Three years, for a check that decided whether a teenager could use voice chat. Discord dropped the vendor, as it had dropped the previous one after a 2025 breach exposed 70,000 government ID photos that were then held for ransom.
Three vendors, three incidents, one shared root cause. The data was there to steal because the data was kept.
Your questionnaire cannot find this
Now the part that should worry anyone who buys identity verification.
The exfiltration ran for over a year. The attackers said so themselves, claiming they had been continuously pulling new data into their own database the whole time, and the record count on the dark web site grew by nearly 400,000 in a single day while journalists were watching it. IDScan says it first received information about the claim on or around 1 September 2026, the same day Krebs published.
So for roughly twelve months, the detection status was: not the company, not its customers, not an auditor, not a scanner, not a regulator. The thing that finally surfaced it was a criminal sales listing.
Hold that against the artefacts your procurement process actually collects. A SOC 2 Type II report describes controls over an observation window that closed before you read it. A penetration test is a point-in-time exercise against a scope the vendor defined. An ISO 27001 certificate attests to a management system. A security questionnaire asks whether data is encrypted at rest, and in this case the honest answer was almost certainly yes. Encryption at rest protects against someone stealing a disk. It does nothing against credentialed access quietly reading records for a year.
None of these instruments measure dwell time, and dwell time is the variable that mattered. This is not a criticism of the instruments. They do what they were designed to do. It is a criticism of treating them as though they answer the question “will my users’ documents leak”, when the question they answer is “did this organisation have a described control framework during a past window”.
There is a version of vendor due diligence that does help, and we have written a checklist for it. But be honest about its ceiling. You cannot audit a vendor’s database continuously. You cannot instrument their egress. You have no telemetry inside their perimeter and you never will, and no contract clause changes that.
What you can control is how much of your user base is sitting in there, and for how long. That is the whole of your leverage. Everything else is a document.
The copies you made yourself
Here is the part that most teams have genuinely never looked at, and it is the reason this post is filed under engineering rather than compliance.
Your vendor is not the only place your users’ identity documents live. In a typical web stack, a single document upload leaves a trail of copies in systems that were never part of the identity design, are not listed in your data processing agreement, and are not covered by your vendor’s retention promises. Seven places, roughly in the order they appear:
1. The browser, via session replay. Tools that record user sessions (Hotjar, FullStory, LogRocket, Microsoft Clarity, Sentry’s replay product) reconstruct the page as the user saw it. If the age gate renders a preview of the uploaded passport, the replay contains a passport. Every one of these tools ships masking controls, and every one of them masks by selector or by default rules that the vendor wrote for text inputs, not for a canvas element holding a document image. Masking that was never explicitly configured for the verification flow is masking that is not applied to the verification flow.
2. Error monitoring. When the upload endpoint throws, the exception handler attaches context. Request bodies, breadcrumbs, local variables, sometimes a screenshot. Sentry, Rollbar and Bugsnag all document PII scrubbing, and all of it is opt-in configuration keyed to field names your team has to supply. The verification flow is the flow most likely to error, because it involves a camera, a file, a third-party SDK and a network call, which means it is disproportionately represented in whatever your error tool retained.
3. CDN and WAF logs. A multipart upload passes through the edge. Most teams log request metadata rather than bodies, which is fine, until someone enables body inspection for a WAF rule or turns on full request logging to debug something and never turns it off. Edge log retention is configured in a different console by a different team from the one that set your identity retention policy.
4. The upload bucket with no lifecycle rule. The document lands in object storage before it goes to the vendor, or as a queue buffer, or because a retry needs it. Someone writes a delete call in the happy path. The failure path does not reach it. There is no lifecycle policy on the bucket because the bucket was created in a hurry. Six months later there are two million orphaned document images in a prefix nobody lists.
5. Support tickets and email. This is the worst one, and it gets worse as appeals become a regulatory expectation. A user is wrongly refused, opens a ticket, and a support agent asks them to attach a photo of their ID. Now a government document is an attachment in Zendesk or Intercom or a shared inbox, retained under the help desk’s retention policy, which is measured in years, visible to every agent, and outside every control you built for the primary flow. The careful architecture on the main path is undone by the most human part of the system.
6. The data warehouse. Verification events flow to analytics. If the event payload is the full API response and it gets loaded as a JSON blob, whatever the vendor returned is now in a warehouse table, replicated to a BI tool, and probably in somebody’s ad-hoc extract. Warehouse retention is effectively infinite by design, because the point of a warehouse is history.
7. Backups and snapshots. Every deletion policy you write is silently amended by your backup schedule. A record deleted on day 30 survives in nightly snapshots for however long snapshots are kept. This is the one that makes deletion claims in privacy policies quietly untrue, and it is the one nobody wants to solve, because solving it properly means either encrypting per-subject with destroyable keys or accepting that “deleted” means “deleted within one backup cycle” and saying so out loud.
None of these seven are exotic. Most engineering organisations have at least four of them. And not one appears in a vendor security questionnaire, because they are not the vendor’s systems. They are yours.
The concrete task, which takes an afternoon: take one test verification through your production flow with a document that has a recognisable serial number, then go and grep for it. Session replay, error tool, edge logs, buckets, help desk, warehouse. Wherever it turns up, it turns up for every real user too.
What the law already says about this
The legal framing tends to arrive after the engineering one, but it points the same way, and in several jurisdictions it points quite sharply.
Storage limitation is a principle, not a preference. GDPR Article 5(1)(e) says personal data must be kept in a form permitting identification no longer than is necessary for the purpose. Once an age check has produced its answer, the document image is no longer necessary for the purpose of the age check. Keeping it needs its own justification, and “we might need it for an audit” is only a justification if some rule actually requires it. Mostly no rule does. Ofcom’s record duties are about the measures a service uses, not about per-user document images, and the ICO has said as much.
The UK regulators have written this down jointly. In their joint statement of 25 March 2026, the ICO and Ofcom set out how online safety duties and data protection duties interact for age assurance. It introduces no new obligations, and it does not need to. The useful part is the alignment: a service must use methods that are effective and proportionate and compliant with data protection law, which removes the excuse that the safety regulator made you collect it.
Collecting an ID copy you did not need is itself finable. The Dutch supervisory authority fined DPG Media €525,000 for requiring people to upload a copy of an identity document in order to exercise their data subject rights. The reasoning generalises well beyond those facts: an identity document carries a great deal of personal data, and demanding one is often disproportionate to the question being answered. An age gate asks a one-bit question. A passport is an extremely expensive way to answer one bit.
Biometric processing narrows your options further. Spain’s AEPD held that matching a live selfie against a stored template is unique identification, putting it inside GDPR Article 9, which is a separate prohibition with a closed list of exceptions. We covered what that leaves you at length. The short version is that special category data is harder to hold lawfully than ordinary personal data, so the volume you hold matters more, not less.
In the US, the litigation risk did not go away this summer. California SB 690 cleared the legislature at the end of August 2026 and, if signed, takes effect on 1 January 2027. It removes the private right of action for website-tracking claims brought under CIPA section 638.51, the pen register provision, with a retroactivity window. A lot of commentary read that as the end of website privacy litigation in California. It is not. SB 690 leaves section 631(a), the wiretapping provision, untouched and still available to private plaintiffs, and section 631 is the one used against session replay and live chat interception. Statutory damages there are $5,000 per violation. The Los Angeles Times settled tracker claims for $3.85 million in June 2026 over ordinary ad trackers on ordinary pages. Now price the same theory on a page where the recorded session contains a driver’s licence.
And separately, Illinois BIPA remains the most expensive statute in this area, with an insurance market that has spent three years writing biometric exclusions into cyber policies. The likeliest outcome of a large age assurance biometric claim is that it is uninsured.
Designing for a breach you cannot prevent
Assume your vendor will be breached. Not as pessimism, as a planning input: three well-funded identity vendors had incidents in twelve months, which is enough of a base rate to design against. The question is what that breach costs you, and that is determined entirely by decisions you made before it happened.
Store the decision, not the artifact. The output of an age check should be a small record: result, timestamp, method, confidence, policy version, and an identifier that is yours. That record is re-checkable, portable between vendors, cheap to cache, and worth nothing to an attacker. A document image is worth about $100 to an attacker, which we know because that is what the Nexus listing was charging per ID.
Put a TTL on the image measured in minutes. Not months, not “after processing”, not “when the job runs”. The image should be unreachable shortly after the answer exists. For reference, our own document path deletes document images within 24 hours of processing completing, and we would rather that number were smaller. Make it a bucket lifecycle rule as well as application code, so it survives a code path that forgets.
Make the expensive path the exception. This is the structural move and it does more than all the others combined. Most of what an age gate does is not a document check. It is a returning user who already has a credential, a browser-level age signal, a liveness check, an OAuth handoff. Those operations are roughly an order of magnitude cheaper to run and they produce no government document at all. Document verification should be reached for when a legal threshold genuinely demands it or when a cheaper method was inconclusive. That is why we price Checks and Verifications as separate operation types rather than billing everything as though it were a passport scan: the same split that keeps unit economics sane is the split that keeps most of your users out of any document store, anywhere.
Verify once, not once per service. A reusable credential collapses many document checks into one, which collapses the population inside the document store by the same factor. Interoperable age credentials are usually sold on friction and conversion. The breach-size argument is stronger and almost nobody makes it.
Fix the appeals path with the same care as the main path. If your support flow ends with “email us a photo of your ID”, you have built a second, worse identity pipeline with no retention policy and broad internal access. Route appeals into the same verified flow, or into a purpose-built secure upload with the same TTL, and never into an inbox.
Contract for deletion with numbers. Deletion SLA stated in hours with a defined start event. A written commitment on what is kept after deletion and why. Sub-processor list with regions. Breach notification in hours rather than “without undue delay”. A right to request evidence that the deletion job ran. And an exit clause, because vendors disappear for reasons other than breaches.
We should say plainly where we sit in this, since a post about retention written by a vendor with no disclosure is worth nothing. Our document path deletes document images within 24 hours of processing. It does create a face embedding to match the live face against the document photo, and we keep that embedding for 12 months from the day of the check before deleting it. An embedding is a numerical vector rather than a photograph and cannot be turned back into a face image, but it is still biometric data under Article 9 and it is still a store with a duration, and the honest reading of this article applies to it. Twelve months is a choice we should keep arguing about internally, and readers are entitled to weigh it.
Five questions to ask this week
- What is our number? Verifications per day multiplied by retention days. Write it on a slide. That integer is your breach headline, and it exists today whether or not anyone attacks you.
- Does the raw capture outlive the answer, and by how long? Check the code, then check the bucket lifecycle rule, then check whether the failure path reaches either.
- Where does a document image appear in our own estate? Run the grep. Session replay, error monitoring, edge logs, buckets, help desk, warehouse, backups.
- What fraction of our checks actually need a document? If it is above a few percent, the rest are probably paying document prices and document risk for a question a Check could answer.
- How would we learn our vendor had been breached? If the honest answer is “we would read about it”, then reducing what sits inside their perimeter is not one mitigation among several. It is the only one you control.
The uncomfortable conclusion of the IDScan story is not that identity verification is unsafe. Age checks are legally required across a growing list of jurisdictions and the methods do work. It is that the industry has been arguing about accuracy, effectiveness thresholds and vendor certifications while the variable that actually determines the damage has been set almost everywhere by default. That variable is how many documents are sitting in a store, and for how long. It gets set by pipelines that save what they read because nobody wrote the delete.
That variable is not a security problem. It is a data model, and you can change it on a normal Tuesday.
If you want to work out what your number is and what it would take to bring it down, we are happy to go through it with you.
