CASE FILE #03: Odido: 6.39 million digital identities

Why Personal Data Needs Protection at the Data Level

Name, date of birth, telephone number, bank details, and identification documents: When such information is combined, it creates a detailed digital identity profile.

In 2026, approximately 6.39 million people were affected by a cyberattack on Dutch telecommunications provider Odido.

The case shows that many personal attributes cannot simply be replaced after a data breach.

1. What Happened?

Over the weekend of February 7–8, 2026, Odido detected suspicious activity in a system used for customer communications.

Unauthorized parties had gained access to personal customer data. Odido stopped the unauthorized access and reported the incident to the Dutch Data Protection Authority.

Following further investigations, the company put the number of affected individuals at approximately 6.39 million.

2. How Did It Happen?

Unauthorized access to a system used for customer communications was publicly confirmed.

However, the information initially published did not contain a conclusively confirmed technical description of the original attack path.

The same principle applies here: The data exfiltration itself does not provide a reliable basis for identifying a specific vulnerability.

3. What Data Was Affected?

The potentially affected information included names, addresses, telephone numbers, email addresses, and customer numbers.

Depending on the individual, this also included dates of birth, bank details or IBANs, as well as information from passports or driving licenses.

Not every affected individual was affected by every category of data.

4. What Consequences and Risks Arise?

The combination of different personal attributes is particularly problematic.

A name, date of birth, address, telephone number, and banking information can together create a detailed identity profile.

Such data can be used for personalized phishing, social engineering, identity theft, or other attempts at fraud. Many of these attributes also cannot simply be changed.

5. Which Traditional Security Measures Are Necessary?

Large customer databases require strong authentication, least privilege, vulnerability management, monitoring, and incident response.

Data minimization is also essential.

Organizations should regularly assess which personal information is actually required, how long it needs to be stored, and which users or systems need access to it.

6. Why Are These Measures Alone Not Enough?

Even a legitimate account, application, or database can be compromised.

The crucial question is therefore: Does every user or process with system access automatically need to be able to access all personal data in plaintext?

Particularly for identity attributes that remain valid over the long term, the answer should be differentiated.

7. How Does Data-Centric Security Help?

Data-Centric Security protects particularly sensitive personal information directly at the data level.

Depending on the use case, data can be encrypted, tokenized, pseudonymized, or masked.

This can separate access to an application from access to specific original information.

8. How Could eperi sEcure Have Protected the Data?

eperi sEcure can encrypt or tokenize defined sensitive data fields in supported applications and data flows.

These can include names, email addresses, IBANs, or identification attributes, for example.

The cryptographic keys can remain separate from the target application and under the control of the organization.

9. What Is the Key Lesson from the Incident?

Personal information remains sensitive regardless of whether it is stored within an ostensibly protected application.

The more permanent an identity attribute is, the more important it is not to make its protection depend exclusively on a user account or application.

The lesson from CASE FILE #03: Possession of a database or a compromised account should not automatically mean possession of the digital identities contained within it.

The eperi Lesson: Assume Breach. Protect the Data.