The IDScan data breach: 153 million ID scans advertised and nine class actions in three days

The IDScan data breach has moved from a dark web listing to federal court: nine class actions were filed against IDscan.net, Inc. between 2 and 4 September 2026, after a service advertised more than 153 million driver's license scans. The company confirms a security incident but not its scale.

• IDScan.net's own notice says it received information on or around 1 September 2026 that data may have been accessed without authorisation.
• A dark web service called Nexus advertised more than 153 million US and Canadian driver's license scans, plus ID cards, travel documents and medical cards.
• Nine putative class actions over the IDScan data breach were docketed in the Eastern District of Louisiana in three days, as of 8 September 2026.
• The captures Krebs corroborated line up with in-person ID checks at car rental counters and a cannabis dispensary, not with online onboarding.
• The company's notice describes names and identification numbers. The listing advertised document images. That gap is unresolved.

What happened in the IDScan data breach?

The IDScan data breach surfaced as a marketplace listing, not a company disclosure. On 1 September 2026 the security journalist Brian Krebs reported that a dark web service called Nexus, advertised on the Russian-language Exploit forum, was selling searchable access to identity documents that appear to have been collected by IDScan.net (in the court filings, IDscan.net, Inc.), a New Orleans identity verification provider.

Krebs reports that the company describes its systems as performing more than 21 million verifications monthly at more than 20,000 locations around the world, and that its published client list has included Hertz, Target, FedEx, Motorola Solutions, Jack Henry and Caesars Entertainment. How the data was collected matters. Nine people Krebs searched for confirmed travel matching their timestamps, several after handing a license to a car rental counter, and one researcher to a Las Vegas dispensary. On that evidence the exposure follows in-person ID checks rather than online KYC onboarding.

The company has since published a notice of a data security incident. It states that on or around 1 September 2026 it "received information indicating that certain data may have been accessed without authorization", and that the investigation is ongoing. It says an unauthorised third party "may have accessed and/or copied certain customer information" held in customer accounts on the IDScan.net cloud. It is offering free credit monitoring and says it is cooperating with federal law enforcement. The Nexus listing came down after Krebs published, though nothing confirms whether the operation has stopped or moved.

What does the litigation record actually show?

Litigation over the IDScan data breach is concentrated in one district. Nine putative class actions naming IDscan.net, Inc. were docketed in the US District Court for the Eastern District of Louisiana between 2 and 4 September 2026, and no further case had been docketed as of 8 September. The case numbers are not contiguous. Eight are allocated across seven district judges, with one not yet assigned, a pattern that often precedes consolidation.

How does 153 million records compare?

Public discussion of the IDScan data breach rests on an advertised figure, so it is worth benchmarking rather than repeating. The Federal Highway Administration counted 239,824,944 licensed drivers in the United States in 2024. The Nexus listing covered the United States and Canada, so the share below is an upper bound, not a count of people.

The monthly figure is the better denominator: at more than 21 million checks a month across more than 20,000 sites, a year of collection reaches nine figures without anything exotic. For precedent, the AssuranceAmerica incident we covered in July exposed roughly 7 million driver's license numbers. This advertised set is an order of magnitude larger.

What does this change for your KYC obligations?

Most regulated firms are not IDScan customers. The duties the IDScan data breach puts in play are about what you keep and who you outsource to, and five are specific enough to act on this week.

Customer identification recordkeeping

Under 31 CFR 1020.220(a)(3)(i)(B), the record a bank must make for documentary verification is "a description of any document that was relied on", noting the document type, any identification number, the place of issuance and, where applicable, the issuance and expiration dates. Retention sits at (a)(3)(ii): five years after the record is made. The rule does not require a stored image. Parallel customer identification program (CIP) rules apply to broker-dealers at 1023.220, mutual funds at 1024.220 and futures commission merchants at 1026.220. Our CIP guide walks the full duty.

Reliance is narrower than outsourcing

Section 1020.220(a)(6) lets a bank rely on another party's identification work only where the reliance is reasonable under the circumstances, the other party is a financial institution subject to an anti-money laundering program rule and regulated by a federal functional regulator, and a contract requires an annual certification. A document-scanning vendor meets none of that. Using one is outsourcing, and the CIP obligation stays with you.

Service provider oversight, for non-bank firms

16 CFR 314.4(f) requires you to select service providers capable of maintaining appropriate safeguards, require those safeguards by contract, and reassess them periodically. Section 314.4(j), effective 13 May 2024, requires notice to the Federal Trade Commission as soon as possible and no later than 30 days after discovering a notification event, defined at 314.2(m) as acquisition of unencrypted customer information without authorisation, involving at least 500 consumers. Scope matters: 16 CFR 314.1(b) applies the rule to financial institutions under FTC jurisdiction, so banks sit under their own agencies' Gramm-Leach-Bliley section 501(b) standards instead.

State breach notification, including the vendor's own duty

Louisiana's R.S. 51:3074(E) requires notice without unreasonable delay and not later than sixty days from discovery. A delay is available where law enforcement determines under subsection F that notice would impede an investigation, but subsection E still requires written reasons to the attorney general inside the sixty-day window before an extension is granted. Subsection D is the one to read twice: a party that maintains data it does not own must notify the owner. Customer firms may then carry their own notification duties in their own states.

