The IDScan Breach Isn’t Just IDScan’s Problem: What 150 Million Stolen Driver’s Licenses Means for Every Business That Used the Vendor

Did somebody say Third Party Risk Management? Did your assessment catch that IDScan, an identity verification service used by businesses ranging from entertainment venues to cannabis dispensaries to check customers’ government-issued IDs, has confirmed what independent security journalist Brian Krebs first reported on September 1: hackers stole driver’s license data, including full names, license numbers, and identity numbers from other government documents like passports, from the Louisiana-based company’s cloud environment. The stolen data reportedly surfaced on a dark web marketplace covering more than 150 million people across the United States and Canada, complete with photos, and reportedly included high-profile individuals such as U.S. Secretary of Defense Pete Hegseth. The Pentagon and the FBI have both confirmed they are looking into the incident.

The breach itself is the headline. The compliance question underneath it is the one that actually matters for every business that ran customer ID checks through IDScan: this is not solely IDScan’s incident to notify and remediate. It is, functionally, an incident for every corporate customer whose end users had their identity documents processed through IDScan’s systems, and those companies now have their own breach notification exposure to assess, on a timeline they don’t fully control.

Why This Is a Third-Party Breach, Not Just a Vendor’s Breach

Identity verification services occupy an unusual position in the vendor stack. A business using IDScan to check a customer’s driver’s license at the door of a venue, or during an age-gated cannabis sale, isn’t sending IDScan marginal marketing data. It’s routing one of the most sensitive categories of personal information that exists, government identity document numbers, directly through a third party specifically because verifying that document is the entire point of the transaction. When that vendor is breached, the affected individuals are the downstream business’s customers, not IDScan’s, and most state breach notification statutes place the notification obligation on whichever entity has the direct relationship with the affected individual, not solely on the vendor that was actually compromised.

That structural fact means a company that has never had its own systems touched can still be sitting on an active breach notification obligation right now, triggered entirely by a vendor’s incident it read about in the news before hearing from the vendor directly.

What Businesses That Used IDScan Need to Determine Immediately

1. Confirm whether your customer data was actually in scope. Not every IDScan customer necessarily had data included in this specific breach, but confirming that requires direct engagement with the vendor, not an assumption based on the news coverage alone.
2. Pull your contract with IDScan and check the breach notification clause. Most vendor agreements involving identity verification specify a notification timeline the vendor owes you once it discovers or confirms an incident. Confirm IDScan met that timeline, and use the contract to press for the specifics you need to run your own notification analysis.
3. Run a state-by-state breach notification analysis based on where your affected customers live. Driver’s license numbers and other government ID numbers are covered personal information under essentially every U.S. state breach notification statute, and notification deadlines, content requirements, and attorney general notice thresholds vary meaningfully by state. A company with customers across multiple states is very likely running several notification clocks simultaneously, not one.
4. Determine whether you have an independent notification obligation or can rely on the vendor’s notice. In some cases, a vendor’s own notification to affected individuals can satisfy a downstream business’s obligation; in many others, the business with the direct customer relationship still has to notify separately. This is jurisdiction-specific and worth confirming with counsel rather than assuming either way.
5. Evaluate credit monitoring or identity protection service obligations. Several state statutes and a meaningful share of past breach settlements involving government ID numbers specifically have included mandated or expected credit monitoring offers, given how directly a stolen driver’s license or passport number can enable identity theft.
6. Document your response timeline from the moment you learned of the incident. Given that this breach became public through independent reporting before formal vendor notification, a documented record of exactly when your organization learned of the incident, and what it did next, is important evidence if your own notification timeline is ever questioned.

The Broader Vendor Concentration Lesson

This incident is also a clean illustration of a risk that rarely gets attention until something like this happens: identity verification is a function many businesses treat as a checkbox vendor decision, not a data governance decision, precisely because the vendor’s entire value proposition is making the compliance-critical function disappear into a simple API call. That convenience comes with concentration risk. A single identity verification vendor holding driver’s license and passport data for millions of people across thousands of corporate customers is exactly the kind of target that produces a breach at this scale, and every one of those corporate customers inherited that concentrated risk the moment they integrated the vendor, whether or not it was ever discussed as a vendor risk decision internally.

Businesses relying on any identity verification, age verification, or document-checking vendor should treat this as the occasion to ask questions that are easy to skip during procurement: how long does the vendor retain the actual document images and numbers after verification, does verification require full document retention at all or could it be architected around a pass/fail signal instead, and what does the vendor’s own breach notification commitment to you actually specify in writing.

A Practical Response Framework

1. Engage IDScan directly and in writing to confirm your organization’s specific exposure, rather than relying on the public notice alone.
2. Activate your incident response process now, treating this as your own potential breach event pending confirmation, not a wait-and-see vendor issue.
3. Map every state where affected customers reside and build a notification timeline against each applicable statute in parallel.
4. Loop in counsel on whether the vendor’s notice satisfies your own obligation or whether independent notification is required in each relevant jurisdiction.
5. Prepare a customer-facing notification and credit monitoring offer ahead of any statutory deadline, rather than waiting for full clarity from the vendor, given how sensitive the data category involved is.
6. Review your broader identity verification vendor relationships for the same concentration and data retention questions this incident raises, independent of whether you used IDScan specifically.

The Bottom Line

A breach at an identity verification vendor is never contained to that vendor. It immediately becomes a notification and governance question for every business that handed that vendor its customers’ most sensitive identity documents, and the timeline for answering that question starts the moment the business learns of the incident, not the moment the vendor finishes its own investigation. Companies that used IDScan should be running their breach notification analysis now, and every company relying on a similar identity verification vendor should be treating this as the reason to ask exactly what that vendor is holding, for how long, and what it owes you the moment something like this happens.

Frequently Asked Questions

Do I need to notify my customers if my vendor, not my own systems, was breached?

In many cases, yes. Most state breach notification laws place the obligation on the entity with the direct customer relationship, not solely on the vendor whose systems were actually compromised, particularly when the vendor was processing data on your behalf.

Are driver’s license numbers considered sensitive enough to trigger breach notification laws?

Yes. Driver’s license numbers and other government-issued identification numbers are covered as personal information under essentially every U.S. state breach notification statute, and their exposure frequently triggers mandatory notification and, in many states, credit monitoring or identity protection offers.

What should a business do first after learning a vendor it uses was breached?

Engage the vendor directly and in writing to confirm the specific scope of your exposure, activate your internal incident response process immediately rather than waiting for full vendor confirmation, and begin a state-by-state notification analysis based on where affected individuals reside.

Can a vendor’s breach notification satisfy my own legal obligation to notify?

Sometimes, but this depends on the specific state statute and the nature of the relationship between the vendor and the affected individuals. This determination should be made with counsel on a jurisdiction-by-jurisdiction basis rather than assumed.

What should businesses ask identity verification vendors going forward?

How long the vendor retains actual document images and numbers after verification, whether verification could be architected around a pass/fail signal rather than full document retention, and what specific breach notification commitments the vendor owes its corporate customers in writing.