New Orleans-based IDScan.net has confirmed a breach of its cloud storage, following reporting that a dark-web marketplace called Nexus was selling more than 170 million identity documents, including 153 million U.S. and Canadian driver's licenses, plus millions of additional ID cards, travel documents, and medical cards. In a notification statement, IDScan said that around September 1, 2026, it learned that an unauthorized third party may have accessed and copied customer information stored in accounts on its cloud platform — including full names and driver's license or other government-issued ID numbers. The company is offering free identity protection and credit monitoring to those affected, and says it's cooperating with federal law enforcement, whose investigation (led by the FBI's New Orleans field office) is ongoing. IDScan is also facing at least four proposed class-action lawsuits.
One detail from the reporting is worth sitting with: security journalist Brian Krebs found evidence that the dark-web listings were receiving newly stolen records in near real time, suggesting an ongoing compromise rather than a single historical dump. That's only possible because there was a live, growing store of documents to keep drawing from.
IDScan's tools — best known under its VeriScan brand — are used across car rentals, retail, financial services, hospitality, and cannabis to scan and authenticate government-issued ID. That's a wide footprint, and the breach is already prompting exactly the question this piece is about: whether identity-verification vendors should be holding onto raw document images and numbers at all, rather than verifying and discarding.
The vulnerability isn't verification. It's storage.
When a business sends a customer's driver's license to a third-party verification vendor, the customer has essentially no visibility into what happens to that image afterward — discarded immediately, stored for fraud-model training, retained for compliance, or just sitting in an account on the vendor's cloud "in case it's needed." Multiply that across every rental counter, dispensary, and retailer using the same vendor, and you get exactly the shape of what happened here: one vendor's stored data becoming a single point of failure for documents collected by hundreds of unrelated businesses.
That's the pattern behind most large-scale ID verification breaches — not a flaw in the idea of verifying age or identity, but a consequence of the record existing somewhere long enough for someone to steal it.
Why this scenario doesn't map onto our architecture
XYZ Age Verification was built specifically to not be that single point of failure:
- No permanent document store. We don't keep a database of driver's license images, because we don't keep the image once verification is complete. Documents are processed for the seconds it takes to extract and confirm an age determination, held only in ephemeral storage with a short TTL, and then they're gone. There's nothing sitting around to breach, subpoena, or accidentally leave exposed in a misconfigured bucket two years from now.
- Certified liveness and face matching, not a black box. Liveness and face-match run through AWS Rekognition, certified to iBeta Level 2 Presentation Attack Detection standards — built to catch spoofing without a human reviewer looking at your face or your ID.
- No manual review queue. A lot of ID verification vendors route edge cases to a human agent, which means your document sits in a review tool or an inbox somewhere, often for an indefinite period, often accessible to more staff than anyone advertises. Our redress model is automated retries within the same session instead — arguably faster for the user, and it never creates a document queue in the first place.
- Parsing happens in memory. Document parsing, including our MRZ fallback chain for license and passport data, runs against the document in flight — not against a stored copy.
Being honest about what this does and doesn't mean
No architecture eliminates every risk. Data still moves through the pipeline in transit, we still depend on infrastructure providers during the verification window, and any system processing sensitive documents deserves ongoing scrutiny rather than a permanent pass. Zero-retention design doesn't mean nothing could ever go wrong — it means one specific, high-consequence failure mode is off the table by construction: there's no XYZ database of driver's license images for an attacker, a subpoena, or a storage misconfiguration to expose, because we never had it to begin with.
That's a meaningfully different risk profile than a vendor whose business model depends on holding onto documents after the yes/no answer has already been given. "We never had your data" holds up in a way "we delete your data eventually" doesn't — deletion policies are promises; not having the data is a fact about the system.
What to ask any ID verification vendor
If you're evaluating age or identity verification for your own site, the IDScan situation is a reasonable prompt to ask vendors directly:
- Do you keep a copy of the ID after verification completes, and for how long?
- Is there a human review queue, and who has access to it?
- What's stored if there's a dispute or an appeal?
- Is the liveness/match assessment independently certified (iBeta, for example), or is it an unaudited in-house model?
- If your systems were breached tomorrow, what would actually be in the database?
If the answer to the first question is "we hold onto it," that's a decision the vendor is making about your customers' most sensitive documents — not a regulatory requirement. Zero-retention verification exists so that businesses using age verification don't have to hope a vendor's storage practices never end up in a lawsuit like the one IDScan is facing now.