For EU and UK firms, the clock is shorter

Where a vendor processes personal data on your instructions, GDPR Article 28 governs the written contract and the guarantees it must give, and Article 33(2) requires it to notify you without undue delay. Article 33(1) then requires you to notify your supervisory authority without undue delay and, where feasible, not later than 72 hours after becoming aware, unless the breach is unlikely to result in a risk. Article 5(1)(c) is the underlying point: data must be "adequate, relevant and limited to what is necessary".

What is still uncertain about the IDScan data breach?

The central facts are contested and should be handled as such. IDScan.net has confirmed a security incident but has not confirmed that the Nexus data came from its systems, how many people are affected, or which customer accounts were touched. The FBI's New Orleans field office has opened an investigation, which reached the public through Krebs rather than through an agency announcement.

Three specifics sharpen the uncertainty. First, the descriptions do not match: the company's notice lists names and driver's license or other government-issued identification numbers, while the listing advertised scans of the documents themselves. Second, the seller claimed on the forum to have "been continuously exfiltrating new data for over a year", and Krebs observed the advertised license count rise by nearly 400,000 in 24 hours, which points to ongoing collection rather than a single point-in-time theft. Third, a Caesars Entertainment spokesperson told Krebs the company stopped using VeriScan in February 2025, held no active account during the incident and did not authorise retention of its data, which contradicts the vendor's own published client list.

Two risks deserve planning time. Liability allocation is the first: the complaints seek damages and security improvements from the vendor, but a regulated customer that pushed document images into a third-party cloud will still face supervisory questions about vendor selection and data minimisation. The second is remediation that does not remediate. Credit monitoring is the standard offer, and a license number is not a password: re-issuance is a state process with its own cost and delay, and for most people it will not happen.

Why do identity vendors hold document images at all?

Because capture and storage were bundled together, and nobody unbundled them. What the IDScan data breach shows is the cost of that bundling when it fails. A scanner reads the document, the platform retains the image for audit and model training, and that copy becomes the asset an attacker wants. The regulatory driver is thinner than the habit suggests: the rule asks for a description of the document, not a picture of it.

What is stored is also richer than most people assume. Krebs reports that some records in the Nexus set carry six image files, including infrared and ultraviolet captures of the same document. Those are the frames a forensic authenticity check relies on, which is why images defeat verification differently from numbers: an attacker no longer has to reproduce what a genuine capture looks like under each light source.

Legislatures have started closing the gap from the other side. Missouri's age verification statute, in force since 28 August 2026, bars the verifier from retaining any identifying information. The direction of travel is consistent: verify, then hold as little as the law allows, against the vendor incidents we log in our IDV provider breach tracker.

How should compliance teams respond?

Treat the IDScan data breach as a prompt to shrink what you hold. Start with an inventory of every place a customer identity document image is stored, in your systems and in your vendors', with the retention period and legal basis recorded for each. Where the only justification is a vendor default, delete on a schedule and keep the 1020.220 description instead.

Then work the contracts. Re-read your identity verification agreements for breach notification windows, audit rights and deletion on termination, and check that vendor reassessment has been performed rather than filed. Confirm you can say, within 30 days, how many consumers a vendor incident touched. Finally, retire any control that authenticates a person using a license number.

Zyphe was built for the version of this problem that does not depend on trusting a vendor's storage. Our KYC flow reads the chip in a passport or national ID card to the ICAO 9303 standard, with two-step liveness and no image upload. The resulting data is split across more than 60,000 nodes, so that 29 of 100 must cooperate before anything can be reassembled, and the key stays with the customer. There is no central store of identity documents to lose. If holding fewer document images is on your roadmap, see how the storage model works or book a demo.

The bottom line

An identity verification vendor is a concentration of exactly the data that cannot be changed after it leaks. The IDScan data breach has produced nine federal complaints in three days while the company's own account of the exposure and the dark web advertisement still describe different things. For teams running KYC and AML, the action item is not vendor selection theatre. It is holding less: keep the description the rule asks for, drop the images the rule does not, and stop treating an identifier printed on a plastic card as proof that the person presenting it is who they claim to be.

Cited sources

• IDScan.net, Notification of Data Security Incident
• Bunch v. IDscan.net, Inc., No. 2:26-cv-01929 (E.D. La., filed 2 September 2026)
• Sullivan v. IDscan.net, Inc., No. 2:26-cv-01956 (E.D. La., filed 4 September 2026)
• 31 CFR 1020.220, Customer identification programs for banks
• 16 CFR 314.4, FTC Safeguards Rule, elements of an information security program
• 16 CFR 314.1, purpose and scope of the Safeguards Rule
• Louisiana R.S. 51:3074, Database Security Breach Notification Law
• GDPR Article 28, processor obligations
• GDPR Article 33, notification of a personal data breach to the supervisory authority
• Federal Highway Administration, Table DL-22, licensed drivers 2024
• Brian Krebs, FBI Probes Service Selling 153M+ Drivers Licenses