TL;DR - On 1 September 2026, KrebsOnSecurity reported that 153 million drivers licences were being offered for sale on a Russian dark-web forum by a dark-web identity-theft service calling itself 'Nexus'. The data allegedly came from IDScan, a New Orleans-based identity verification vendor. The FBI opened a formal investigation the same day. By 4 September, multiple US class-action lawsuits had been filed. If you are an ANZ MSP, SMB IT lead, or GRC analyst, the question is not whether your data was in that batch. The question is whether any of the third-party KYC vendors in your stack were processing scans through IDScan - because if they were, you are now part of the supply chain for an incident you cannot directly audit.
Most of the KYC conversations I have with ANZ MSPs go something like this: "We use Vendor X for ID verification, it works fine, we do not worry about it." That mental model is wrong, and the IDScan incident is the cleanest demonstration of why. The data on those licences did not come from companies that used IDScan directly. It came from every company whose end-customers were scanned by an IDScan customer - which is a much larger group, and which is exactly the group that does not know they are downstream of an incident.
By the numbers: the IDScan incident in context
| Metric | Detail |
|---|---|
| Vendor | IDScan.net (New Orleans, US) |
| Volume | 153 million drivers licences advertised for sale |
| Forum | Russian-language dark-web forum (per KrebsOnSecurity) |
| Dark-web service name | 'Nexus' (went offline the day after Krebs published) |
| FBI involvement | Formal investigation opened 1 September 2026 |
| First Krebs publication | 1 September 2026 |
| Class-action filings | Multiple, by 4 September 2026 (Markovits, Stock & DeMarco; Hall Attorneys) |
| Known IDScan customers (publicly named) | Caesars, FedEx, Target, Jack Henry, Hertz (per public reporting) |
| ANZ vendor connection | Likely through US-based ID-verification resellers and KYC-as-a-service providers |
What an ANZ SMB IT lead should be doing this week
The first thing to do is the thing you should have done six months ago but probably have not: build a complete inventory of every third-party service that touches customer identity data. For most ANZ MSPs and SMBs, that list looks something like:
- KYC / ID verification at customer onboarding
- Hospitality check-in (hotels, short-stay rentals, car rentals)
- Aged care and health check-in (visitor management)
- Car rental counter ID verification
- Retail "scan to verify age" for restricted goods
- Internal HR right-to-work verification
- Government-adjacent services where you rely on a third-party vendor
For each of those, find out: who is the underlying KYC vendor, what is the data flow, and is there any path through which scanned IDs could have been processed by IDScan or one of its resellers?
Most ANZ SMBs do not have that list. They have a vendor name on the contract, but they do not know what that vendor uses internally. The IDScan incident is the moment to start asking.
Why the "we use Vendor X" mental model is wrong
The vendor you use for KYC is almost certainly not the vendor that scanned the ID. Most ANZ-facing KYC vendors (Onfido, Jumio, Veriff, the local players like Equifax / Illion / Trustmatic) operate as platform aggregators. They integrate with multiple scanning engines and route based on document type, region, and quality. You contract with the platform; the platform chooses which underlying scanning engine to use.
That is the supply chain. When an end-customer's ID is scanned at a counter in Adelaide or Auckland, the image may be routed through three or four vendors before a "pass / fail" decision comes back to the front desk. None of those vendors is visible to the customer. None of them is named in the SMB's contract. And when one of them gets breached, the SMB finds out via Krebs or BleepingComputer, not via a vendor disclosure.
This is the same shape as the SolarWinds incident in 2020, the 3CX incident in 2023, and the xz-utils incident in 2024. The compromise is at a vendor you did not know you depended on. The blast radius includes every customer of every customer.
What to ask your KYC vendor this week
Send each KYC vendor in your stack the following five questions in writing. Save the responses in your vendor risk register. The questions are written for you to copy and paste:
- Do you currently use, or have you ever used, IDScan.net (or any predecessor service operating under the IDScan brand) for any portion of your document verification pipeline? This is the direct question. If the answer is yes, you have a confirmed connection to the incident.
- Do you integrate with any third-party scanning engine that may have used IDScan as a routing destination at any point since 1 January 2020? This is the indirect question. Most platforms do not track this at the level their customers need.
- What is your process for sub-processor disclosure when a sub-processor experiences a security incident? This tests whether the vendor has a sub-processor incident notification clause in their contract. Most do not.
- What data did your sub-processor receive from scans processed through your platform during the period 1 January 2020 to 1 September 2026? If they cannot answer this, they are not tracking sub-processor data flows at the level an SMB needs.
- Are you aware of any customer data you processed that was subsequently passed to IDScan for any reason (manual review, fallback processing, training data)? This is the long-shot question. Some platforms send low-confidence scans to a human reviewer, and that human reviewer may have been IDScan.
The responses you get back will fall into three buckets:
- Bucket A - "We do not use IDScan and never have." Good. File the response and move on. Re-test the answer in your next vendor review.
- Bucket B - "We are investigating." Expected. Follow up in writing every two weeks until you have a definite answer.
- Bucket C - No response, or a deflection. Treat as Bucket B. The absence of a definite answer is itself information.
What to do if you find a Bucket C vendor
If a vendor cannot or will not answer the IDScan question in writing, you have two practical options. Option one is to push harder: escalate to the vendor's CISO or DPO, request a written attestation under your existing MSA, and put a 30-day deadline on the response. Option two is to start a parallel vendor evaluation - identify two or three alternative KYC vendors that you could swap to within 60 days, and begin the procurement conversation now even if you do not need to switch today.
The reason for option two is that a vendor that cannot answer the IDScan question in writing probably cannot answer the next vendor compromise question either. The capability gap is the issue, not the specific incident.
What this looks like for an ANZ MSP with retail and hospitality clients
If you are an MSP with retail or hospitality clients, the conversation this week should be:
- For each client, ask which KYC / ID-verification service they use at the counter.
- Ask the vendor (not the client) whether they used IDScan.
- Document the answer in the client's vendor risk register.
- For clients whose vendor falls into Bucket C, recommend a vendor evaluation as part of the next quarterly review.
For aged-care and visitor management clients, the same shape applies but the conversation is usually with the vendor of the visitor management system (which often integrates KYC invisibly as part of the check-in flow).
What this is not
This is not a story about 153 million ANZ drivers licences being on the dark web. ANZ was not the primary IDScan market. This is a story about a third-party vendor compromise that propagates through the KYC supply chain to every company whose customer data passed through any IDScan customer, directly or indirectly. The number of ANZ end-customers affected is hard to estimate without vendor disclosure, and that is the problem.
What to do this week
- Inventory every KYC / ID verification vendor in your stack. Include the named vendor on the contract and every sub-processor you can identify. If you cannot identify the sub-processors, that is the gap to fix.
- Send the five questions above in writing to each vendor. Save the responses. Follow up in writing every two weeks.
- For any vendor that cannot answer in writing, start a parallel vendor evaluation. Identify two or three alternatives. Begin the procurement conversation now.
- Document the answers in your vendor risk register. If you do not have a vendor risk register, this is a good week to start one. A spreadsheet is fine for now.
- Brief your clients. If you are an MSP, your retail and hospitality clients need to know that third-party KYC is now a first-party risk for them. They are the ones who will face the customer-facing questions if a breach trace lands back at their door.
Further reading
- KrebsOnSecurity: FBI Probes Service Selling 153M+ Drivers Licenses (1 September 2026)
- BleepingComputer: IDScan sued over alleged data breach affecting 153 million drivers (4 September 2026)
- IDScan.net public advisory (pending - check the vendor site for updates)
- Class-action filings via Markovits, Stock & DeMarco and Hall Attorneys
Mathew Clark / Founder, SecureInSeconds / Currently: rewriting my own KYC vendor inventory after reading the Krebs write-up, with the audit-trail gaps on the page in front of me
