A lot of IT teams find out the hard way that Microsoft 365 and ransomware are not the incompatible pair they assumed. The old mental model, where ransomware locks down local machines and cloud data stays safe, was considered inaccurate years ago. Modern ransomware knows exactly how to follow files into SharePoint and OneDrive, and when it gets there, Microsoft’s built-in tools are rarely enough to clean up the damage.
Here’s what happens, why native protection falls short, and what a recovery plan looks like.
How Ransomware Gets Into SharePoint
The most common entry point is the OneDrive sync client. When a device running OneDrive sync gets infected, ransomware encrypts files on the local drive. The sync client then pushes those encrypted versions straight up to SharePoint and OneDrive, treating the corruption as a perfectly normal file update. Within minutes, encrypted files are sitting in SharePoint libraries, version history has logged the encrypted files as the latest edits, and the damage has already spread to anyone else syncing those same libraries.
This is not a hypothetical scenario. It happens to organizations of every size, in every industry. The speed of modern ransomware, combined with cloud sync, means infections travel faster than most security teams can react.
What Microsoft’s Native Tools Do
Microsoft gives SharePoint and OneDrive users two main recovery tools: version history and the recycle bin. On paper, these sound like reasonable safeguards. In practice, neither was built with ransomware in mind.
Version history keeps copies of earlier file states, which genuinely helps when someone accidentally overwrites a document. The problem is that version history stores those copies inside the same tenant it is supposed to be protecting. When ransomware encrypts files aggressively across multiple libraries, the version history fills with encrypted versions just as fast. Rolling back manually, one file at a time, is not a realistic recovery path when thousands of files are affected at once.
The recycle bin gives you 93 days to recover deleted files. That is useful for accidental deletion, but it does nothing for encryption attacks where files were never deleted, only corrupted beyond use.
There is also a hard ceiling on how far back version history goes. Microsoft limits the number of stored versions per file, and in an active SharePoint environment, those slots fill up quickly. By the time an attack is discovered, the clean versions you actually need may have already been pushed out of the version history queue entirely.
The Problem Nobody Talks About Enough
Sophisticated ransomware operators do not just encrypt files and wait. Once inside a Microsoft 365 tenant, they delete version history, empty the recycle bin, and modify retention settings before anyone on the security team even knows something is wrong. If your only recovery options live inside the same environment the attacker is already controlling, those options are compromised too.
This is exactly why immutable storage matters so much in a ransomware recovery context. Immutable storage keeps backup data in a state that nobody can modify, delete, or encrypt, including tenant administrators. It operates completely outside the Microsoft 365 permission structure, which means an attacker with full admin access to your tenant still cannot touch the backup. That separation is not a luxury feature. It’s the foundation on which everything else is based for ransomware recovery.
Why Point-in-Time Restores Change the Recovery Equation
What organizations actually need after a ransomware attack is the ability to roll their environment back to a specific moment before the infection hit. Not file by file. Not library by library. A targeted portion of the environment or all of it is restored to a clean state from a date and time that predates the damage.
Point-in-time restores make this possible. Instead of digging through encrypted version histories, hoping clean copies still exist somewhere, recovery teams can identify the last known clean snapshot and restore directly from there. The difference in recovery time between a file-by-file manual approach and a point-in-time restore is often measured in weeks versus hours.
Microsoft’s version history does not offer point-in-time restoration at the library or tenant level. It gives you per-file version rollback, which works fine for individual mistakes but falls apart completely when a coordinated attack has touched thousands of files at the same time.
What Proper SharePoint Backup Requires
Closing the gap Microsoft’s native tools leave open means turning to advanced data backup solutions like Exchangesavvy Exchange Online Backup, which is purpose-built for Microsoft 365 environments. A few things to look for when evaluating options:
Organizations running hybrid environments should also ensure legacy Exchange on premise public folder data is protected during modernization projects, as these repositories often contain business-critical information that requires the same level of backup and recovery planning as SharePoint.
Independent storage that sits entirely outside the Microsoft 365 tenant. If an attacker compromises admin credentials, they should have no path to the backup.
Frequent automated snapshots that keep the gap between the last clean backup and a potential attack as minimal as possible. Daily backups suit many organizations, but higher-risk environments need intervals more often.
Granular recovery options that let you restore individual files, entire document libraries, or full SharePoint site collections, depending on how wide the damage spread.
Long enough retention to account for slow-moving attacks that go undetected for weeks before anyone notices something is wrong.
The organizations that recover from ransomware quickly share one thing in common. They had clean, recent backups stored somewhere the attacker could not reach.
Businesses that still maintain an Exchange on premise mail box alongside Microsoft 365 should review backup coverage across both environments to avoid protection gaps during ransomware incidents or migration projects.
The Cost of Waiting
Figuring out your recovery options after ransomware hits is the most expensive way to learn that native protection was not enough. Microsoft 365‘s built-in tools were designed for accidental deletion and individual file recovery, not for coordinated encryption attacks targeting entire SharePoint environments.
The starting point is always a thorough look at what your environment can realistically recover, whether the priority is immutable backup storage, point-in-time recovery for SharePoint Online, or a full review of existing Microsoft 365 data protection coverage.
Ransomware is not a future risk to plan for eventually. For most organizations, it is an active and ongoing threat that the current setup may not be prepared for.
Frequently Asked Questions
Q1: Can ransomware actually reach SharePoint Online?
It can, and it does more often than most people expect. Ransomware that infects a device running the OneDrive sync client pushes encrypted files directly into SharePoint through the sync process. By the time anyone notices, the damage is already sitting in the cloud, and version history has logged the encrypted files as the latest updates.
Q2: Does Microsoft’s version history protect against ransomware?
Not in any meaningful way for large-scale attacks. Version history is useful for rolling back individual file edits, but it was not designed for encryption events affecting thousands of files at once. In a real ransomware scenario, version history fills with corrupted versions quickly, clean snapshots get overwritten, and file-by-file recovery becomes completely unworkable.
Q3: What is the difference between version history and a point-in-time restore?
Version history gives you per-file rollback inside SharePoint. A point-in-time restore lets you recover a full library or environment to a specific moment before the attack happened. For ransomware recovery, that distinction matters a lot. One takes hours to complete, while the other can take weeks.
Q4: Can a ransomware attacker delete SharePoint backups?
If the backup is inside the Microsoft 365 tenant, then yes. That is why immutable storage that operates independently of the tenant is non-negotiable. Backups stored outside the tenant’s administrative permissions stay protected even if an attacker gains full admin-level access to your Microsoft 365 environment.
Q5: How often should SharePoint be backed up to guard against ransomware?
Daily backups give most organizations a solid starting point, but they are not a one-size-fits-all answer. If your environment is fast-paced, stores sensitive data, or carries strict recovery requirements, you need backups running more often. The tighter you keep the gap between your last clean snapshot and an attack, the less you have to deal with afterward.
