Skip to main content

On 31 August a service called Nexus appeared on the Russian-language cybercrime forum Exploit, offering digital scans of more than 153 million driver’s licences from the United States and Canada, alongside over 10 million other identity cards and roughly three million travel documents. Brian Krebs traced the apparent source to IDScan.net, a New Orleans identity verification provider that says it processes over 21 million verifications a month across more than 20,000 locations.

The sentence worth reading twice is the seller’s, not the vendor’s: “We have been continuously exfiltrating new data for over a year into our private database.” Reporting put the growth at roughly half a million documents a day while the listing was live. This was not a smash-and-grab followed by a torrent link. It was a subscription.

IDScan.net says it is investigating and has not confirmed its systems were the source. The FBI has opened a case, and Nexus vanished from the dark web about two hours after Krebs published. None of that changes the engineering lesson, which is not really about IDScan.

TL;DR

  • A dark web service listed 153 million-plus driver’s licence scans, apparently exfiltrated continuously from an identity verification provider for over a year at roughly 500,000 documents a day.
  • Records reportedly include front and back scans and, in some cases, infrared and ultraviolet captures, which are the channels that exist to prove a document is genuine.
  • You can rotate a password. You cannot rotate a driver’s licence, so the only control that ever worked on ID images was not retaining them.
  • If you are an EU or Irish business with an ID upload in your onboarding flow, you are the controller and your verification vendor is a processor. The GDPR Article 33 clock starts on your awareness, not on the vendor confirming anything.
  • Design for verify, assert, discard: store the decision, the check reference and a hash, never the image, and enforce retention as an infrastructure TTL rather than a policy sentence.

Nobody in that dataset chose the vendor

IDScan.net’s public site lists Holiday Inn, 7-Eleven, GameStop, DraftKings, Hertz, Target, Shell and Caesars Entertainment among its customers and integrations. Every one of those was a procurement decision made by a company. None was made by the person handing a licence over at a rental desk, a dispensary counter or a betting app signup. That person agreed to be verified, not to be archived, and was never told the difference existed.

What should worry engineering teams more than the headline number is what the records apparently contain: multiple images per document, front and back, and in some cases infrared and ultraviolet versions. Those channels are not decorative. They are captured because they expose the security features a forger cannot easily reproduce, which is what makes a scan trustworthy at all. A leaked IR and UV capture is not simply personal data that has escaped. It is reference material for defeating the next check, and a far better template than a photograph of the front. A verification industry that retains its own evidence has built a training set for the fraud it exists to prevent.

You can rotate a password. You cannot rotate a licence.

Every other credential class has a revocation story. Passwords rotate, sessions expire, API keys roll, payment cards get reissued within days while the scheme absorbs the fraud. That is why a credential breach, painful as it is, has a defined end. Government identity documents have none of it: multi-year issuance cycles, no reissue-on-compromise process, no channel to notify the businesses relying on the document. The blast radius here is the remaining validity of 153 million documents.

Once you accept there is no remediation step, the conclusion is immediate: the only control that was ever going to work is not holding the image. Encryption at rest, access reviews and SOC 2 attestations reduce the probability. None of them reduce the consequence, and the consequence is unbounded.

“Near real-time” is a detection problem, not a perimeter one

The listing described near real-time access, and that matters more than the record count. There was no single exfiltration event to catch, no 153-million-row query, no three-in-the-morning egress spike. Data left at the rate it arrived, because it was leaving as it arrived.

Data-loss tooling is tuned for the dump: egress thresholds, anomalous query size, unusual bulk export. All of it assumes the attacker eventually gets greedy. An adversary content to take today’s documents today looks exactly like the business operating normally. Same shape as the SAML SSO version blindspot and the Keycloak patch clock: access that produces normal-looking telemetry, so the absence of an alert means nothing.

What catches it is per-record read accounting: every stored document carries a read log with a purpose code, and any read that does not correlate to an inbound verification request raises an alert. Most identity pipelines log the verification in detail and the read not at all, because the verification is the billable event.

Under the GDPR, your vendor is not the one holding the bag

For an Irish or EU business, this is where the story stops being American news. Put an ID upload into onboarding or an age gate and you are the controller, the verification service is your processor, and the exposure lands on you.

  • Articles 5(1)(c) and 5(1)(e). Minimisation and storage limitation apply to the image separately from the check. A lawful basis to verify someone is not a lawful basis to keep the picture, and most teams ran those two assessments as one.
  • Article 9. Matching a licence photo against a selfie is processing biometric data to uniquely identify a person: special category data, needing an Article 9(2) condition on top of your Article 6 basis. Plenty of “quick liveness check” integrations never made that call in writing.
  • Article 28(3). Your processor contract must require deletion or return at the end of processing. Ask when your vendor last demonstrated deletion in a form you could check, rather than asserting it on a trust centre page. Test it annually, the way you test restores.
  • Article 33. Seventy-two hours from your awareness, which is the awkward part, because the vendor is investigating and has confirmed nothing. Awareness means a reasonable degree of certainty that a breach occurred, not a supplier admitting one. If credible reporting puts your processor at the centre of a live dataset, you assess and document that assessment either way, with the same discipline as the 24-hour Cyber Resilience Act reporting clock.

Verify, assert, discard

Store the assertion, not the artefact. What an auditor wants is a decision: verified or not, document type, issuing country, the derived answer rather than the raw field (“over 18: true” instead of a date of birth), the vendor’s check reference, a timestamp and the vendor version behind it. That is a complete audit trail and it is worth nothing on a cybercrime forum. Where you need evidence of the artefact itself, hold a digest: enough to prove you checked what you say you checked, not enough to reconstruct a licence.

Where a regulator genuinely requires the image, make retention expire by default. Enforce the TTL in infrastructure, not in a policy document; encrypt under a key you hold rather than one your vendor holds; make deletion the default and retention the deliberate exception. Long-lived buckets and “temporary” prefixes that have been temporary since 2022 are how five-year-old scans end up in a 2026 breach.

Ask the collection question before the storage question. Do you need someone’s identity, or a single attribute? Most age gates need one bit of information and are handed a complete identity document because the integration was easier. That sprint-sized decision is what creates the permanent liability.

The direction of travel

Age assurance mandates are pushing more products into ID collection, faster than the alternatives arrive; we covered the platform-signal version of that in age assurance moving into the OS. The credential-based alternative is real and dated: member states must offer at least one certified EU Digital Identity Wallet by 24 December 2026, with acceptance obligations reaching regulated relying parties roughly a year later. With selective disclosure and zero-knowledge proof tooling, that model returns “over 18” without transmitting a licence, removing the retention question rather than answering it. The transition will take years, and every ID image stored in the meantime carries a clock that outlives the vendor contract and probably the team that shipped it.

Start by finding every identity document your product has already stored, including support ticket attachments and the analytics bucket nobody owns. Then decide, on paper, what you do the day your vendor turns up in a Krebs headline. The 72-hour clock is a poor time to start that conversation.

REPTILEHAUS builds and audits identity and onboarding flows for products across Ireland and the EU, from data minimisation reviews to processor due diligence. If you are storing ID scans and are not certain why, get in touch.

This article is technical commentary, not legal advice. Take advice on your own data protection obligations.

📷 Photo by Kalden Swart on Unsplash