A breach that took a year to notice, and it wasn’t even the victim’s network

On 1 September 2026, ID verification giant IDScan.net discovered that an unauthorised party had been sitting inside its systems, quietly pulling data out. By the time the company noticed, the attackers had already been at it, by their own account, for “over a year.” We now know roughly what they took: north of 153 million US and Canadian driver’s licences, more than 10 million ID cards, 3 million-plus travel documents, and 579,000 medical cards.

Not just names and licence numbers, either: full scans, including the infrared and ultraviolet layers used to authenticate a document as genuine, complete with timestamps. It’s about as complete a kit for identity fraud as exists outside a government database.

IDScan didn’t find this on its own. Security journalist Brian Krebs did, after spotting a new dark web marketplace called Nexus advertising searchable access to the haul on a Russian cybercrime forum. He confirmed it was real the way you’d want a journalist to: he searched for his own driver’s licence, found it, and matched the scan’s timestamp to a car rental from June 2025, more than a year before IDScan even knew it had a problem.

Why this one should worry more than just IDScan’s customers

Here’s the part that should stop consultants and compliance officers scrolling: if you’ve rented a car from Hertz, shopped at Target, shipped something through FedEx, bought a Motorola radio, banked with a Jack Henry client, checked into Caesars, or walked into one of over 1,000 licensed cannabis dispensaries across 19 US states, there’s a decent chance your ID was scanned through IDScan’s systems at some point. The company runs upwards of 21 million verifications a month across more than 20,000 locations. None of those household names had their own networks touched. Their exposure arrived entirely through a vendor two or three steps removed from the relationship their customers actually trust.

That’s the real story here, and it’s one I see play out in miniature on nearly every vendor risk assessment I run: an organisation pours real budget and real audit hours into hardening its own perimeter, then hands a mountain of sensitive customer data to a third party on the strength of a signed questionnaire and a logo that says “trusted by [big brand].” The big brand didn’t do the diligence for you. In this case, it didn’t do enough diligence for itself either.

The dwell-time problem nobody budgets for

The detail that should really sit with you is the “over a year.” This wasn’t a smash-and-grab. It was slow, continuous exfiltration. Krebs noted the dataset grew by roughly 400,000 records in the 24 hours he was watching it, meaning the pipe was still open even after the marketplace went public. A breach that runs undetected for twelve-plus months isn’t a technology failure so much as a monitoring and accountability failure: nobody was watching closely enough, for long enough, to notice a slow leak turning into a flood.

For any business handing customer data to a vendor, that raises an uncomfortable but necessary question: if your ID verification provider, payroll processor, CRM host, or document management platform were leaking data right now, would you find out from them, or from a security journalist finding your customers’ records for sale?

What this means practically

A vendor risk programme that stops at onboarding is not a vendor risk programme. It’s a compliance exercise. If this story has you wanting to check your own exposure, a few questions are worth putting to every vendor that touches identifiable customer data, and revisiting annually rather than once at signature:

  • Can they show you evidence of independent security testing in the last 12 months, not just a SOC 2 letter, but the scope of what was actually tested?
  • What does their breach notification clause actually commit them to, in writing, and does it meet the timelines your own regulatory obligations require (POPIA’s “as soon as reasonably possible,” for instance)?
  • Do you have a contractual right to audit, or are you relying entirely on their word?
  • How long is customer data retained, and could it be minimised? The less a vendor holds, the less there is to lose.
  • Who at your organisation actually owns the relationship with this vendor from a risk perspective, and when did they last review it?

None of this is exotic. It’s the same discipline organisations apply, or claim to apply, to their own environments, extended to the parts of the supply chain that hold just as much of their customers’ sensitive data and get a fraction of the scrutiny.

If you outsource identity verification, document processing, or any function that touches customer PII, this is a good week to pull the file on that vendor and actually read it, not skim the cover page. If you’d rather have someone else do that read, with a structured framework instead of a gut check, that’s precisely the kind of assessment I run for clients. Happy to talk through what it would look like for your vendor list.

References

Leave a Reply