Identity Attacks Beat Exploits: 7 Critical Gaps MFA Won't Close

Chart showing identity attacks as the leading ransomware root cause in 2026, ahead of exploited vulnerabilities
Three of the top four routes in are identity-led.

For a decade the standard advice was patch faster. That advice is now aimed at the wrong target. Identity attacks have overtaken software exploits as the leading way ransomware gets into a business, and the uncomfortable detail is that most of the victims already had multi-factor authentication switched on.

The 2026 data makes the shift hard to argue with. It also explains why so many organisations feel secure and are not.

What the 2026 numbers actually say

Sophos surveyed 2,158 IT and cybersecurity leaders across 17 countries whose organisations were hit by ransomware in the previous year. The root-cause breakdown in the State of Ransomware 2026 report is the headline finding.

Malicious email accounted for 26% of incidents. Phishing accounted for 24%. Compromised credentials accounted for 23%.

Exploited vulnerabilities — the thing most security budgets are still shaped around — accounted for 18%, down from 32% three years earlier.

Add the identity-led routes together and they dwarf the technical exploit path. The attacker is not breaking the door. They are signing in.

The 97% problem

Here is the finding that should change how you spend.

In ransomware cases where compromised credentials were the way in, 97% of those organisations already had MFA deployed. Not planned. Deployed.

MFA is still one of the highest-value controls available, and nothing here argues against it. But "we have MFA" has quietly become a statement about procurement rather than about coverage.

Deployment is not the same as enforcement, and enforcement is not the same as complete enforcement. The gap between those three is where identity attacks live.

Seven gaps that let identity attacks through MFA

1. The accounts that were exempted

Almost every tenant has exceptions. A service account that could not handle a prompt. A senior person who found it disruptive. A break-glass account created during a migration and never reviewed.

Those are precisely the accounts an attacker wants, and they are usually the ones with the broadest access. Audit your conditional access exclusions and treat each one as an open finding with an owner and a date.

2. Legacy protocols that never see the prompt

If anything in the estate still authenticates over a legacy protocol, MFA is not in the path at all. The credential works and no second factor is ever requested.

This is the same structural problem driving the Exchange Web Services retirement — older protocols predate modern identity controls and cannot be retrofitted with them. We covered the practical steps for that in our guide to the EWS retirement and Microsoft 365 migration.

3. Session tokens instead of passwords

Modern phishing kits do not try to capture your password and second factor separately. They proxy the real login page, let you complete MFA properly, and steal the resulting session token.

The user sees a normal sign-in. The attacker gets an authenticated session that has already satisfied MFA. Token protection and short session lifetimes matter here in a way that stronger passwords simply do not.

4. MFA fatigue

Repeated push notifications at two in the morning eventually get approved. This is a human factor, not a technical one, and it is solved by design rather than training.

Number matching, and moving away from simple approve or deny prompts, removes most of it. If your tenant still sends bare push approvals, that is a configuration change available today.

5. Attacker-registered factors

One of the more instructive campaigns of the last year persuaded employees to register an attacker-controlled passkey against their own account. No malware, no exploit — just a convincing prompt and a user following instructions.

Once registered, the attacker holds a legitimate second factor indefinitely. Registration events deserve the same alerting as failed sign-ins, and most tenants do not monitor them at all.

6. Phishing-resistant does not mean attack-proof

Passkeys and hardware keys are a genuine improvement and remain the right direction. They are still implemented in software somewhere.

Researchers demonstrated pass-the-passkey techniques against Windows and Entra ID this year, addressed by Microsoft in its July 2026 security update. The lesson is not that passkeys are unsafe. It is that "phishing-resistant" describes a threat model, not a guarantee, and patching still matters even in an identity-first world.

7. Nobody is watching the identity logs

Identity attacks are noisy if you are listening. Impossible-travel sign-ins, new factor registrations, unusual consent grants, sudden mailbox forwarding rules — these all generate events.

The problem is retention and attention. Default log retention is frequently shorter than the time it takes to notice a compromise, so the evidence has rolled off before anyone looks.

The six-step response order for identity attacks: close exemptions, kill legacy auth, harden the prompt, watch registrations, fix logging, rehearse
Almost all of it is configuration you already have licences for.

What to do about it, in order

The good news is that the response to identity attacks is mostly configuration, not capital expenditure.

Third-party and contractor accounts deserve the same list. Delegated admin access granted once and never reviewed is a standing invitation, and the named, scoped, time-bound model that closes it is described in our piece on remote IT consulting — the same controls that stop identity attacks against your own staff.

First, close the exemptions. Produce a list of every account excluded from MFA or conditional access. For each, either remove the exemption or write down who accepted the risk. There is usually no third option that survives scrutiny.

Second, kill the legacy paths. Block legacy authentication outright. Inventory anything that breaks, then fix those specific cases rather than leaving the door open for all of them.

Third, harden the prompt. Number matching on, bare push approvals off, phishing-resistant methods for administrators as a minimum.

