A continuously updated KYC breach tracker logging every major identity verification provider incident: Persona, Sumsub, IDmerit, AU10TIX and Veriff, with dates.
Table of contents
- Yes, multiple identity verification providers have been breached. This tracker logs each major incident with dates, scope, data types and a verified root cause.
- IDmerit: an unprotected MongoDB database attributed by Cybernews exposed roughly 1 billion KYC records across 26 countries (discovered 11 November 2025). IDmerit disputes ownership of the data.
- Sumsub: a July 2024 intrusion through a third-party support ticketing platform went undetected until a January 2026 review, publicly disclosed on 4 February 2026, an 18-month detection gap.
- Persona: researchers found roughly 2,500 files of its government dashboard code (53MB) on a public FedRAMP Google Cloud server, disclosed around 19 February 2026.
- AU10TIX left admin credentials live for over a year; Veriff exposed 8,583 Total Wireless customers. The pattern is architectural, not bad luck.
A KYC breach is any incident where personal data collected for know your customer or identity verification leaks, is accessed without authorisation, or is left exposed. Across recent IDV provider incidents the cause is rarely broken encryption. It is a misconfigured store, a stale credential, a support tool, or a long dwell time before anyone notices.
TL;DR
Multiple identity verification vendors have been breached since mid-2024, and every KYC breach in this tracker shares one root design. A MongoDB attributed by Cybernews to IDmerit exposed around 1 billion KYC records across 26 countries. Sumsub disclosed a July 2024 intrusion through a third-party support tool that went undetected for roughly 18 months. Researchers found Persona's government dashboard code on a public server, and AU10TIX and Veriff both reported incidents. The thread running through every KYC breach here is not weak encryption. It is the fact that a centralised vendor must aggregate sensitive identity data into one store, which becomes a honeypot worth attacking. This KYC breach tracker logs each verified incident and explains why the failure is structural, not a one-off bug.
KYC breach tracker by the numbers
Figures below are computed from the incidents logged on this page as of 18 September 2026. They are updated each time an incident is added and the date changes with them.
- Incidents logged: 7 identity verification providers or KYC data holders since July 2024 (IDmerit, Sumsub, Persona, the Discord and 5CA vendor incident, AU10TIX, Veriff, Coinbase).
- Largest by records: the database Cybernews attributed to IDmerit, roughly 1 billion records, with the attribution disputed by the named vendor.
- Longest undetected: Sumsub, an intrusion from July 2024 found in January 2026, about 18 months.
- Most common entry point: a third-party support platform or outsourced support staff, in 3 of 7 incidents (Sumsub, Discord and 5CA, Coinbase and TaskUs).
- Incidents involving a cryptographic break: 0. Every incident in the log came through a credential, a misconfiguration, an exposed artefact or a person.
Four of these incidents, IDmerit, Sumsub, the Discord and 5CA incident and Coinbase, are also records in our AML enforcement tracker, where each has a permanent link and a labelled source. The tracker's identity-data breach records download as a spreadsheet at breaches.csv, which also holds the July 2026 AssuranceAmerica driver's license breach. Persona, AU10TIX and Veriff are documented on this page only, with their sources in the cited sources list below. The full tracker is also published as CSV, JSON and RSS under CC BY 4.0.
Has Persona had a data breach?
Yes, with a caveat about what kind of incident it was. Around 19 February 2026, independent security researchers found roughly 2,500 files totalling 53MB of Persona's government dashboard codebase sitting on a public Google Cloud server connected to the United States FedRAMP programme. The exact 2,456-file count traces to the researchers' own technical analysis rather than to mainstream reporting; Fortune rounds it to approximately 2,500 files. This was an exposure of source code, not a confirmed theft of customer records, but the code itself was revealing.
The exposed codebase showed 269 distinct verification checks, including adverse-media screening across 14 categories such as terrorism and espionage, and watchlist facial recognition. Separate researcher analysis of Persona's dashboard code and policy indicated biometric and identity data could be retained for up to three years; that retention figure comes from the code and policy review, not from any customer statement. Discord, whose name surfaced in the coverage, told Fortune its Persona trial lasted less than a month and that it would not proceed with Persona, so frame this as a partnership Discord declined to pursue rather than a deal cancelled because of a leak.
A separate and earlier Discord incident is often conflated with the Persona code exposure, so keep them distinct. On 3 October 2025 Discord disclosed a breach of a third-party customer-service provider, later named as 5CA, that exposed roughly 70,000 users' government ID images along with names, emails, usernames and IP addresses. Attackers using the handle Scattered Lapsus$ Hunters social-engineered a 5CA support agent. 5CA, for its part, disputes wrongdoing and says none of its systems were involved and that it does not handle government IDs for Discord, so attribute the vendor link to Discord's account with 5CA's denial on record. Discord said the trial data tied to that flow was deletable within about seven days, and it terminated its 5CA contract. For the broader case study of how this style of breach plays out, see our Coinbase data breach analysis.
What happened in the Sumsub data breach?
According to Sumsub's own Security Incident Update, an external threat actor submitted a malicious attachment through a third-party support ticketing platform in July 2024. The activity was confined to an internal support environment and went undetected until a January 2026 security review surfaced it, an interval of roughly 18 months. Sumsub publicly disclosed the incident on 4 February 2026; the January 2026 date is when the activity was detected internally, not when it was announced, so the accurate framing is detected January 2026, disclosed February 2026.
On scope, Sumsub states the exposed data was limited to names plus a subset including emails and phone numbers. Critically, the company says biometrics, identity document images, bank and payment details, and government-issued identity data were not accessed. That is a meaningfully smaller blast radius than several other incidents in this tracker, and the vendor self-disclosure is worth crediting. The standout figure is not the data type but the dwell time: an intrusion can sit inside a support environment for a year and a half before a review catches it. A long detection gap is itself a KYC breach risk, because the window for quiet data movement is measured in months, not minutes. This KYC breach also shows that a vendor's support tooling, not just its core platform, is part of the attack surface.
How big was the IDmerit data leak?
Cybernews discovered an unsecured MongoDB instance on 11 November 2025 that it attributed to IDmerit, exposing roughly 1 billion personal KYC records across 26 countries. The exposed fields reportedly included full names, addresses, postal codes, dates of birth, national identification numbers, phone numbers and emails. The United States was the most affected jurisdiction with 203M+ records (Cybernews gives both over 203 million and about 204 million), followed by other countries including Mexico, the Philippines and Germany. The database was secured by 12 November 2025.
In fairness to the named vendor, IDmerit disputes ownership of the data. It states it does not own, control or store the underlying records, and has characterised the data as tied to independent data sources and a ransom-related context. So the accurate attribution is a MongoDB attributed by Cybernews to IDmerit, with the company's denial on record. Whoever controlled it, the contrarian point stands: the real scandal is not the missing protection, it is that around a billion identity records sat in one queryable place at all. A single open store should never be able to expose a billion people, and in a centralised design it can. This is the largest incident by volume in the tracker, yet the cause Cybernews describes is the most mundane: a store with nothing protecting it.
What about AU10TIX, Veriff and the other providers?
AU10TIX, an identity verification provider used by TikTok, Uber, X and others, exposed a set of administrative credentials online for more than a year. The credentials were likely compromised via malware in December 2022 and were still active when a researcher discovered them, as reported by 404 Media in June 2024 and covered by Malwarebytes. They gave access to a logging platform with links to identity documents, names, dates of birth, nationalities and identity numbers. The failure class here is stale, long-lived credentials that nobody rotated.
Veriff suffered a separate incident affecting customers of Total Wireless, a Verizon-owned mobile virtual network operator. Unauthorised access occurred on or around 18 November 2025 and was detected on 10 December 2025, the same day Veriff notified Total Wireless. Roughly 8,583 United States customers were affected, with exposed government-ID images, postal addresses and dates of birth; consumer notifications began on 9 January 2026, and multiple class actions followed.
For completeness as a reference page: among other large centralised incumbents, there is no confirmed public breach on the record for Onfido, Jumio, Trulioo or Socure as of this update. Absence of a headline is not proof of a different architecture, though. Each still operates the same centralised collect-and-store model that produced the incidents above. Our guide to identity verification software comparison covers how these vendors line up on capability.
Why do identity verification providers keep getting breached?
Because the model is architectural, not a run of bad luck, and the same KYC breach pattern repeats because the underlying design does. Regulation requires regulated firms to collect and verify customer identity, and the dominant way to do that has been to hand raw personal data to a vendor, which aggregates it into one store. That store becomes a honeypot: a single concentration of millions of complete identity records, valuable enough that a KYC breach becomes a matter of when, not if. The economics favour the attacker, because one success unlocks everything.
Notice what the attackers in this tracker did not do. None of them broke AES-256. They found one stale credential (AU10TIX), one unprotected store (attributed to IDmerit by Cybernews), one malicious support ticket (Sumsub), one socially engineered support agent (the 5CA flow), or one public bucket of source code (Persona). Every incumbent that centralises personal data, Sumsub, Onfido, Veriff, Jumio, Trulioo and Persona among them, shares the same single point of catastrophic failure. The honest counter-argument is that a well-run central store with encryption at rest and tight access controls can pass audits for years, and many do. That is true, and it is also beside the point: encryption did not stop a bribed insider at Coinbase, and it did not help when the data was simply left exposed. Controls reduce the odds on any given day; they do not remove the standing target.
What are the five recurring root causes of a KYC breach?
The same failure classes recur across every verified incident, so a KYC breach is rarely a novel attack. The table below is our original "anatomy of a KYC breach" pattern library, mapping each KYC breach to its root cause and to why the cause is intrinsic to centralising personal data, not something more security alone can fix.
| # | Root cause | Verified example | Why centralising personal data makes it intrinsic |
|---|---|---|---|
| 1 | Misconfigured or unsecured database or bucket | IDmerit: unprotected MongoDB, around 1 billion records (attributed by Cybernews, disputed by IDmerit) | One concentrated store means one misconfiguration exposes everyone at once, not a fraction. |
| 2 | Exposed source code on a public server | Persona: 53MB and roughly 2,456 files on a public FedRAMP Google Cloud server | A complex central platform has a large surface; one leaked artefact reveals the whole verification logic. |
| 3 | Third-party or support-tool attack surface | Sumsub (malicious support ticket attachment) and the 5CA support agent behind Discord | Aggregated data is reachable through every connected tool and subprocessor, not just the front door. |
| 4 | Long-lived stale credentials | AU10TIX: admin credentials live around 18 months, from December 2022 to June 2024 | One valid key to a central store grants access to everything it holds, so a stale credential is catastrophic. |
| 5 | Long dwell time or late detection | Sumsub: roughly 18 months undetected | A single high-value store is worth quietly sitting inside; the prize justifies a long, patient intrusion. |
Read down the right-hand column and the thesis writes itself. Each KYC breach is amplified, not caused, by the decision to concentrate personal data in one place. You can harden any single row with more security. You cannot patch your way out of being a honeypot, which is why the next KYC breach will almost certainly fit one of these five rows.
Was my data exposed in a KYC breach, and what should I do?
Start by knowing you rarely deal with an identity verification vendor directly, which is what makes a KYC breach hard to trace back to yourself. These providers sit behind the apps, exchanges, banks and games you actually use, so if you onboarded to a crypto exchange, a neobank, a marketplace or a Discord-style service in the affected window, your data may have passed through one of them and into a KYC breach you never heard about. Check the provider's official advisory and a reputable breach-notification service, and read the notice from the company you actually signed up with, since that is who must notify you.
Then take practical steps. Monitor for identity theft, consider a credit freeze, and watch for synthetic-fraud and Suspicious Activity Report risk if identity numbers leaked. Where the law gives you the right, demand deletion under the General Data Protection Regulation (GDPR) Article 17 right to erasure or under the California Consumer Privacy Act (CCPA). One hard truth sets a KYC breach apart from an ordinary password leak: biometric and document exposure is permanent. You can reset a password, but you cannot reset your face, your fingerprint or your passport number, which is exactly why these incidents are uniquely severe.
How can companies protect against KYC provider breaches?
If you are the regulated firm choosing a vendor, you inherit the vendor's KYC breach risk, so make storage a procurement question, not an afterthought. Run focused due diligence before you sign or renew. Use our short readiness checklist as a starting point; it is general guidance, not legal advice.
- Ask exactly where personal data is stored, in which regions, and for how long it is retained.
- Ask whether raw personal data is centralised in one store, or sharded and distributed.
- Request the vendor's breach and dwell-time history, including how incidents were detected.
- Get the full subprocessor and support-tool list, since that is where several breaches started.
- Confirm data-minimisation and deletion guarantees, mapped to GDPR and CCPA duties.
- Ask whether verification can happen without the vendor retaining your customers' raw personal data.
- Confirm you can still produce a complete, audit-ready record for an examiner on demand.
We answer the same questions about ourselves on our security page, and our GDPR page sets out where we act as processor for your verification data and how erasure works.
The last two items are where the model diverges. Most due-diligence checklists assume a central store and only ask how well it is locked. The more durable question is whether raw personal data has to be retained centrally at all. Privacy-preserving designs, including decentralised encrypted storage and zero-knowledge style proofs, can meet recordkeeping and audit requirements without a central honeypot. Our how it works page and our explainer on why your KYC vendor is your biggest data breach risk walk through what to look for.
Can you verify identity without a central honeypot?
This is the structural fix, and it is the reason a KYC breach is not inevitable. The line that captures it is simple: you cannot breach a database that does not exist. If verification never deposits raw identity data into one central store, there is no honeypot to misconfigure, no single credential that unlocks everything, and no concentrated prize worth an 18-month intrusion, so the conditions for a KYC breach never assemble in the first place.
Zyphe is built that way, and these are its positioning claims rather than independent findings. Personal data is sharded across a decentralised network of thousands of nodes, so no single node holds a complete record, and reconstruction requires a 29-of-100 threshold scheme. The key is customer-held, with no master key and no central honeypot. Identity is captured by reading an NFC chip to ICAO 9303 and eIDAS standards with two-step liveness and no image upload, and a reusable KYC passport lets a person verify once and re-present elsewhere. Data residency is per region and the trail is exportable and audit-ready, so an examiner still gets a complete record on demand. Zyphe positions this as breach-impossible by construction and materially lower compliance cost, a fraction of the cost of a conventional stack; treat those as the company's claims, not third-party-verified fact. If that model fits the build decision these breaches force, you can see how it works.
Methodology: what this KYC breach tracker includes
Inclusion criteria. An incident is logged when personal data collected for identity verification or KYC was exposed, exfiltrated or accessible without authorisation, and the exposure is confirmed by the vendor's own advisory, a regulator or court filing, or two independent named security publications. Breaches at regulated firms are included only where the exposed data was KYC data or the entry point was an identity verification vendor or its support chain.
Sources. Vendor security advisories and filings first, then regulator and court records, then named security press (Cybernews, Malwarebytes Labs, TEISS, NBC News, Fortune, TechCrunch, Reuters). Every incident links its source in the cited sources list. Three rest on the company's own disclosure: Sumsub's advisory, Discord's announcement and Coinbase's filing with the SEC. The others rest on the researchers who found the exposure or on press reports. Where a vendor disputes an attribution, the dispute is recorded next to the claim.
What is not counted. Phishing campaigns that impersonate a vendor without a breach of its systems, vulnerabilities disclosed and patched without evidence of exposure, and incidents where the only exposed data was operational (logs, configuration) with no personal data.
Update cadence and versioning. Incidents are added by hand when they meet the criteria above, with no fixed schedule, and the by the numbers block carries the date of the last review. The question headings on this page are stable anchors. The four incidents that are also records in the AML enforcement tracker each have a permanent record URL there, for example the Sumsub record, and the tracker's change history lists every change to those records. Corrections are logged on the corrections page.
How to cite. Zyphe (2026). KYC and identity verification breach tracker. Retrieved from https://www.zyphe.com/resources/blog/kyc-idv-breach-tracker. Quote the figure, the as-of date and the incident's primary source.
The bottom line
Read the incidents in this tracker side by side and the lesson is not that five vendors had five unlucky weeks. It is that a billion records in one MongoDB, an 18-month dwell time, code on a public server and credentials left live for a year are the predictable output of one design choice: aggregating raw personal data into a central store. You cannot patch your way out of being a honeypot. The durable fix is structural, which is to verify identity without ever centralising the raw data, so a single misconfiguration can never expose everyone at once. We will keep this page updated as new incidents are confirmed.
Related resources
- Why your KYC vendor is your biggest data breach risk
- Coinbase data breach 2025: why KYC data is the honeypot
- Identity verification software comparison 2026
- Decentralised KYC: what it is and how it works
- How Zyphe verifies without a central PII store
- Privacy-first KYC software
Cited sources
- Sumsub, Security Incident Update (official advisory)
- Discord, update on a security incident involving a third-party customer service provider (official announcement)
- Coinbase, Form 8-K of 15 May 2025 on the support-staff data theft (filing with the SEC)
- Cybernews, global data leak exposes a billion records (IDmerit MongoDB discovery)
- Fortune, Discord and Peter Thiel backed Persona identity verification breach
- NBC News, 70,000 government ID photos exposed in Discord user hack (5CA)
- Malwarebytes Labs, driving licences and official documents leaked by AU10TIX
- TEISS, data security incident at Veriff impacted Total Wireless customers
Michelangelo Frigo (Co-Founder at Zyphe) Michelangelo Frigo is a privacy and identity infrastructure expert and co-founder of Zyphe.