Published: September 29, 2026
Published: September 29, 2026
The Breach and the Response
Nearly four weeks after hackers began advertising searchable scans of what operators claimed were more than 153 million driver's licences on a Russian cybercrime forum, there has been no enforcement action from the FTC and no confirmed state attorney general enforcement proceeding in the public record — though confidential investigations cannot be ruled out and a breach notification filed with a state AG is distinct from a public enforcement action. The identity verification provider's September 4 notice confirmed it secured its systems, engaged third-party investigators, reviewed its data-security policies, cooperated with federal law enforcement, and is offering free credit monitoring to potentially affected individuals. What it does not address is the underlying architecture — how data accumulated, under what retention defaults, and what if anything changes as a result. The FBI's New Orleans field office opened an inquiry on September 1. The Office of the Privacy Commissioner of Canada (OPC) launched a formal investigation on September 21 OPC investigation announcement. As of publication, that is where the institutional response stands.
The enforcement picture is incomplete. It is also, for identity practitioners, secondary. The more durable question raised by the IDScan.net incident is not which agency acts next. It is why an architecture that centrally accumulates tens of millions of government-issued identity documents in a B2B vendor's cloud environment existed in the first place — and what that means for the organisations that built their compliance workflows on top of it.
Market context: The Scale and Its Limits
The figure circulating — reportedly more than 153 million driver's licence records from the United States and Canada combined, attributed to the operators of the Nexus service, not to IDScan.net itself — was described by WBUR as representing more than half of all licensed drivers. That comparison uses a US-only denominator against a dataset that Krebs on Security confirmed includes Canadian records; the proportion should be read as an approximation of order of magnitude, not a precise ratio. The Nexus dataset also reportedly includes more than 10 million ID cards and approximately 579,000 medical cards. IDScan.net has not confirmed the scope. The 153 million figure should be treated as reported, not verified, but its approximate order of magnitude is consistent with what IDScan.net's customer base and operational history would plausibly support.
Shortly after the original Krebs on Security story published on September 1, the Nexus service vanished from the dark web. Whether the underlying data persists in other hands is a separate question from whether Nexus itself remains accessible; stolen copies of this kind of dataset do not disappear when the original marketplace does.
The National-Security Dimension
Government-issued identity documents — driver's licences, passport identity pages, cannabis dispensary intake forms that captured government IDs — are not simply credentials for fraud. They are the substrate of identity itself. They carry legal names, dates of birth, residential addresses, physical descriptors, and government-assigned identifiers.
A dataset of this type and scale has a value to foreign intelligence operations that extends well beyond its criminal market price. The same database that enables domestic fraud — synthetic identity construction, account takeover, document replay attacks — enables foreign adversaries to map, profile, and potentially identify individuals with government affiliations, security clearances, or positions of influence. Krebs on Security reported that the Nexus dataset included a driver's licence attributed to Defense Secretary Pete Hegseth Krebs reporting. At a dataset of this scale, the counterintelligence concern and the criminal concern are not separable use cases.
That context may help explain why the FBI, rather than the FTC, is the primary investigator.
The Architecture Question
The practitioner-relevant analysis is not primarily about IDScan.net's security posture, though that question is legitimate and unresolved. It is about the architectural model that made this breach possible, and about the alternatives.
Centralised scan retention is the model IDScan.net operated. The vendor receives a document scan or image at verification time, stores it in its own infrastructure, and retains it — either for audit and compliance purposes, for reuse across subsequent verifications, or simply as a default that was never deliberately changed at the customer level. The security risk of this model is proportional to the aggregate size of the stored dataset: a breach of one system yields records on millions of individuals who interacted with dozens or hundreds of unrelated businesses. The dataset's value to attackers compounds with its size.
IDScan.net's VeriScan support documentation confirms that the platform's default configuration is to collect all data fields — including document images and attachments — and to retain all records in the cloud indefinitely. Configurable deletion controls exist, but they are only available to Premium, Enterprise, and ID Authentication plan customers; the Basic plan defaults to collect all and cannot be changed. The documented defaults illustrate how large stores can accumulate. Available sources do not establish which settings governed the affected accounts or how those settings contributed to the breached dataset.
Match-and-discard is an architectural alternative. Under this model, the verification transaction extracts the necessary attributes, confirms document authenticity, returns a compliance record to the relying business, and discards the underlying document data. No persistent store accumulates at the vendor. A breach of this infrastructure would expose transaction logs and attribute records rather than the document images and raw scans that make a centralised-retention breach so damaging — though the completeness of that protection depends on what the implementation actually discards and when.
On-device processing takes this further, keeping the document data on the user's device throughout the verification flow. The extracted attributes — or a cryptographic assertion about them — travel to the relying party. The document image and raw data never leave the device, and nothing accumulates at the vendor. The FinCEN CIP guidance issued on September 8 clarifies how qualifying government-issued documentary credentials presented through verifiable digital credential systems may satisfy existing Customer Identification Program requirements for financial institutions — a regulatory clarification that creates a compliance pathway for this kind of approach for that specific credential type, though it does not itself endorse any particular vendor architecture.
Tokenised document references sit between these options. The vendor retains a reference that allows it to respond to future queries about a previously verified individual without retaining the underlying document data. This reduces the breach surface compared to raw document image storage, though it does not eliminate all linkage or identification risk.
None of these alternative architectures eliminates fraud risk. Each makes a different trade-off between operational utility, downstream access to document data, and the consequences of a breach. The IDScan.net incident makes those trade-offs concrete in a way that vendor documentation does not.
What Buyers Owe Their Diligence
The IDScan.net breach is not primarily a story about IDScan.net's security team. It is a story about due diligence and about what questions the market has historically not required vendors to answer.
The organisations that contracted with IDScan.net — cannabis dispensaries, car rental desks, entertainment venues — operate in compliance-driven contexts where an ID-scanning product is a functional requirement, not a technology investment. The reviewed sources do not establish what those customers were told about data handling, what affected individuals were told, or what consent was obtained. Those controls are configured by the business customer; what happened in practice at each account is not established by available sources.
The problem is that the downstream consequences of that gap are not borne by the business customer. They are borne by the individual whose government-issued identity document ended up in a breached database.
This has implications for the identity verification industry beyond IDScan.net. Any vendor that operates centralised scan retention with collect-all defaults is holding a dataset whose value to attackers grows over time. Any relying business whose IDV contract does not specify data handling, retention defaults, deletion options, and breach notification procedures is accepting a risk it may not have knowingly taken on.
That exposure is now moving into civil litigation. At least five class-action lawsuits had been filed against IDScan.net in the U.S. District Court for the Eastern District of Louisiana as of early September, generally alleging negligence and violations of privacy and consumer-protection laws. The common thread: individual plaintiffs who never contracted with IDScan.net, now seeking relief against the vendor whose infrastructure held their data. This is the supply-chain liability theory the industry has discussed abstractly. It is now active litigation.
Nearly four weeks on, the institutional response includes an FBI field office investigation and a formal investigation opened by the Office of the Privacy Commissioner of Canada on September 21. As of September 29, 2026, no FTC civil action and no state attorney general enforcement proceeding has been confirmed in the public record. A breach notification filed with a state AG is distinct from a public enforcement action; the absence of a confirmed public action does not rule out confidential inquiry.
This is partly a function of legal process timelines: FTC investigations and state AG actions take months to develop, and their absence nearly four weeks after a breach becomes public does not mean they are not coming.
But it also reflects something structural. The US privacy and data security enforcement framework was not built for B2B vendors whose primary relationship is with business customers rather than individual consumers. The individuals whose documents were exposed are not IDScan.net's customers. They are third parties to a contract between IDScan.net and a dispensary or a car rental company. The legal pathway to consumer relief is less direct than it would be in a breach of a consumer-facing service.
The FTC's Section 5 authority is broad enough to reach IDScan.net's data practices. Whether the current commission acts is a separate question, and one that practitioners should not rely on for resolution.
What the enforcement picture confirms is that the primary protection for individuals is not enforcement after a breach. It is architecture that does not create the conditions for this kind of breach in the first place.
The IDScan.net incident illustrates supply-chain risk at a B2B vendor serving multiple industry verticals. An individual may present an ID to a car rental desk, dispensary or venue without choosing the verification vendor. Available sources do not establish what affected individuals were told about that downstream relationship.
Questions for Practitioners
For identity practitioners, the operational questions are immediate:
- If you are a vendor: What are your default data collection and retention settings, and do your customers know what plan tier they need to change them? If the honest answer is "collect all, retain indefinitely, Basic plan cannot opt out," that is the answer your customers need before the next breach, not after. - If you are a buyer: What did you agree to in your IDV vendor contract regarding data handling, retention defaults, and deletion options? What are your notification rights and remediation obligations if that vendor experiences a breach? The IDScan.net case is the scenario that clause was meant to address. - If you are an operator: The individuals handing you their documents are extending trust to your business, not to your technology stack. The due diligence you perform on your IDV vendor is an important check between their government-issued identity data and the next centralised store that attracts an attacker — alongside contract terms, regulatory obligations, and your own data minimisation practices.
The enforcement response, when it comes, will be backward-looking. The architecture question is forward-looking. That is where the industry's attention should be.
Primary sources:
- Krebs on Security, September 1, 2026: https://krebsonsecurity.com/2026/09/fbi-probes-service-selling-153m-drivers-licenses/ - IDScan.net breach notice, September 4, 2026: https://idscan.net/notification-data-security-incident/ - IDScan.net VeriScan retention documentation: https://support.idscan.net/veriscan-cloud-portal/data-collection-and-retention - Office of the Privacy Commissioner of Canada, September 21, 2026: https://www.priv.gc.ca/en/opc-news/news-and-announcements/2026/nr-c_260921/ - Fox 8 Live, September 6, 2026 (FBI inquiry): https://www.fox8live.com/2026/09/06/fbi-looking-into-drivers-license-data-breach-possibly-linked-new-orleans-id-verification-firm/ - Shattered.io, September 14, 2026 (class actions, no confirmed FTC/AG action): https://shattered.io/idscan-net-breach-no-ftc-ag-action-153-million-ids-2026/ - FinCEN, September 8, 2026: https://www.fincen.gov/resources/statutes-regulations/guidance/frequently-asked-questions-regarding-treatment-verifiable - WBUR, September 22, 2026 (US denominator caveat): https://www.wbur.org/onpoint/2026/09/22/is-your-drivers-license-on-the-dark-web