The Odido breach started with phishing emails to customer service staff and ended with over seven million records scraped from Salesforce. Attackers harvested passwords, then called employees posing as IT and talked them into approving the second factor. That opened a system whose scale raised serious questions about how access had been scoped.
Like most serious breaches, this wasn't one thing going wrong. It was a chain of failures: authentication that could be bypassed with a phone call, access that may have been too broadly scoped for the role and scraping that ran for roughly 48 hours before it was stopped. This article focuses on the user authentication process, but the Odido case is a reminder that security architecture is only as strong as its weakest link.
It started with phishing. Attackers sent emails to customer service staff that looked like internal communications. Those emails harvested employee credentials, giving the attackers valid passwords for the next step.
Then came the phone calls. Attackers rang employees, posing as Odido's IT department. Routine-sounding request, manufactured urgency and a simple ask: approve this login or share the verification code.
With valid credentials and an approved second factor, the attackers accessed Odido's Salesforce CRM. From there, they were able to scrape data on over 7 million records; 6.5 million individuals and roughly 600,000 businesses. A volume that raises questions about how broadly access was scoped and how long the scraping went undetected. The stolen dataset, including names, addresses, IBAN numbers and identity document numbers, was published by the ShinyHunters group in escalating batches after Odido refused to pay ransom.
A common response is another awareness campaign. Remind people never to share codes, never to approve unexpected login prompts, don't click suspicious links. Send a test phishing mail once a quarter and track who falls for it. That's sensible, and it helps.
This isn't about blaming individual employees. The deeper problem is a model that places the burden of a security decision on people, then puts them in situations designed to exploit trust and routine. Attackers need one person to slip once.
Whether it's an SMS code, an authenticator app or a push notification, the underlying issue is the same: anything that can be typed, read aloud or tapped under pressure can be handed to an attacker. The factor itself is transferable, and that's what makes it exploitable.
The question worth asking: does your authentication still depend on something a human can hand over?
Phishing-resistant MFA removes the transferable element entirely. No code to read aloud, no push notification to approve under social pressure. Authentication happens between the device and the identity provider through a cryptographic exchange that can't be intercepted, relayed or dictated over a phone.
Solutions like Okta FastPass use public-key cryptography with origin verification. The authenticator checks the domain of the request and won't respond to proxy sites or look-alike pages. In a scenario like Odido's, a phishing page wouldn't trigger a valid authentication regardless of how convincing it looked.
That covers the front door. Device trust covers the device itself: access can be restricted to managed hardware with cryptographic attestation via the TPM or T2 chip. Credentials can't be exported or replayed from an unmanaged machine.
Then there's what happens after login. Session hijacking, where an attacker steals a valid session token and replays it, is a growing category of attack. In most organisations, a single session token can open the door to email, file storage, communication tools and business-critical SaaS platforms, so a stolen token is worth more than a stolen password. Continuous session monitoring (Okta calls theirs Identity Threat Protection) watches for context shifts after authentication. If a token suddenly appears on an unmanaged device, the system can revoke access across integrated applications before lateral movement starts.
These layers reinforce each other across the full attack chain. Social engineering fails because there's nothing transferable to ask for. A stolen credential is useless without the right hardware. A hijacked session gets caught and shut down.
If the Odido breach has you reviewing your own setup, here's where to start.
Check what type of second factor your organisation actually relies on.
If it's SMS codes, authenticator app OTPs or push notifications that users can approve without context, you have the same architectural exposure that made this attack possible. The factor itself is the vulnerability.
Then look at device policy.
Are your critical applications accessible from any device, or only from managed hardware with attestation? If someone could log in from a personal laptop, device trust isn't enforced.
Finally, check what happens after authentication.
If a session token is valid until it expires, with no continuous context checks, a stolen token gives an attacker a long, unmonitored window.
None of these are quick fixes, but they're the right questions. Most organisations at this scale know their authentication could be stronger. The challenge is usually not knowledge but prioritisation, and that changes the moment a breach turns an accepted risk into a front-page incident. These questions are the difference between hoping your people don't get tricked and building an environment where getting tricked doesn't matter.