MFA Gaps: Why So Many Breaches Still Start With a Password

Short read

This post covers why so many breaches still start with a password. Seven of the fifteen major breaches we reviewed, including Colonial Pipeline, Change Healthcare and the Snowflake customer breaches, began with an attacker signing in with real credentials and no second factor in the way.

You'll learn why having an MFA policy isn't the same as having MFA coverage, where the gaps usually hide, and six practical steps to find and close them. We also explain how urgentic amber and urgentic BLUE help keep that list current and watch for the logins that get through anyway.

MFA gaps are still one of the most common ways into an organisation. When we went back through fifteen of the biggest breaches of the last decade, using what the victims, regulators and investigators published afterwards, seven of them began the same way: an attacker signed in with a real password, and no second factor stood in the way. Only one of the fifteen needed a zero-day. This article looks at why that keeps happening when almost every organisation already has a multi-factor authentication policy, and how to find the gaps before someone else does.

Seven of fifteen: the pattern behind the headlines

The seven are Colonial Pipeline, Uber, MGM Resorts, the British Library, Midnight Blizzard's attack on Microsoft, Change Healthcare and the Snowflake customer breaches. The classification is ours, based on the initial access point in each public account, but the detail comes from the organisations and investigators themselves. Four of them show the pattern especially clearly.

• Colonial Pipeline, 2021. In testimony to the US Senate, Colonial's chief executive explained that the attackers got in through a legacy VPN profile that was not intended to be in use, and that it relied on a password alone. Normal remote access at the company used hardware tokens. The old route simply never got the same treatment.
• Change Healthcare, 2024. UnitedHealth Group's chief executive told the Senate Finance Committee that on 12 February criminals used compromised credentials to access a Citrix remote-access portal that did not have multi-factor authentication. They moved through the network, took data, and deployed ransomware nine days later.
• Midnight Blizzard and Microsoft, 2024. Microsoft's own write-up says the attackers used a slow, carefully throttled password spray to compromise a legacy, non-production test tenant account that did not have MFA enabled, then abused an old test OAuth application to reach corporate mailboxes.
• Snowflake customers, 2024. Mandiant found that the attackers used credentials stolen by infostealer malware, some dating back to 2020, to log into customer accounts. Around 165 organisations were notified. The impacted accounts had no MFA, the passwords had not been rotated, and there were no network allow lists. Snowflake's own environment was not breached.

The British Library's own review of its 2023 ransomware attack tells a similar story: the first detected access was on a server used by partners and administrators that sat outside the scope of its MFA rollout. We covered that case in detail in our British Library breach breakdown.

The one exception was MOVEit Transfer in 2023, where a criminal group exploited a previously unknown flaw in an internet-facing file transfer product, as set out in the joint CISA and FBI advisory. That kind of attack is genuinely hard to prevent. The other pattern is not.

Why an MFA policy isn't the same as MFA coverage

Several of these organisations did use MFA for their main systems. Colonial's everyday remote access used tokens, and the British Library had MFA on its cloud applications. What they had was a gap between the policy and the estate. The attackers did not beat MFA. They found the door it had never been fitted to.

Those doors tend to fall into a few familiar groups:

• Legacy and "retired" access. Old VPN profiles, remote desktop gateways and accounts that should have been switched off but were only forgotten.
• Test and non-production environments. Test tenants, staging systems and proof-of-concept setups that were built quickly and never brought under the main identity controls.
• Third-party and contractor access. Supplier logins and support accounts that sit outside the normal joiner, mover and leaver process. Mandiant noted that several Snowflake compromises began on contractor laptops also used for personal activity.
• SaaS platforms with their own logins. Data warehouses, file-sharing tools and admin consoles that don't sign in through the corporate identity provider, so a central MFA rule never reaches them.
• Service and app accounts. Non-human identities and OAuth applications that hold broad permissions and are rarely reviewed.

A policy describes what you intend. A list of every path that still accepts a password alone describes what is true. Most organisations have the first and not the second.

How to find and close your MFA gaps

The UK National Cyber Security Centre's MFA guidance and CISA's MFA guidance are good starting points for choosing strong methods. Getting coverage right is a separate job, and it usually looks like this:

1. Build the inventory from the outside in. Start with what an attacker can reach: every internet-facing login page, VPN, remote desktop gateway and SaaS tenant tied to your domains. Then work inwards to every identity that can use them.
2. Record the MFA state of each path, not each user. The question is not "does Sarah have MFA?" but "does this route enforce it for everyone who uses it?"
3. Check for leaked credentials. Passwords from infostealer logs and breach dumps stay valid until someone changes them. The Snowflake campaign used some that were years old.
4. Treat dormant as dangerous. Disable accounts, profiles and apps that haven't been used, rather than leaving them in place in case they're needed.
5. Bring third parties inside the rules. Supplier and contractor access should meet the same MFA standard as staff, and be reviewed on the same schedule.
6. Re-check continuously. New systems, trials and suppliers arrive every month. An inventory that is accurate once a year will be wrong for most of it.

Watch for the login that gets through anyway

Even with good coverage, some logins will slip through: a session token stolen from a browser, a help desk talked into a reset, or a push notification approved by someone tired of the prompts. That is why detection matters as much as prevention. Password spray, sign-ins from unfamiliar infrastructure, a dormant account suddenly active, or a new OAuth application granted mailbox access are all signals that can be caught, but only if someone, or something, is looking at them at 2am as well as 2pm. At Change Healthcare, the attackers had nine days between first access and ransomware.

This is the gap urgentic is built to close. urgentic amber continuously maps your external exposure, including exposed apps and leaked credentials, so the list of password-only paths stays current. urgentic BLUE and our specialist AI agents then watch identity activity around the clock and investigate suspicious sign-ins as they happen, across the tools you already run. You can see how the pieces fit together on our platform page.

None of the fifteen breaches involved urgentic customers, and no single control would have stopped every one. But the pattern is clear enough to act on: know every way in that still asks for only a password, close as many as you can, and keep watching the ones you can't.