The Odido breach: how one phone call to customer service exposed 6 million people

On the weekend of 7-8 February 2026, criminals gained access to the customer systems of Dutch telecom provider Odido. Not through a sophisticated technical exploit, but through people: first a phishing email to steal customer-service agents' passwords, then a phone call in which the attacker posed as the internal IT department to bypass the extra login step. The result: data on roughly 6.2 million (former) customers of Odido and its Ben brand — almost the entire customer base.

What actually happened

Odido disclosed the breach on 12 February 2026; the attack itself took place the weekend before. Two weeks later, on 26 February, the criminals published part of the haul on the dark web: data on around 430,000 individuals and 290,000 business customers.

The stolen dataset was unusually sensitive. It included not only names, addresses, phone numbers, email addresses and customer numbers, but also IBAN account numbers, dates of birth and identification data. Some internal notes even contained references to stalking, domestic violence and protected addresses — information that can be life-threatening in the wrong hands.

Access ran through the Salesforce environment used by customer service. Not a server intrusion, but the abuse of a valid account that an employee had handed over. Under the GDPR a breach like this must be reported to the supervisory authority within 72 hours.

Why customer service was the target

Attackers take the path of least resistance. Customer service — often partly outsourced to external call centres — has daily access to large volumes of customer data, yet usually receives less security attention than IT administrators or developers.

On top of that, helping is the job of a service agent. Someone trained all day to be friendly and solution-oriented will naturally cooperate when 'a colleague from IT' calls with an urgent request. That helpfulness is not an individual weakness; it is a trait attackers deliberately exploit.

For awareness professionals this is the core lesson: the people holding the most customer data are not always the people getting the most training. That gap needs to be closed deliberately.

MFA is not the finish line: how the extra step was bypassed

Many organisations assume multi-factor authentication (MFA) protects them against stolen passwords. It does — until a human approves the MFA step themselves. At Odido the attacker called the agent after the phishing email, posed as the IT help desk and asked them to confirm the login attempt. The agent approved the prompt and handed over the second factor.

This is known as MFA fatigue, or bypassing MFA through social engineering. The technology works fine; the human process around it is the weak point. An attacker only needs one employee who taps 'approve' at the wrong moment.

MFA remains an essential baseline measure, but only if you set it up well. Want to know which forms of MFA resist this kind of attack and how to roll them out? Read how to implement MFA in your organisation.

The rule every employee should know: real IT never asks for your password, your MFA code, or for you to approve a login attempt you did not start yourself. Got such a request? Hang up and call back on a known, internal number.

The real damage comes later: follow-up phishing with real data

A breach is not an end point but a starting point. With real customer data, criminals can send messages that check out: they know your name, your customer number, your provider and sometimes your IBAN. A phishing email or text that opens with correct details is far more convincing than the classic 'Dear customer'.

Sure enough, the Odido breach was followed by a wave of follow-up phishing: fake messages 'from Odido' about a failed payment or an outstanding invoice, linking to a cloned login page. That is the real business model behind the theft.

It means a breach at one organisation raises the risk for every organisation. Your employees and customers can be targeted more precisely, even if your own systems were never touched.

How to embed this in your awareness programme

The Odido incident is an ideal, relatable case to use in your programme — precisely because there was no 'genius hack', just a phone call and an email.

Do not focus only on office staff. The biggest gains are with the teams that handle a lot of customer data and a lot of inbound contact: customer service, help desk, reception and external call centres.

Audience + cadence: give customer service and the help desk a dedicated module with a callback procedure, and repeat it every quarter — turnover in these teams is high.
Set one rule everyone knows: 'IT never asks for your password or MFA approval; when in doubt, hang up and call back on the internal number.'
Practise the scenario live: a vishing simulation (fake IT calls) teaches more than an e-learning module alone.
Measure reporting, not just clicking: how many staff report the suspicious call within 30 minutes?
Want to go deeper? See how to tackle this structurally through security awareness training.

FAQ

Was the Odido breach a technical hack?

No. The attackers used no software vulnerability but social engineering: a phishing email to steal passwords, followed by a phone call in which they posed as internal IT to get the MFA step approved. It was a human attack, not a technical one.

How can MFA be bypassed if it is enabled?

MFA protects against a stolen password, but not against an employee who approves the login attempt themselves. By calling and posing as IT, the attacker got the agent to confirm the second factor. The technology worked; the human process was the weak point.

What should employees do about a suspicious 'IT phone call'?

Hang up and call back on a known, internal number. Real IT never asks for your password, your MFA code, or for you to approve a login attempt you did not start yourself.

Why is a breach at another company also my problem?

Because with real data criminals can send far more convincing follow-up phishing. Your employees and customers can be targeted with messages containing accurate names, customer numbers or account details, even if your own systems were never breached.