TL;DR
- 01What happened
On February 4, 2026, identity-verification (KYC) vendor Sumsub disclosed that its internal support environment had been accessed without authorisation in July 2024. The way in was a malicious attachment an outside attacker sent through a third-party support-ticketing service. The exposed data was mainly names, with some email addresses and phone numbers. Clients’ notices show it included users of the crypto exchanges Ndax and Bitpanda.
- 02Why it was hard to tell
Face images, ID document images and bank details were protected along with the core verification systems. Even so, users’ names and contact details remained in the support environment.
- 03The missing layer
An internal review found the intrusion retrospectively in January 2026, but for about 18 months before that the data sat readable. What failed was the layer that checks where personal data held for identity checks lingers outside the core and who can read it, and keeps nothing that isn’t needed.
What happened
- Who
- Sumsub, a London-based identity-verification and anti-fraud vendor that verifies users on behalf of clients such as crypto exchanges.
- Way in
- In July 2024 an outside attacker sent a malicious attachment through a third-party support-ticketing service (not named) and gained limited access to a support-related internal environment.
- Exposed
- Mainly names; some records also included email addresses or phone numbers. The number of people has not been disclosed (the company says “a limited number of customer accounts”).
- Whose data
- Sumsub does not say, but its clients Ndax and Bitpanda told their own users that names, email addresses and phone numbers may have been accessed.
- Not exposed
- Biometric data, ID document images, bank and payment details, and government ID information. Live verification workflows, client-facing APIs and core production systems were not affected (per the company).
- Discovery
- Found retrospectively in an internal security review in January 2026. The company says it has seen no signs of unauthorised activity after July 2024 and is still assessing why discovery took so long.
- Response
- Brought in independent forensic experts and told affected clients directly through their account managers. Revised support staff’s access controls and strengthened monitoring and detection.
Glossary
Identity-verification (KYC) vendor — A company that checks users' ID documents and faces on behalf of banks and crypto exchanges. It holds a lot of users' personal data.
Support ticket — The record of a single enquiry. Along with the conversation and attachments, it often holds the user's name and contact details.
The point to stop it was ③. Had personal data not needed for support been kept out, and who could read what been checked, little would have been readable after the break-in.
Through the third-party ticketing service.
Separate from the verification core.
2024-07.
2026-01.
Timeline — disclosure and response
- The attacker sends a malicious attachment and gets into the support-related internal environment.
- An internal security review finds it retrospectively.
- Sumsub discloses the incident, having told affected clients directly.
- French crypto outlet Cryptoast reports the notice Bitpanda sent its users.
- Ndax tells its users on X and warns them about phishing.
- Sumsub says on X that “in our 10-year history, this is the first incident of its kind”.
Facts rest on Sumsub’s disclosure and Ndax’s post (both primary) and on Cryptoast’s report of Bitpanda’s notice. The ticketing service’s name, the number of people, affected clients other than Ndax and Bitpanda, and any regulator notification have not been disclosed. As of October 2026, the disclosure has not been updated.
After disclosure
- Ndax: Said none of its systems were compromised and no passwords, ID documents or banking details were exposed, and warned users about phishing.
- Bitpanda: Told users their names, email addresses and phone numbers may have been affected (per Cryptoast).
Why it wasn’t stopped
This case was not a failure to protect the verification core. Face and ID images were protected, but users’ names and contacts remained in the support environment, which sat readable and unnoticed for about 18 months.
The core of identity verification was protected, but users' names and contact details left in the support environment sat readable and unnoticed for about 18 months.
Proof works before data is stored and before it is read; detection works after an intrusion surfaces. In between, data left outside the core stays readable.
names and contacts were readable
Detection worked: Sumsub found the intrusion in its own review and told its clients. But it found it about 18 months later, and although “the core is protected” and “held data exists only where it is needed” are separate facts, only the first had been checked. That distance is the detection–proof gap, and it is a structural one.
The same structure appears in Awa Bank (customer data that should have been deleted left in a test environment past its purpose).
How to counter this
Keep personal data held for identity checks only where it is needed, and keep checking where it remains. Environments outside the core, such as support, should hold only what they need. Organisations that outsource should also ask where their vendor keeps what, so that if it leaks they can say whose data, and which, was involved.
Industries and operations to watch
- IndustryFinance & FinTech
- Crypto exchanges, payment services and others that outsource identity checks. Leaked contact details can be used for phishing aimed at their users.
- OperationLookup & data access
- Support staff looking up user information to answer enquiries. This tends to be less protected than the core systems.
Do today’s controls close it?
| Control | This case | Why |
|---|---|---|
| Protecting the verification core | Partial | Face and ID images were protected. Names and contacts left in the support environment sat outside it. |
| Vendor certifications and audits (SOC 2, ISO) | Partial | They show the vendor’s management system, not which data remains in which environment. |
| Intrusion monitoring | Partial | An internal review found it, but about 18 months later. |
| Warning users about phishing | Partial | It reduces harm after the leak, but cannot undo it. |
- Keep personal data not needed for support out of support. Let support staff see only the fields needed to answer an enquiry, and set how long they are kept.
- Check what remains where, and who can read it. Ask vendors, too, which environments hold the data you entrust and who can read it.
- Record what was checked. Keep records of where data is and who could read it in a form that can later be shown to a third party: in other words, as proof. Then, if it leaks, you can say at once whose data, and which.
Three things to confirm in an organisation that outsources identity checks
- Do you limit the user information you pass to the vendor to what the identity check needs?
- Is there an agreement that, after a leak, the vendor promptly tells you whose data, and which, was involved?
- If users’ contact details leak, is there a procedure to warn them about phishing?
Note: keeping data only where it is needed still leaks if that place is breached. And the less data is kept, the harder it can be for support staff to answer enquiries.
Sources
- Primary, company disclosureSumsub “Security Incident Update”
- Primary, client notice on XNdax Notice to users about the Sumsub incident
- Primary, post on XSumsub Reply calling it “the first incident of its kind” in its 10-year history
2 more (reporting, analysis)
- Reporting, quotes Bitpanda’s noticeCryptoast “Bitget, Bybit, MoonPay, Bitpanda : des données personnelles de clients pourraient avoir fuité à cause de ce fournisseur de KYC”
- ReportingUnivers Freebox “Fuite de données : un des principaux tiers de confiance pour vérifier l’identité touché… il s’en rend compte avec un an et demi de retard”
References: “The last layer left for cyber defense in the age of AI”