FBI investigates a dark-web claim of 153M leaked license scans

A dark-web marketplace is selling what it says are 153 million scanned driver's licenses. It claims they were stolen from IDScan.net, an identity-verification service embedded directly into other companies' apps and websites. The FBI's New Orleans field office opened a formal investigation on September 1, 2026. IDScan.net has not confirmed a breach happened.

What IDScan.net actually is

This is not a story about a company's internal systems getting breached. It is a story about a company whose product is code that other businesses run.

ByteIota describes IDScan.net's offering as "a RESTful API and SDK that businesses embed into their onboarding flows," in effect developer infrastructure rather than an in-house tool. The service verifies more than 10,700 document types across more than 250 languages and returns a result in under 15 seconds, according to the same report. Businesses across automotive, hospitality, retail, finance, gaming, and logistics use it, per BreachNews.

Has your product ever asked a user to scan an ID to prove their age or identity? There is a real chance a service shaped exactly like this one was doing the checking behind the scenes.

What is actually confirmed, and what is only claimed

The scale of this breach is not settled. BreachNews reports the 153 million figure comes from the dark-web marketplace's own listing, roughly 11.5 million catalog pages at about 15 records each. The outlet calls that math "plausible," not confirmed. Neither IDScan.net nor law enforcement has published an official count.

What is independently verified is narrower, but real. BreachNews reports that security researcher Brian Krebs checked records belonging to multiple actual people. He matched the timestamps on their leaked ID scans to real events in their lives, car rentals and hotel stays that happened exactly when the records say they did. That is evidence the leaked data is genuine and current, even without a confirmed total count.

IDScan.net's own position, as characterized by BreachNews, is that the company was investigating but had not publicly confirmed unauthorized access at the time of reporting.

The detail that should worry anyone who integrates a service like this

ByteIota reports that IDScan.net retained high-resolution scans, including infrared and ultraviolet captures of the documents, indefinitely. Payment processors handling card data operate under PCI DSS, a standard that requires discarding sensitive raw data once it is no longer needed. Nothing forces an identity-verification vendor to do the same.

An indefinitely retained, high-resolution scan of a government ID is a materially worse thing to lose than a truncated card number. A card number can be reissued. A face, a birth date, and a license number cannot.

What this means for developers

If your product embeds an identity-verification API or SDK, find out today what that vendor retains and for how long. "Under 15 seconds to verify" says nothing about how long the underlying scan sits on a server afterward. Ask directly, in writing, for the retention policy itself, not a general privacy-policy link.

Do not wait for a vendor to confirm a breach before you act. IDScan.net has confirmed nothing, and the FBI investigation alone is reason enough to act. Review any integration your team has with this specific vendor. Rotate any API keys, check what data you have received and stored from it yourself, and consider suspending the integration while this plays out.

Push for retention limits the way PCI DSS forces them for payment data. If you are choosing between identity-verification vendors, ask each one directly whether it deletes raw document scans once verification completes. Treat "we can retrieve your history" as a red flag, not a feature.

Separate what is confirmed from what is claimed before you repeat either one internally. The 153 million figure is a marketplace listing's own math, not an audited number. The breach itself, based on independent timestamp verification, appears real. Those are two different confidence levels, and conflating them either understates or overstates the actual risk to your own users.