When Your KYC Provider Gets Breached: Lessons From the Sumsub Security Incident

Key highlights

• The Sumsub breach went undetected for eighteen months, from July 2024 to January 2026, exposing a fundamental failure in the monitoring and incident response that clients pay for.
• Attackers entered through a malicious attachment on a third-party support platform, proving centralised KYC providers are only as secure as their weakest integration point.
• Sumsub says the exposure was limited to names, with a smaller subset of emails or phone numbers, and that biometric data, document images, and government IDs were not accessed.
• This was Sumsub's second incident in twelve months, following a March 2025 event involving an integrator that left API tokens publicly available.
• Under GDPR and financial services rules, the institution that collected the data stays liable. A vendor breach does not absolve you, it compounds your risk.
• A decentralised architecture removes the honeypot entirely: data is encrypted, sharded, and user-controlled, so there is no central database of identity documents to breach.

The Sumsub security incident was a breach of a support-related internal environment that went undetected for eighteen months, from July 2024 until a January 2026 audit found it. The attacker gained access through a malicious attachment submitted on a third-party support platform. Sumsub states the exposure was confined to names, with a smaller subset of email addresses or phone numbers, and that live verification workflows and core production systems were not affected.

When Your KYC Provider Gets Breached: Lessons From the Sumsub Security Incident

In January 2026, Sumsub, a leading identity verification provider, revealed a security incident that had gone undetected for eighteen months and compromised its internal systems.

The attack began in July 2024 when a malicious attachment, submitted through a third-party support platform, gave an attacker access to a support-related environment. The issue surfaced only during a security audit in January 2026.

Let that timeline sink in. Eighteen months of undetected access.

What was actually exposed in the breach?

Sumsub has stated that the breach was confined to a support-related internal environment and did not affect its live identity verification workflows, customer-facing APIs, or core production systems. The data exposed primarily consisted of names, with a smaller subset including email addresses or phone numbers, either alone or in combination with names.

Biometric data, identity document images, bank account details, and government-issued identification were reportedly not accessed.

That's the official account. And while it's encouraging that the highest-sensitivity data appears to have been protected, the incident raises structural questions that every compliance leader and risk officer should be asking, not just about Sumsub, but about the entire centralised KYC model.

Why does centralisation create honeypots?

This isn't just a Sumsub problem. It's an architecture problem.

When you think of an organisation that manages, stores, and processes identity information for thousands of organisations and millions of people, you realise that such an organisation would be of extremely high value to a potential attacker. Think of all the identity documents, selfies, and proof of address that are stored in one single location. The cost-benefit analysis of attacking such a system would be attractive to any well-funded potential attacker, as they would get access to millions of people by attacking just one system.

This is what security professionals call the "honeypot effect." The more personally identifiable information (PII) concentrated in a single environment, the more attractive and rewarding it becomes for attackers.

We unpack why this concentration is so dangerous in why centralized PII storage is your biggest liability.

And it's not just the primary verification infrastructure. As the Sumsub breach illustrates, the third-party applications it integrates with, such as support ticketing software or customer service tools, offer further avenues of entry that are not always subject to the same security rigour.

We cover this exposure in detail in third-party breach risk for fintechs.

How did the breach stay hidden for eighteen months?

Perhaps the most concerning detail isn't what was exposed; it's how long the exposure lasted.

The intrusion persisted from July 2024 to January 2026 without detection. In the identity verification industry, where providers are entrusted with the most sensitive personal data imaginable, an eighteen-month detection gap represents a fundamental failure of the monitoring and incident response capabilities that clients are paying for and relying upon.

For the organisations that depend on these providers for compliance, this creates a cascading risk problem. If your KYC vendor is compromised and doesn't know it, you don't know it either, but you're still responsible for the data you've entrusted to them and for the regulatory obligations tied to that data.

Was this Sumsub's only recent incident?

