Ransomware Protection in Microsoft 365: How Attacks Get In and What Stops Them
Ransomware protection tends to get discussed as though it were a product decision. Buy the right tool, switch it on, and the problem is handled. That framing is comfortable, and it is why so many organisations that have bought something still get hit.
In Microsoft 365 environments, the overwhelming majority of incidents do not begin with clever malware defeating a security product. They begin with someone signing in. A credential from an old breach still works, or a convincing phishing email harvests a password, and from that point the attacker is not breaking in at all. They are logged in, holding whatever permissions that account holds, moving at the speed of a legitimate user.
That changes what protection actually means. The controls that matter most are not exotic. They are identity, patching, endpoint protection, sensible permissions and a tested route back, and almost all of them are already sitting in your tenant, licensed and half-configured. The gap is rarely a missing product. It is the unglamorous maintenance nobody owns.
Knowing which layers you genuinely have working, and which you only assume are, is what decides whether an incident becomes a bad afternoon or a fortnight of lost trading.
Quick summary
Ransomware in Microsoft 365 usually arrives through a compromised account rather than a technical exploit, which is why identity controls matter more than any single security product.
Protection is layered maintenance, not a purchase.
How ransomware actually gets into a Microsoft 365 environment
The mental image most people hold is of malware landing on a server and encrypting everything in sight. That still happens, but in cloud-first organisations the more common pattern is quieter.
An attacker obtains working credentials, usually from a previous breach elsewhere or a phishing page. They sign in, look around, and use the access they now hold. Because they are authenticating legitimately, nothing about the traffic looks obviously wrong. Files sync, mailboxes open, Teams loads.
The Microsoft 365 password spray attack that generated 81 million login attempts is a good illustration of the pattern: no new vulnerability, just old passwords tested at scale until some worked. Once inside, encryption or exfiltration is simply what the attacker chooses to do with valid access.
That is why ransomware protection starts at the front door rather than at the point of encryption.
Layer one: identity
If an attacker cannot authenticate, most of what follows never happens. Multi-factor authentication is the single most effective control available, and the important detail is that having it is not the same as having it everywhere.
The gaps that matter are the familiar ones:
- MFA applied to administrators but not to standard accounts, which are the ones most commonly compromised
- MFA required only from unfamiliar locations, which attackers work around
- Conditional Access policies configured correctly and then left in report-only mode
- Legacy authentication protocols left enabled, which bypass the interactive prompt entirely
Fixing these is configuration work rather than expenditure, and it removes the entry route that the majority of incidents rely on.
Layer two: patching and endpoints
Once an attacker has a foothold, unpatched software is what lets them move further and do more damage. This is the least interesting layer and one of the most consequential.
Keeping devices current is a maintenance discipline rather than a project, which is precisely why it slips. Windows Autopatch handles Microsoft’s own updates automatically with staged rollout rings, though it is worth remembering it does not touch third-party applications such as browsers and PDF readers, which are a common route in. Endpoint protection through Defender for Endpoint covers the device-level behaviour that cloud controls cannot see.
The practical test is simple: can you say, today, how many of your devices are more than a month behind on updates? If the answer is no, that is the gap.
Layer three: limiting the blast radius
Assume, for a moment, that an account does get compromised. What that account can reach is what ransomware can encrypt.
Most organisations accumulate permissions rather than manage them. People change roles and keep old access. Sites get shared broadly to solve a short-term problem and never get tightened. Service accounts hold far more privilege than their function requires. None of this is visible day to day, and all of it expands the damage of a single compromise.
Reducing blast radius means periodically reviewing who can reach what, keeping administrative privilege separate from everyday accounts, and using tools like Defender for Cloud Apps to spot unusual behaviour such as mass file downloads or sudden sharing activity.
What Microsoft 365 recovers natively, and what it does not
Microsoft provides genuine recovery capability, and it is more useful than many organisations realise. It is also more limited than most assume.
According to Microsoft’s own guidance, files in SharePoint and OneDrive are protected by three mechanisms: versioning, which retains a minimum of 500 versions by default; the recycle bin, which holds deleted items for 93 days; and Files Restore, which lets you roll a library or a whole OneDrive back to any point in the previous 30 days.
The limits are worth stating plainly:
- Thirty days is the restore window. Ransomware that sits dormant for longer than that, which is not unusual, can put the clean restore point out of reach.
- Files Restore is manual. An administrator has to notice, decide and initiate it. Nothing happens automatically while everyone is still working out what is going on.
- It does not cover email. There is no equivalent rollback for an Exchange Online mailbox, which matters because Teams chat messages are stored in mailboxes too.
Native recovery is a real safety net for a contained incident. It is not a substitute for a genuine backup, and our piece on Microsoft 365 backup covers where that distinction bites.
The part most plans miss: who decides
Technical controls get attention. The decision-making rarely does, and it is what determines how long an incident lasts.
During a live incident somebody has to decide whether to disable accounts, whether to disconnect systems, who contacts the insurer, who speaks to staff and customers, and whether the ICO needs notifying within the statutory window. If those decisions are being made for the first time at eight o’clock on a Friday evening, everything takes longer.
Writing down who holds each of those decisions, and making sure they can be reached out of hours, costs an afternoon. Aligning with a framework such as Cyber Essentials is a straightforward way to surface these gaps alongside the technical ones.
Common mistakes and pro tips
The patterns that come up repeatedly are rarely exotic:
- Treating backup as protection, when it is the last line rather than the first
- Assuming MFA coverage is complete without checking which accounts and applications it actually applies to
- Buying an additional security product while leaving existing licensed capability unconfigured
- Never testing a restore, so the recovery time is unknown until it matters
The organisations that recover well are usually the ones that had rehearsed something, however briefly, before they needed it.
Would you know how far an attacker could get?
Our free Microsoft 365 risk and cost health check reviews your identity controls, device patching, permissions and recovery position, and tells you where an attacker would find room to move. No obligation, and if your defences are already sound we will say so.
The bottom line on ransomware protection
There is no single product that delivers ransomware protection, which is inconvenient, because a single product is what most organisations would prefer to buy. What actually works is several ordinary controls being properly configured and then maintained: identity locked down across every account and application, devices patched, permissions reviewed rather than accumulated, and a route back that somebody has tested.
Nearly all of that is already included in Microsoft 365 licensing. The reason it so often fails is not cost or capability. It is that ongoing maintenance has no obvious owner, so it quietly stops happening.
Our Microsoft 365 Support service takes on that ownership, keeping identity controls, patching, permissions and recovery in working order rather than in a state that looked right at some point in the past.
STRAIGHT ANSWERS
Frequently asked questions
Does Microsoft 365 protect against ransomware?
Partly. Microsoft 365 includes meaningful protection and recovery features, including versioning, a 93-day recycle bin, Files Restore covering the last 30 days, and ransomware detection alerts. These help considerably with a contained incident, but they depend on correct configuration and do not extend to email rollback, so they are one layer rather than a complete answer.
What is the most common way ransomware gets into Microsoft 365?
Compromised credentials. Attackers typically obtain a working username and password through a previous data breach or a phishing page, then sign in legitimately. Technical exploits are far less common than simply using an account that should have been better protected.
Is a backup enough to protect against ransomware?
No, though it is essential. A backup determines whether you can recover, not whether you get attacked, and recovery still costs time and disruption. It also needs to be genuinely separate from the environment it protects, or an attacker with sufficient access can reach it too.
How long does Microsoft 365 keep files after a ransomware attack?
Files Restore allows recovery to any point within the previous 30 days. Deleted items remain in the recycle bin for 93 days. Versioning retains a minimum of 500 versions of a file by default. Ransomware that activates after a long dormant period can fall outside these windows.
Should we pay a ransom?
Law enforcement guidance, including from the National Cyber Security Centre, advises against paying. Payment does not guarantee recovery, marks the organisation as willing to pay, and may carry legal implications depending on who the attacker is. The decision is far better considered in advance than during an incident.
