The Breach Nobody Saw Coming—and Everyone Should Have
On September 10, 2026, identity verification company IDScan finally admitted what the security community had known for nine days: hackers got into its cloud platform and walked out with customer data. Specifically, full names and government-issued identification numbers pulled from accounts hosted on IDScan.net. According to TechCrunch, who spotted the company's breach notification, IDScan said an unauthorized third party "may" have accessed or copied that information.
Nine days. That's how long IDScan sat silent while lawsuits piled up and Brian Krebs publicly verified that a dark-web marketplace called "Nexus" was selling more than 153 million US and Canadian driver's license scans traced directly back to their platform.
If that timeline sounds familiar—if the pattern of slow disclosure, minimal language, and "in an abundance of caution" notification feels like a broken record—you're not wrong. The Coupang data breach followed almost the same arc: a third-party or vendor-connected compromise, a quiet period, then a notification that told affected users almost nothing they hadn't already pieced together from open-source reporting.
What Actually Got Stolen
Here's the inventory, pieced together from IDScan's notification and Krebs's reporting:
- 153 million+ US and Canadian driver's license scans
- 10 million ID cards
- 3 million travel documents
- 579,000 medical cards
That's not a list of hashed passwords or stale email addresses. Those are the raw materials for identity fraud at industrial scale. A driver's license scan gives a criminal the full name, date of birth, address, license number, physical description, and photograph on a government-issued document. Combined with enough supplementary data, it's sufficient to open bank accounts, file fraudulent tax returns, or impersonate someone in a video KYC check.
IDScan's notification confirmed names and ID numbers. The scan images themselves—arguably the juicier prize—weren't explicitly mentioned in the company's disclosure. That's a notable omission.
How the Breach Surfaced
The incident didn't start with IDScan's notification. It started on September 1, when Krebs reported that "Nexus", a dark-web platform, was advertising access to that massive database. He verified samples by searching for his own records and those of volunteers, then traced the data back to IDScan.
BleepingComputer followed up on September 4, reporting that multiple lawsuits had already been filed. IDScan didn't respond. The breach notification was published September 4, but configured with a noindex directive that kept it out of search engine results. They'd put the announcement up but effectively hidden it.
It took a full week of external pressure before IDScan went public.
The ShinyHunters Overlap
The source article from BleepingComputer references "ShinyHunters" in its related-articles sidebar and the broader pattern of SaaS-platform compromises attributed to this threat cluster. ShinyHunters has been connected to a string of high-profile cloud and SaaS breaches throughout 2025 and 2026, typically leveraging social engineering, vishing and device-code phishing, to bypass authentication controls on cloud service providers.
We can't confirm IDScan is specifically a ShinyHunters operation from the available reporting. The FBI confirmed to BleepingComputer that it's investigating. But the method, compromise of a cloud-hosted vendor platform storing sensitive identity documents, matches the playbook this group has used repeatedly. The Ernst & Young breach, the Salesforce-linked campaigns, the platform compromises that led to the Coupang data breach: all share the same structural weakness. A vendor trusted with sensitive data. A cloud environment that inherits the customer's trust but not the customer's scrutiny.
The Notification That Wasn't
IDScan's language is a masterclass in minimizing. They said access to the exposed information "required payment", meaning the Nexus marketplace wasn't handing the data out for free, and that they were notifying people "in an abundance of caution."
They also confirmed they were "reviewing policies and procedures related to data security" and cooperating with federal law enforcement.
What they didn't say: how the attackers got in. Whether the breach involved stolen credentials, an API vulnerability, a misconfigured cloud bucket, or a supply-chain compromise. Whether the "review" was triggered by this incident or was already underway. Whether the noindex directive on their September 4 notification was a technical default or a deliberate choice.
The absence of a technical explainer after a 153-million-record compromise is itself a signal. Either the investigation is far from complete, or the explanation doesn't reflect well on them.
The Third-Party Identity Store Problem
IDScan's platform is used by car rental companies, retailers, financial institutions, cannabis dispensaries, gun shops, and hospitality businesses. Every one of those industries uses IDScan to verify customers at the point of transaction, rental counters, hotel check-ins, dispensary counters. The platform scans, authenticates, and extracts information from government-issued IDs.
Here's the structural problem: that scanning process creates a data store. When you verify a customer's identity by scanning their license, the scan data often persists longer than anyone thinks it should. A comment on the BleepingComputer article put it bluntly: "Why were they holding onto copies of the ID after they were scanned and verified?"
That question applies to every identity verification vendor. Every time a business outsources KYC or age verification to a cloud service, it creates a honey pot, the same structural exposure that led to LastPass's CRM data exposure via a third-party OAuth incident. The data isn't encrypted in transit to the criminal, it's already sitting in a cloud platform that presumably has some access controls but maybe not the kind that stop a determined social-engineering attack.
The Coupang data breach taught us a related lesson: the vendor you don't directly interact with may know more about your customers than you do. Coupang's partners stored data that, once exposed, gave attackers a map of the entire supply chain. IDScan's breach is the same pattern with more stakes, these aren't purchase histories, they're government-identity documents.
What the Pattern Looks Like
Pull back from any single breach and a shape emerges. Here's the company data breach examples sequence that recurs across incidents from Coupang to IDScan to Ernst & Young to the FBI portal compromise:
- A vendor accumulates sensitive data as a byproduct of providing a service.
- An attacker gains initial access through the vendor's cloud environment, often via stolen credentials or social engineering rather than a software exploit.
- The vendor either doesn't detect the compromise or chooses not to disclose immediately.
- External researchers, journalists, or the criminals themselves surface the breach.
- The vendor confirms with minimal language, offers credit monitoring, and avoids technical detail.
This is the cloud security incident response playbook every CISO says they have. Most of them are paper exercises.
What to Do If You Use a Verification Vendor
If your organization uses IDScan, Jumio, Onfido, Veriff, or any similar platform, here's what's actionable right now:
Ask your vendor to disclose their retention policy. Not the marketing language, actual data-flow documentation. How long are scans held? Where? Who has access?
Demand a breach-notification SLA with a clock. "In an abundance of caution" isn't a timeline. Contractually bound disclosure within a specific window, with penalties.
Assume breach in your risk model. If your vendor stores customer identity documents, treat a compromise as inevitable. What's your containment plan? Who do you notify? How do you explain to customers that their driver's license is for sale on Nexus?
Minimize what you send. If your integration only needs a binary "yes, this is a valid license," don't send the full image. Ask whether partial verification, name match, document authenticity check without image retention, is available.
The Bigger Question Nobody Answers
153 million driver's licenses. That's roughly 60% of the US driving-age population. If the database is legitimate, and Krebs's verification suggests it is, then identity verification as an industry has created a single point of failure for identity fraud across an entire continent.
IDScan isn't the first vendor to learn this lesson. They won't be the last. The Coupang data breach didn't stop the next vendor from accumulating the same data with the same architecture. Ernst & Young didn't. The FBI portal compromise won't.
The comment that asks "why were they holding onto copies" deserves a better answer than "in an abundance of caution."
What We Still Don't Know
- How the attackers gained initial access. No technical vector disclosed.
- Whether the breach is contained. "We began an investigation" isn't a containment statement.
- The true scope. IDScan confirmed names and ID numbers in their notification. Whether the 153M scans were in that platform or a downstream data store remains murky.
- Whether the Nexus platform operators had a prior relationship with IDScan or are opportunistic buyers of stolen data.
These aren't minor gaps. For organizations relying on IDScan to verify customers, the "how" determines whether the risk is closed or ongoing.
This article was written while the situation remains active. Facts sourced from BleepingComputer's reporting by Lawrence Abrams, published September 10, 2026.