Fourth, watch registration events. Alert on new authentication methods being added, especially outside normal hours or from unfamiliar locations.

Fifth, fix log retention. If your sign-in logs do not go back further than your realistic detection time, you cannot investigate anything. This is usually a licensing or storage decision that costs less than one incident.

Sixth, rehearse the identity incident. Most incident plans describe restoring from backup. Fewer describe revoking sessions, forcing re-registration and working out what an attacker read while they were inside.

What this means for smaller businesses

There is a comforting assumption that identity attacks are an enterprise problem. The data does not support it.

Credential-led intrusion is cheap and it scales. It does not require a specific vulnerability in your specific software, which is exactly why it has displaced exploitation as the dominant route.

A fifty-person business running Microsoft 365 with MFA enabled, a handful of exemptions and default log retention is a realistic target, not an unlikely one. The controls above are all available in licences that business almost certainly already holds.

That is the genuinely encouraging part of the 2026 picture. The gap between most organisations and a materially better identity posture is configuration and attention, not budget.

The compliance angle, briefly

For South African businesses there is a second reason to care.

An identity compromise that exposes personal information is a notification event, and the ability to determine what an attacker accessed depends entirely on logs you retained beforehand. Detection capability is not just a security control — it is what makes a lawful, accurate breach notification possible at all.

We set out the technical duties in more detail in our POPIA compliance checklist for small business IT. The overlap with everything above is close to total, which is convenient: the same work satisfies both.

Insurers reached the same conclusion from their claims data. An insurance application now opens with the scope of your multi-factor authentication rather than your firewall, because identity attacks are what fills the loss files — we take that form apart question by question in the 12 controls underwriters check.

Does the 2026 DBIR contradict this?

Worth addressing directly, because it looks like it does. Verizon’s 2026 Data Breach Investigations Report, published in May, found that vulnerability exploitation has overtaken stolen credentials as the leading breach entry point for the first time in the report’s nineteen-year history, at 31% of all breaches. Read beside a piece titled “identity attacks beat exploits”, that reads like a flat contradiction.

It is not, and the reason matters more than the headline. The two reports count different things:

  • Sophos measures ransomware root causes — how the attack that encrypted your files began, among organisations that were actually hit by ransomware.
  • The DBIR measures initial access across all breaches — every incident type, most of which never becomes ransomware.

Both can be true at once, and both are. Exploitation is now the most common way into a breach of any kind; identity is still how most ransomware specifically begins. If your concern is the incident that stops the business for a week, the identity picture is the relevant one. If your concern is any unauthorised access at all, patching has just become the more urgent half.

The practical answer is that this changes the ordering of what comes after identity, not identity itself. Nothing below moves; a vulnerability management programme moves up the list behind it. Anyone citing either figure without saying which population it describes is quoting a statistic they have not read.

The uncomfortable summary

If your security posture is a patching programme with MFA bolted on, you are well defended against the fourth most common way in.

Identity attacks succeed against organisations that did the right thing at a headline level and never audited the detail. The exemption list, the legacy protocol, the unmonitored registration event — these are not exotic failures. They are the normal state of a tenant nobody has reviewed.

The fix starts with an honest inventory of who can sign in, from where, with what, and what happens when they do. Everything else follows from that.

Why the shift happened at all

It is worth understanding the economics, because they explain why this trend will not reverse.

Exploiting a software vulnerability requires a vulnerability to exist in software you actually run, unpatched, reachable, with a working exploit available. Every improvement in patching cadence and every automatic-update default makes that chain less reliable for an attacker.

Stealing a credential requires a person. People are consistently available, are not centrally patched, and behave the same way at every organisation regardless of size or sector.

Identity attacks also scale in a way exploitation does not. A phishing campaign works against ten thousand targets simultaneously with no per-target research, and the infrastructure to run one is commoditised and cheap.

Add credential marketplaces and access brokers — where one group harvests access and sells it to whoever wants to deploy ransomware — and the specialisation makes the whole model more efficient again.

What good looks like in a small tenant

You do not need a security operations centre to close most of this. A realistic target state for a small business:

  • Every account, without exception, requires phishing-resistant MFA, and any exception is written down with a named owner and a review date.
  • Legacy authentication is blocked at the tenant level rather than per application.
  • Administrative work happens in separate accounts that are not used for email or browsing.
  • New authentication-method registrations generate an alert somebody actually reads.
  • Sign-in logs are retained longer than your honest estimate of how long a compromise might go unnoticed.
  • Someone has rehearsed revoking sessions and forcing re-registration, before needing to do it under pressure.

None of that requires additional licensing in most Microsoft 365 tenants. It requires an afternoon of configuration and a decision to stop granting exemptions.

Identity is the first thing we look at in any cybersecurity risk management engagement, for the reason this whole piece argues: it is where the attacks actually land, and it is usually already licensed.

Which licence you hold decides which of these controls you can switch on at all, and the answer surprises people — the plan carrying the detection and response you want after identity attacks succeed is often the cheaper one. We work through that in Business Premium versus Microsoft 365 E3.