170 Million Identities, One Cloud Account: The IDScan.net Breach and What It Teaches About Storing the Document Itself
More than 170 million scanned identity documents surfaced on a cybercrime forum after a breach at IDScan.net. The lesson is not about verification — it is about what happens after.
In late August 2026, a seller on the Russian-language cybercrime forum Exploit began advertising a marketplace called Nexus, offering forensic-grade scans of physical identity documents rather than the usual passwords or card numbers. Security journalist Brian Krebs traced the listing to more than 170 million identity documents belonging to people across North America. Every path led back to the same source: identity verification hardware operated by IDScan.net, a Louisiana-based identity verification company.
A blank search returned an estimated 11.5 million results
The scale was not a marketing exaggeration. The Nexus trove included upwards of 153 million U.S. and Canadian driver’s licenses, more than 10 million other identification cards, more than 3 million travel and international documents, and at least 579,000 medical and dispensary cards.
| Document category | Reported volume |
|---|---|
| U.S. and Canadian driver’s licenses | 153 million+ |
| Other identification cards | 10 million+ |
| Travel and international documents | 3 million+ |
| Medical and dispensary cards | 579,000+ |
A blank search of the Nexus interface — no name, no filters, nothing entered — returned an estimated 11.5 million pages of results at roughly 15 records per page, consistent with the advertised totals. Canadian records alone numbered around 1.1 million, with Ontario the single largest source at nearly 474,000. Some records carried the tags CDL (commercial driver’s license) and CAC (Common Access Card, the credential used to access secure U.S. government facilities and Department of Defense networks), showing the exposure reached beyond routine retail identity checks.
Six images per license reveal the source of the leak
Individual license entries in the Nexus database did not contain one image. They contained six: front and back captures under ordinary light, plus infrared and ultraviolet versions of the same document, each carrying its own capture timestamp. A phone camera does not produce that output. A dedicated multi-spectrum ID-scanning terminal does — the kind of hardware deployed at rental car counters, hotel front desks, casinos, and age-restricted retail locations to check for holograms and laminate structures invisible to the naked eye.
That detail pointed the investigation directly at IDScan.net, whose scanning terminals sit at Hertz rental counters, cannabis dispensaries, hotels, casinos, and shipping and logistics centers across the United States. The company reports performing more than 21 million identity verifications a month at over 20,000 locations worldwide.
Every trail led back to the same cloud account
The forensic trail was personal. Krebs was offered his own driver’s license as a free sample, timestamped to the exact moment he had handed it to a rental car counter agent. A researcher at the cybersecurity firm Cybera found his own license in the database, timestamped to a recent vacation car rental. Others found their records tied to dispensary visits rather than airports or border crossings, and in at least one widely reported case, records belonging to a senior U.S. government official were said to be present in the trove.
IDScan.net confirmed the incident in a public statement:
“On or around September 1, 2026, IDScan.net received information indicating that certain data may have been accessed without authorization,” and “an unauthorized third party may have accessed and/or copied certain customer information stored within their accounts on the IDScan.net cloud.”
The company said exposed data could include full names and driver’s license or other government-issued identification numbers, and said it was cooperating with federal law enforcement. The FBI’s New Orleans field office opened a formal investigation. Krebs’s reporting suggested the Nexus marketplace was receiving newly stolen records in near real time throughout the investigation, and the operators themselves claimed to have been exfiltrating data continuously for over a year.
The breach hit customer cloud accounts, not the verification engine
One sentence in IDScan.net’s statement is easy to skim past, and it is the most important sentence in the whole story: the breach was not of IDScan.net’s central verification engine. It was of customer accounts within IDScan.net’s cloud storage — accounts that appear to have been used by IDScan.net’s own business customers to retain raw document images long after the verification moment had passed.
This is a recurring architectural pattern in the identity verification industry, not one company’s bad month. A document image is captured for a few seconds to answer a yes/no question — is this a real ID, does the photo match the person, is the holder old enough — and then, for reasons of convenience, audit trail, or simple inertia, the image itself is kept. Sometimes the verification vendor keeps it centrally. Sometimes, as here, a general-purpose cloud storage account made available to the vendor’s own customers becomes the actual point of failure. Either way, a raw document image retained beyond the verification transaction becomes a standing target, regardless of how good the underlying verification logic was.
Verifying a document and storing it are two different problems
We are writing about this breach not to point fingers at a company navigating a hard problem, but because it illustrates a design principle UIID was built around from the start: verifying an identity and storing a copy of the document used to verify it are two entirely different things, and a well-designed identity system should not need to do the second one.
UIID does not operate a central repository of identity document images, and it does not retain document scans anywhere in its verification pipeline — not in its KYC (Know Your Customer) checks, not in its jurisdiction-specific Trust Center verification modules, and not in partner-mediated verification flows where a third-party provider performs the underlying document check. Where a document image is involved at all, it exists only for the duration of the verification transaction. UIID does not write it to persistent storage, and it does not come back out the other side. This is a structural characteristic of how UIID’s storage is built, not a policy layered on top of a system that could technically do otherwise.
UIID’s KV Storage holds text, not document images
A natural question, in light of the IDScan.net incident, is whether UIID has an equivalent of the customer cloud account that turned out to be the actual point of failure. UIID offers a general-purpose storage primitive called KV Storage, and it is worth explaining what it is — and what it structurally is not.
KV Storage is a key-value store: a mechanism that lets an application, or in some cases a user directly, associate a piece of text with a key, under a given Core ID or alias, through a straightforward API. It works like a labelled notebook attached to an identity — an application writes a short text value under a key such as “loyalty-tier: gold” and reads it back later. Some buckets can be shared across multiple integrated applications, which makes KV Storage useful as a lightweight, portable attribute store tied to a Core ID rather than to any single app’s own database.
| KV Storage | |
|---|---|
| What it stores | Plain text values under a key, on write, in persistence, and on read |
| What it is | A key-value attribute store tied to a Core ID or alias |
| What it is not | An object store, document vault, or media/blob storage service |
| Image upload endpoint | None |
| Binary object type | None |
| File format handling | None |
| Rendering layer | None |
A customer could, in theory, paste a hyperlink into a value pointing at a document image hosted elsewhere. In that case UIID is storing a piece of text that happens to be a URL, not the image itself. There is no mechanism by which an actual document scan — a JPEG, a PNG, a PDF, or a set of infrared and ultraviolet capture files — can be written into KV Storage as a first-class stored object. The component of UIID that most resembles the customer cloud storage implicated in the IDScan.net breach is, by construction, incapable of holding the kind of data that made that breach so damaging. It was designed to carry small facts about an identity, not scans of the identity’s paperwork.
The safest data is the data nobody kept
Security engineering has a well-worn truth: the safest data is the data nobody collected, and the second-safest data is the data that was collected but not kept. Encryption, access controls, and monitoring all matter, but each of them is a defense built around something that exists. The IDScan.net breach did not fail because encryption was weak or access controls were obviously absent; reporting suggests the exposure came through customer-managed cloud accounts, a layer that is easy to under-govern precisely because it feels like ordinary storage, disconnected from the sensitivity of what it happens to contain.
UIID removes that layer from the equation for document images specifically. If a document scan is never retained in the first place, there is no customer-cloud-account equivalent to misconfigure, no long-lived cache to forget about, and no dataset that can grow quietly for a year before anyone notices it is being exfiltrated in near real time. Verification produces a decision. It does not need to produce a permanent copy of the evidence to remain trustworthy — and where the decision itself needs to be auditable, that is a smaller and far less sensitive problem than retaining original images at scale.
This does not resolve every open question. When a partner-mediated verification provider performs the underlying document check before handing UIID a result, what that partner does with the document image on its own side happens outside UIID’s storage layer. Applications choosing a verification partner should ask that partner the same retention questions this article raises about IDScan.net.
What this means for teams building on UIID
An application that integrates with UIID does not need a separate secure document vault to use UIID’s identity verification, because UIID does not hand back a document image to be responsible for in the first place. An integration that uses KV Storage to carry attributes alongside a Core ID can treat it exactly as designed — a lightweight text attribute store — and should not attempt to route document images or scans through it, encoded or otherwise. Doing so would not behave well as a media store, and it would reintroduce, at the application layer, the exact risk this article describes.
What comes next
The IDScan.net breach will be written about, correctly, as a story about scale: 170 million people, a marketplace still growing, a federal investigation, and a hard question for an entire industry about whether document images should be kept at all once a verification is complete. For UIID, the narrower and more actionable lesson is this: the safest way to make sure a document vault can never be breached is to not build the document vault. Verify what needs to be verified, keep the decision, and let the document itself go.
Learn more about how UIID handles identity verification and storage at uiid.me.