Every March 31, the hosting industry runs its backup reminder cycle. Check your backups. Test your restores. Follow the 3-2-1 rule. The advice is not wrong. It is just aimed at a threat that is no longer the primary one.
The 3-2-1 rule predates the commercial internet. It assumes the enemy is hardware failure, fire, or accidental deletion. It does not assume that the person deleting your backups has valid credentials and logged in through the front door.
How Attackers Actually Get In Now
Cloudflare’s 2026 Threat Report, published March 3, describes a fundamental shift in attacker methodology. The report frames it as moving from “breaking in” to “logging in.” Attackers are not exploiting vulnerabilities to get a foothold. The report identifies infostealers like LummaC2 as the primary mechanism: they harvest active session tokens from compromised machines and sell them.
The same report flags a further escalation: session token theft is now prioritized over password theft, because stolen session tokens bypass multi-factor authentication entirely. The attacker does not need your password. They do not need to pass your MFA prompt. They present a valid session token and the system treats them as you.
This matters for backup in a specific way. Your backup management console is a web application with an authentication system. If your production account credentials or session tokens are compromised, the same access that reaches your live environment typically reaches your backup configuration. An attacker with that level of access can locate backup schedules, identify backup destinations, and either delete the backups or encrypt the backup target before triggering the ransomware payload on production systems.
The 3-2-1 rule does not account for an attacker who has already authenticated to your backup system.
The Exfiltration Problem the Backup Industry Does Not Discuss
The European Commission’s AWS account was breached in late March 2026. Attackers accessed part of its cloud infrastructure and took data from its public-facing Europa.eu websites. AWS confirmed its platform ran exactly as designed. The attack surface was the account configuration, not the platform. Data left the environment before detection.
Backup is a recovery tool. It restores data that has been deleted, corrupted, or encrypted. It does not address data that has been copied and removed. If an attacker exfiltrates your customer database, your backup copy is intact. The breach still happened. The data is still gone from your exclusive control. Your recovery time objective is irrelevant to the outcome.
The ShinyHunters group, which claimed responsibility for the EC breach, is a financially motivated extortion group. Their documented methodology is credential theft via social engineering, followed by data exfiltration and ransom demands. Backup is not part of the negotiation leverage in that model. The attacker does not encrypt your data. They copy it and threaten to publish it. Restoring from backup changes nothing about that threat.
For hosting companies that store customer data, this is a direct operational concern. A breach that exfiltrates customer records, billing data, or credentials is a breach regardless of backup posture. The question of recovery is separate from the question of exposure.
What 3-2-1 Covers and What It Does Not
The 3-2-1 rule is: three copies of data, on two different media types, with one copy offsite. It is a reasonable architecture for protecting against hardware failure, localized disaster, and accidental deletion. Those remain real risks. The rule is not obsolete. It is incomplete.
What 3-2-1 does not specify:
Immutability. A backup destination that can be written to by the same credentials that write to production can also be deleted or overwritten by anyone with those credentials, including an attacker. Immutable storage, meaning storage that cannot be modified or deleted for a defined period regardless of credentials, breaks this attack vector. The backup exists in a state the attacker cannot change even if they have full account access.
Credential isolation. If the account that manages backups is the same account that manages production, or uses the same credentials, a single credential compromise affects both. Backup systems with separate authentication, separate access keys, and separate management planes are not immune to attack, but they require a second, separate compromise rather than inheriting the first.
Recovery testing. The 3-2-1 rule describes storage architecture. It says nothing about whether the restore process actually works. A backup that has never been tested is a backup that produces a recovery time estimate with no empirical basis. For hosting companies managing customer data, an untested backup is a liability, not an asset, because it creates false confidence that affects incident response decisions.
The Hosting Company’s Specific Position
Hosting companies face this problem at two levels simultaneously.
At the infrastructure level, they manage backups of their own systems: control panels, billing platforms, DNS configurations, customer databases. The credential theft patterns described in the Cloudflare report apply directly to hosting control infrastructure. A WHMCS installation or cPanel server that shares credentials with backup destinations, or that stores backup access keys in a reachable location, has a single point of failure that an infostealer can exploit.
At the product level, most hosting companies sell backup as an addon, priced as a checkbox feature. The implicit message to customers is that backup is a recovery mechanism for mistakes and hardware failure. That framing does not prepare customers for the threat model their data actually faces in 2026. Customers who understand that attackers log in rather than break in make different decisions about backup architecture than customers who are told to follow 3-2-1.
There is a product opportunity here. Backup sold as immutable, isolated, and tested is a different product from backup sold as “we keep a copy offsite.” The differentiation is real, the underlying costs are not dramatically higher, and the customers who have been through a credential-based attack will pay for the distinction.
What a Current Backup Architecture Actually Requires
None of this is new technology. The components exist and are widely available. What is missing is the framing that connects backup architecture to the actual 2026 threat environment.
Immutable storage with a retention lock. Object storage with write-once-read-many policies, configured so that no account, including the account that wrote the backup, can delete or overwrite it within the retention window. AWS S3 Object Lock, Azure Immutable Blob Storage, and equivalent products from regional providers all offer this. The configuration has to be deliberate; it is not on by default.
Separate credentials for backup access. The account or service principal that writes backups should not be the same account that manages production systems. Ideally, no human logs into the backup account directly during normal operations. The backup writes automatically; human access requires a separate authentication flow that is logged and alertable.
Tested recovery. A documented, scheduled restore test with a recorded recovery time. For hosting companies managing customer data, this means restoring a representative sample of customer environments to a test destination on a schedule, not waiting for a real incident to discover that the restore process has drifted from the backup configuration.
Exfiltration monitoring alongside backup monitoring. Backup success metrics tell you whether data was written to the backup destination. They do not tell you whether that same data was also copied somewhere else. Anomaly detection on data access patterns, specifically unusual volumes of data being read or transferred outside normal patterns, is a separate monitoring requirement that backup success dashboards do not fulfill.
The Actual Question for March 31
The traditional World Backup Day question is: do you have a backup? That question was relevant when the primary risk was a failed disk or an accidentally deleted database.
The current question is more specific: if an attacker authenticated to your environment with valid credentials three weeks ago, and has spent the intervening time mapping your infrastructure, can they find and destroy your backups before triggering ransomware on your production systems? And separately: if they copied your customer database on their way in, does your backup posture change anything about the consequences of that?
The Cloudflare 2026 Threat Report describes a threat landscape where attackers log in rather than break in, bypass MFA with stolen session tokens, and trace more than half of ransomware incidents to credential theft enabled by infostealers. That is not the threat model 3-2-1 was designed for. The rule is still worth following. It is just no longer sufficient by itself.
Łukasz Nowak
Nearly two decades in IT. A decade in web hosting - and still in the trenches. Writing about the infrastructure that runs the internet from the inside.