150 Million Driver's Licenses Stolen — What Developers Should Learn From the IDScan Breach

If your app has ever asked a user to scan their driver’s license to prove their age or identity, there’s a real chance that scan passed through a vendor like IDScan — and this week is a reminder of exactly what’s at stake when it does.

What actually happened

IDScan, a Louisiana-based identity verification company used by everything from entertainment venues to cannabis dispensaries to check customer IDs, confirmed on September 10 that hackers stole driver’s license data from its cloud environment. The confirmed haul includes full names, driver’s license numbers, and identity numbers from other government-issued documents like passports. The breach was first discovered around September 1, when a dark-web marketplace called Nexus began advertising a database of over 150 million driver’s license scans, along with millions of other ID and medical card records.

Here’s the detail worth sitting with, because most coverage glosses over it: the 150-million-plus figure comes from the dark-web listing itself, not from IDScan’s own confirmed count. IDScan has confirmed the breach happened and that customer data was accessed — it has not published its own total. That distinction matters. It’s entirely possible the real number is close to what’s advertised, but “a criminal marketplace’s own sales pitch” and “a vendor’s verified count” are not the same category of evidence, and treating them as interchangeable is exactly the kind of imprecision that makes breach reporting less trustworthy over time.

Why this is worse than a typical breach

Password breaches are bad, but passwords can be rotated. A stolen driver’s license number is a static, government-issued identifier that doesn’t expire on your schedule — it’s tied to a real document that takes a government agency to reissue. Combined with a full name and a photo (license scans typically include one), this is close to a complete identity-theft starter kit, not just a login-credential leak.

The FBI is investigating alongside IDScan’s own third-party responders. IDScan is offering affected individuals free credit monitoring and identity protection — the standard post-breach playbook, though it’s worth being clear-eyed that credit monitoring detects fraud after it happens, it doesn’t prevent a static identifier from being reused indefinitely.

Why this matters specifically if you build software

This isn’t just a “watch out for phishing” story for end users. If your product integrates any third-party ID-verification, age-verification, or KYC (know-your-customer) vendor, this incident is a direct vendor-risk lesson, not a background news item — and it’s already playing out that way. Reporting has since connected several large enterprise names, including Hertz, FedEx, and Target, as IDScan clients now facing the exact question every business using a third-party verification vendor should be asking itself: what did our vendor-risk assessment actually check before we handed a security-critical function to this company? At least five lawsuits had been filed against IDScan as of September 7, with more expected as additional law firms open investigations.

• You inherit your vendor’s security posture, whether or not you audited it. Every business that used IDScan for age or identity checks is now dealing with a breach they didn’t cause and couldn’t have directly prevented — but their users are the ones exposed. This is the same lesson as any supply-chain dependency: the vendor’s blast radius becomes yours.
• Minimize what you actually retain. If your integration only needs a pass/fail verification result, question whether you (or your vendor) need to retain the underlying scanned image and extracted PII at all, versus verifying and discarding. Retention is the thing that turns “a vendor got hacked” into “150 million people’s documents are for sale.”
• Ask vendors directly about data retention and encryption-at-rest before integrating, not after. A verification vendor’s core product is handling exactly this kind of sensitive data — it’s reasonable to expect a clear, specific answer about how long scans are kept and how they’re protected, not a vague compliance-page assurance.

What to actually do if you’re affected, or use a vendor like this

• If you’re a user: check whether you’ve interacted with a business that uses IDScan (entertainment venues, dispensaries, and similar age-gated services are named in reporting), and take the free monitoring being offered — it’s limited, but it’s not nothing.
• If you’re a developer or business using an ID-verification vendor: ask your vendor directly, now, what data they retain post-verification and for how long, rather than assuming “compliant” means “minimal retention.” Those are not the same thing.
• If you’re evaluating a new vendor: treat “how long do you retain scanned documents” as a first-tier question in vendor selection, not a follow-up.

Official reference: reporting from TechCrunch and BleepingComputer, both confirming IDScan’s own breach notice as of September 10, 2026 — treat the specific record count as originating from the dark-web listing, not an independently verified figure, until IDScan or law enforcement publishes their own number.