It's worth noting that Sumsub also disclosed a separate security incident in March 2025 involving Merkur AG, where a third-party integrator's negligence caused API tokens to become publicly available. While Sumsub attributed that incident to the integrator rather than its own systems, the pattern is instructive: centralised platforms are only as secure as their weakest integration point.

Two incidents in twelve months should prompt any compliance team to reconsider the concentration risk inherent in their KYC infrastructure.

This is the core argument in why your KYC vendor is your biggest data breach risk.

What should your organisation ask right now?

If your institution relies on a centralised KYC provider, whether Sumsub or any other, this incident should prompt three immediate questions:

1. Where does your users' identity data actually live?

In a centralised model, it lives on someone else's servers, alongside the data of every other client. You have limited visibility into how it's stored, who has access, and what other systems are connected to that environment. Your compliance posture is, in practice, outsourced.

2. How would you know if your provider was breached?

In the Sumsub case, the answer was: you wouldn't, not for eighteen months. Most centralised providers offer audit logs and compliance certifications, but these are backward-looking controls. They tell you what happened after the fact, not what's happening now.

3. What's your exposure if a breach does occur?

Under GDPR, the organisation that collected the data, not just the processor, bears responsibility. Under financial services regulations, the institution that onboarded the customer is liable for the consequences of a compromised identity. A vendor breach doesn't absolve you; it compounds your risk.

For the controller versus processor split, see what the GDPR transparency sweep means for KYC.

How does a decentralised architecture remove the target?

There is a fundamentally different way to approach identity verification, one that eliminates the honeypot problem by design.

In a decentralised architecture, verified identity data isn't stored in a central repository at all. Instead, it's encrypted, sharded, and distributed across decentralised storage with the user maintaining control through cryptographic keys. No single point of failure. No centralised target for attackers. No eighteen-month blind spots.

We explain the mechanics in decentralised KYC: what it is and how it works.

"The result of a verification is stored as a cryptographic credential in the user's own vault. If a partner organisation needs to verify a user's identity, they receive a mathematically verifiable proof of that fact, not a copy of the underlying data. The data remains under the user's control at all times, and a verifying organisation never becomes a 'keeper' of that data."

This isn't theoretical. At Zyphe, this is how our platform works, and it's why incidents like the Sumsub breach don't apply to our architecture. There is no central database of identity documents to breach, because no such database exists. The data is decentralised by design, encrypted at rest and in transit, and accessible only through cryptographic access grants that can be revoked at any time.

See a direct breakdown in Zyphe vs Sumsub.

When does the decentralised model not solve the problem on its own?

Decentralisation removes the central honeypot, but it does not erase every avenue of entry. The Sumsub breach started in a third-party support platform, not the core verification system, and that lesson holds for any architecture. If your team connects weakly secured support tools, integrators, or customer service software to a verification stack, you reintroduce risk at the integration point regardless of how the underlying data is stored.

The model also does not change who carries the regulatory weight. Under GDPR, the organisation that collected the data stays responsible, and under financial services rules the institution that onboarded the customer remains liable. Moving data off a central server reduces the blast radius, but you still own your monitoring, your incident response, and your obligations to the people whose identities you handle.

Why does this matter for your compliance posture?

The Sumsub incident is a useful case study, but the lesson extends far beyond one provider. The centralised model of identity verification, where a single vendor becomes the custodian of millions of identities, carries inherent risks that no amount of perimeter security can fully mitigate.

The same architecture lesson runs through why centralized identity verification is a ticking time bomb.

As regulations tighten globally (the UK's PSR liability framework, the EU's PSD3, and the US's evolving interpretation of Regulation E), financial institutions are being held to a higher standard on data protection. The question isn't whether your KYC vendor will be targeted; it's whether your architecture can withstand the attack when it comes.

Decentralised identity verification doesn't just reduce the blast radius of a breach. It removes the target entirely.

You can run the numbers yourself in is KYC safe in 2026.