Odido, the largest mobile operator in the Netherlands, suffered one of the biggest personal-data exposures in Dutch history: 6.2 million customers, roughly a third of the country, had personal information taken in a cyberattack. The intrusion was detected over the weekend of February 7-8, 2026, and disclosed shortly after, but the story did not end there. In May 2026 the consequences crystallized, the company publicly ruled out compensating affected customers, and mass-claim and GDPR-driven legal actions began to organize. We are covering it now because the May developments turned a February breach into a live case study on liability, regulatory exposure, and the same Salesforce social-engineering technique that defined the rest of the 2026 breach quarter.
The data lost is severe for a consumer telecom: names, home and email addresses, phone numbers, dates of birth, bank account numbers (IBANs), and government ID document details. The breach reached customers of both the Odido brand and its Ben subsidiary; the Simpel subsidiary was unaffected. Odido stated that passwords, call records, billing data, location data, and ID document scans were not accessed. The notorious ShinyHunters group has been associated with the attack, and reporting describes an extortion attempt with a roughly €1 million demand and a subsequent leak of the dataset after the deadline passed.
For security and compliance leaders, Odido is the European mirror of the Carnival and ADT incidents: same technique, different jurisdiction, and a regulatory regime, GDPR, with sharper teeth. This post covers the verified facts, the vishing-into-Salesforce attack pattern, and what defenders running large CRM-backed customer operations should take from it.
TL;DR
- What happened: Odido (Netherlands' largest mobile operator) exposed personal data of 6.2 million customers, including Ben-brand customers; Simpel was unaffected.
- Detected: Weekend of February 7-8, 2026; reported promptly to the Dutch Data Protection Authority; widely disclosed in February with major developments in May 2026.
- Data exposed: Names, home and email addresses, phone numbers, dates of birth, bank account numbers (IBANs), and ID document details.
- Not exposed (per Odido): Passwords, call records, billing data, location data, and ID document scans.
- Attack pattern: Reporting attributes the breach to ShinyHunters using social engineering and MFA-bypass vishing to reach a customer-contact/Salesforce system. Treat attribution as reported, not company-confirmed.
- May 2026 development: Odido publicly ruled out compensation; GDPR mass-claim actions began organizing. An ~€1M extortion demand and post-deadline leak were reported.
- Key action: Harden helpdesk against MFA-fatigue and vishing, cap bulk export from CRM, and prepare for GDPR liability when financial identifiers like IBANs are exposed.
What happened
The verified facts, drawn from Odido's statements, Dutch reporting, and contemporaneous coverage:
- February 7-8, 2026: Odido detected the cyberattack over the weekend and launched an investigation with internal and external experts.
- Scope: 6.2 million customers across the Odido and Ben brands; Simpel unaffected.
- Data exposed: Names, home and email addresses, phone numbers, dates of birth, bank account numbers (IBANs), and ID document details, with exact fields varying per customer.
- Not accessed (per Odido): Passwords, call records, billing data, location data, and ID document scans.
- Reporting: Odido promptly notified the Dutch Data Protection Authority and began informing affected individuals by email and SMS.
- May 2026: Odido publicly ruled out paying compensation to affected customers, prompting organized mass-claim activity under GDPR.
CEO Søren Abildgaard's statement at disclosure: "Odido has been affected by a cyberattack, in which customer data has been impacted," adding that "our operational services have not been affected; customers can continue to call, use the internet, and watch TV safely."
Separating reported from confirmed:
- Confirmed by Odido: The breach, the affected brands, the data fields, the fields not accessed, and the regulator notification.
- Reported but not company-confirmed: Attribution to ShinyHunters, the specific vishing/Salesforce vector, the ~€1 million extortion demand, and the subsequent leak of the dataset to the dark web after the demand deadline.
The IBAN exposure is the financially dangerous element. Combined with name, address, and date of birth, a bank account number enables convincing direct-debit fraud and targeted social engineering against the customer's bank.
How the attack worked
The reported entry method matches the dominant 2026 enterprise-breach pattern almost exactly: social engineering of customer-service staff to obtain credentials, then a vishing call to defeat multi-factor authentication, then access to a CRM customer-contact system and bulk export.
# Reported attack pattern (per security reporting, not Odido-confirmed).
# Illustrative reconstruction, not a forensic timeline.
1. Phishing -> targeted emails to customer-service employees
capture login credentials
2. MFA bypass -> attacker calls the employee posing as internal IT,
(vishing) manipulating them into approving a second-factor
login request
3. Session ride -> valid, MFA-satisfied session into the CRM /
customer-contact platform
4. Bulk export -> copy 6.2M customer records (PII + IBANs + ID details)
5. Extortion -> ~€1M demand; dataset reportedly leaked after deadline
Step 2 is the part defenders most often get wrong. MFA was likely present, and it did not help, because the second factor was a push approval the employee was talked into accepting. MFA-fatigue and live vishing defeat prompt-based MFA precisely because the human is the approving authority and the human is the target. Phishing-resistant factors (FIDO2/WebAuthn hardware keys bound to the origin) are far harder to socially engineer, because there is no "approve" button to talk someone through.
Step 4 is the same blast-radius problem seen across the quarter. A consolidated CRM holding the entire customer base allows a single compromised identity to export millions of records, because bulk export is a sanctioned feature for legitimate operations. The attacker does not bypass a control; they use an intended capability with a stolen-but-valid identity.
What detection looks like
For a telecom or any large consumer business running a CRM-backed contact operation:
- MFA-approval anomalies tied to inbound calls. Correlate a burst of push approvals with helpdesk or inbound-call activity. Approvals immediately following a phone call are a strong vishing indicator.
- Bulk export volume per identity. Alert when any agent or service identity exports record counts far above baseline. A contact-center agent does not export the full customer base.
- Export egress monitoring. Bulk API or report jobs from new ASNs, VPS ranges, or anonymizing networks.
- Credential-phishing precursors. Spikes in password resets, new-device enrollments, or session creation from unusual locations among customer-service staff.
- IBAN/ID field access patterns. Reads of bank-account and ID-document fields at volume should be high severity; these are the highest-value columns in a telecom CRM.
The decisive signal is mass read by a valid identity, not failed logins. Auth succeeded. Behavior is the tell.
What to do Monday morning
Ordered by urgency for organizations with phone-reachable support staff and a consolidated CRM:
- Move privileged and support logins to phishing-resistant MFA. Replace push/OTP with FIDO2/WebAuthn hardware keys for anyone with CRM access. This directly defeats the vishing step that powered Odido, ADT, Carnival, and 7-Eleven.
- Cap bulk export per identity. Enforce hard ceilings on records exportable per user per hour, with alerting above baseline. This is the control that bounds a six-million-record loss.
- Restrict export egress to known IP ranges. A valid session from an unexpected network should fail bulk export.
- Run a vishing tabletop with the helpdesk. Specifically rehearse the "internal IT asks you to approve a prompt" scenario and make refusal the trained default.
- Scope CRM read access. Agents need the records they are serving, not the entire base. Remove standing full-table read; require step-up auth for large queries.
- Treat IBAN exposure as a fraud event. Warn affected customers about direct-debit and bank-impersonation fraud; coordinate with banks where possible.
- Get your GDPR posture in order. Document detection, notification, and DPA-reporting timelines now. Where IBANs and ID details are exposed, expect mass-claim and regulator scrutiny, exactly what materialized for Odido in May.
Why this keeps happening
The technique works because it sidesteps everything most security programs invest in. There is no CVE to patch, no malware signature to detect, no perimeter to breach. A phished employee with a valid login and a manipulated MFA approval is indistinguishable from a legitimate user until the export volume gives them away. Organizations that bought MFA assumed they had solved credential theft; prompt-based MFA solved password reuse, not social engineering.
Consumer telecoms are concentrated targets for the same reasons as cruise lines and security companies: large, distributed, phone-reachable support workforces (a wide social-engineering surface) sitting on top of CRMs that hold rich identity and financial data for the entire customer base. The CRM is designed for fast, broad access by humans, so the blast radius of one compromised agent is the whole book of business.
The European angle adds a liability dimension absent from many U.S. cases. Under GDPR, exposure of financial identifiers and ID details for a third of a country's population is a serious incident with real regulatory and civil exposure. Odido's May 2026 decision to rule out compensation collided directly with an organized mass-claim response. The lesson for European operators is that the post-breach legal and regulatory cost can dwarf the incident-response cost, and that posture must be planned before, not after, the breach.
The structural fix
The honest framing: you cannot prevent every employee from being socially engineered, so the goals are to make the stolen credential useless (phishing-resistant MFA), to bound what a single identity can exfiltrate (export caps and scoping), and to detect mass read fast. Those three controls would have meaningfully shrunk Odido's blast radius even granting the initial human compromise.
Safeguard's SaaS-to-SaaS and identity posture mapping enumerates which identities and connected applications can bulk-read your consolidated customer stores, flags standing full-table read grants and export paths that are not IP-restricted, and highlights identities still relying on phishing-vulnerable MFA. Cross-referencing those findings against active campaign intelligence means that when a group like ShinyHunters is implicated in a live wave, the identities and integrations most exposed to that exact technique are ranked first, with a revoke-and-rescope workflow. For European operators, policy-as-code can require that any integration touching financial identifiers or ID data be scoped, IP-bound, and tied to phishing-resistant authentication before it is approved, which also strengthens the GDPR accountability story. None of this prevents a determined vishing attempt; it shortens dwell time and shrinks the export an attacker can complete before detection.
What we know we don't know
- Confirmed attribution and vector. Odido confirmed the breach and data fields but has not publicly confirmed ShinyHunters or the specific vishing/Salesforce path; those rest on security reporting.
- The extortion and leak. The reported ~€1 million demand and post-deadline dataset leak are from reporting, not Odido's statements.
- Per-customer field variance. Exact fields exposed vary per customer; the full distribution is not public.
- Regulatory outcome. The Dutch DPA's findings and any penalties were not concluded as of the May 2026 developments.
- Compensation endgame. Odido ruled out compensation; how the mass claims resolve is unsettled.
References
- The Register: Dutch telco Odido admits 6.2M customers affected in breach
- BleepingComputer: Odido data breach exposes personal info of 6.2 million customers
- The Record: Dutch telecom giant Odido announces data breach
- NL Times: Odido rules out compensation after massive cyberattack affecting 6.2 million accounts
- eSecurity Planet: Odido CRM Data Breach Exposes 6.2M Customer Records
Internal Safeguard resources: