Should your backups live in a separate cloud subscription?

There is a question that ought to come up whenever someone designs a backup layer for a cloud data platform, and in my experience almost never does: should the backup vault sit in the same subscription as the thing it protects, or somewhere else?

I say “ought to” because I have now watched this decision go unmade in several large, well-governed, heavily regulated organisations — the kind with security review boards and architecture sign-off. The pattern is always the same. The backup design is careful and competent: an Azure Backup vault with immutability switched on, soft delete enabled, resource locks everywhere. And then it sits in the production subscription, administered by the same identities that administer production, because nobody asked whether it should be anywhere else. The unspoken assumption is that immutable vault plus soft delete covers the risk. As we will see, it covers a good deal of it — and leaves a specific set of attacks wide open.

I do not think this is carelessness. I think the question is simply not in the sources people reach for. When I went looking, I found that Microsoft’s own landing-zone guidance for Azure does not raise it, the OWASP catalogues have nothing on it, and the one application-security standard that used to mention backups at all removed the requirement as “not appsec”. If your threat model is built from the usual references, this risk is not in it.

So I wanted an answer grounded in evidence rather than instinct. Keeping the vault in the same subscription is cheaper and simpler: one set of networking, one set of policies, one bill, and the backup service works without any cross-boundary plumbing. Moving it out adds cost, complexity and another thing to operate. Against that sits a worry that is easy to state: if someone compromises access to the production subscription — a leaked pipeline credential, a phished administrator, a disgruntled insider — can they use that same access to reach the backups? To delete them, reconfigure them, quietly corrupt what goes into them, or simply switch them off?

I went looking for three things: documented attacks where backups were destroyed through the production control plane; what the platform vendors, security agencies and regulators actually recommend; and exactly what an attacker who holds a production subscription can still do when every in-subscription mitigation is switched on. My examples are Azure, because that is where the question arose, but almost all of it transfers to AWS and Google Cloud.

The short version: yes, the risk is real, well documented, and exploited in the wild. But the evidence gives a more precise answer than “separate is better”, and the detail should be valuable to anyone considering the security of a cloud platform.

A few terms before we start

This post is aimed at architects and security people, but I do not want to assume everyone shares the same vocabulary, so here is the handful of Azure terms the argument depends on. If you know them, skip ahead.

Subscription. A container for Azure resources with its own billing and its own access control. A permission granted in one subscription does not carry over to another — unless it was granted higher up.

Management group. A folder of subscriptions. Permissions and policy assigned to a management group apply to every subscription inside it.

Tenant. The directory of users, groups and service identities that every subscription trusts for sign-in. Microsoft’s identity service is called Entra ID (it used to be Azure Active Directory). An organisation normally has one tenant, and all of its subscriptions hang off it.

Global Administrator. The top role in a tenant. Crucially, a Global Administrator can, with one API call, grant themselves a role called User Access Administrator at the root of the tenant. Microsoft’s own documentation says this “allows you to view all resources and assign access in any subscription or management group in the tenant” (Microsoft Learn). Hold that thought — it is the hinge of the whole argument.

Control plane and data plane. The control plane is the management API that creates, configures, deletes and sets permissions on resources. The data plane is reading and writing the data inside them. Some protections only apply to one or the other.

Immutability. A setting that stops data being changed or deleted until a retention period has passed — by anyone, including the owner. On an Azure Backup vault this is called an immutable vault; on blob storage it is a time-based retention policy, often described as WORM (write once, read many). Both can be locked, after which the setting itself can no longer be removed. Microsoft is blunt about it: “Immutability locking is irreversible” (Microsoft Learn).

Multi-user authorisation (MUA). A two-person rule for sensitive backup operations. A second resource called a Resource Guard, owned by a different person, has to approve them. Where that Resource Guard lives turns out to matter a great deal.

What has actually happened

I found more documented cases than I expected. Here are the ones that bear directly on the question, oldest first.

Code Spaces, 2014 — the textbook case

Code Spaces was a code-hosting company running on AWS. An extortionist got into their AWS control panel. When the company tried to lock them out, the attacker deleted everything they could reach. In the company’s own words, as reported at the time, “he had removed all EBS snapshots, S3 buckets, all AMI’s, some EBS instances and several machine instances”. The backups were in the same account, reachable with the same credentials. The company announced it “will not be able to operate beyond this point” and closed (Help Net Security).

Everything since has been a variation on this.

VFEmail, 2019

An email provider lost its entire estate overnight: “Every VM is lost. Every file server is lost, every backup server is lost.” The owner noted that “not all VMs shared the same authentication, but all were destroyed” — different passwords on different servers did not help. What did survive was a single backup drive hosted in another country (Krebs on Security). That one separately held copy is the small counter-example of segregation saving data.

CloudNordic, 2023

A Danish hosting company was hit by ransomware during a data-centre migration. Infected machines were connected to the internal network, which gave the attackers access to central administration and the backup systems. The attackers “succeeded in encrypting all servers’ disks, as well as on the primary and secondary backup system”. The majority of customers lost all their data (TechTarget). Two tiers of backup, both reachable from the same administrative plane.

Codefinger, 2025 — ransomware built from the cloud’s own features

Halcyon reported a campaign in which attackers used stolen AWS keys to re-encrypt objects in S3 buckets with a key only they held, using a standard AWS feature (server-side encryption with customer-provided keys), then set lifecycle rules to delete the objects after seven days (Halcyon). No malware; just the platform’s own API with the wrong person’s credentials. A copy in a separate account would have been out of reach of those keys.

Storm-0501, 2025 — the Azure case that matters most

This is the one to read if you read nothing else. Microsoft Threat Intelligence described a ransomware operation that moved almost entirely into the cloud (Microsoft Security Blog).

The attackers compromised a non-human account that had been synced from on-premises Active Directory and held the Global Administrator role, with no multi-factor authentication. From there they did exactly the thing I asked you to hold in mind earlier: “They elevated their access to Azure resources by invoking the Microsoft.Authorization/elevateAccess/action operation. By doing so, they gained the User Access Administrator Azure role over all the organization’s Azure subscriptions.” Then: “The threat actor assigned themselves the Owner Azure role over all the Azure subscriptions available.”

With Owner everywhere, they exfiltrated data and then “initiated the mass-deletion of the Azure resources containing the victim organization data, preventing the victim from taking remediation and mitigation action by restoring the data” — storage accounts, snapshots, restore points and Recovery Services vaults.

Here is the part that shapes the recommendation. Not everything could be deleted: “they faced errors and failed to delete some of the resources due to the existing protections in the environment. These protections include Azure resource locks and Azure Storage immutability policies.” For the resources they could not delete, the attackers “resorted to cloud-based encryption”, creating their own Key Vault and customer-managed key and encrypting the data with it.

Two lessons. First, a separate subscription in the same tenant would not have helped against this attacker, because they held Owner on every subscription in the tenant. Second, locked immutability did hold, where it had been applied.

Storm-3168, 2026 — an AI agent with a service principal

In September 2026 Microsoft reported an intrusion carried out, in part, by an AI agent driving compromised service principals (the non-human identities that pipelines and applications use) (Microsoft Security Blog). The principals held Contributor and Storage Account Contributor roles across several subscriptions. The destructive phase lasted about seven minutes and included “100+ storage account deletion attempts”, most of which succeeded.

Again, the protections held where they existed: “Multiple unsuccessful deletion attempts were also made against Azure Site Recovery locks and Azure Backup protection locks protecting storage accounts.” Microsoft’s recommendation from the incident is worth quoting: “Restrict access to backup and recovery resources and closely monitor attempts to modify or remove their protection controls.”

This is the attack a separate subscription does stop. A workload identity with no role assignment in the backup subscription cannot touch it.

The insider cases

The insider threat is usually framed as a hypothetical. It is not. In 2018 a former Cisco employee, five months after resigning, accessed the company’s AWS environment and, in the prosecutor’s words, “deployed a code that resulted in the deletion of 456 virtual machines”. Sixteen thousand customer accounts were disrupted for up to two weeks; the restoration cost about $1.4 million plus over $1 million in refunds (US Department of Justice). In 2023 a former employee of a Singapore IT firm, whose access had not been revoked, deleted 180 virtual servers; reports say they could not be restored (BleepingComputer).

Neither report mentions backups specifically. Both show the path: production credentials that still work, used destructively. Separate identities on the backup plane, with their own joiner-and-leaver process, are what limit it.

How often does this happen?

Often enough to be the default assumption. Sophos surveyed nearly 3,000 organisations in 2024 and found that “94% of organizations hit by ransomware in the past year said that the cybercriminals attempted to compromise their backups”. The attempt succeeded 57% of the time. Where it did, the median recovery cost was eight times higher ($3 million against $375,000) and victims were almost twice as likely to pay the ransom (Sophos). Veeam’s 2023 survey of 1,200 organisations put the figure at 93% of attacks targeting backup repositories, with 75% of victims losing at least some backups (Infosecurity Magazine).

These surveys cover every kind of estate, not just cloud. But they make the point: going after the backups is standard practice, not a refinement.

What the guidance says

Having established that the risk is real, I wanted to know what the people who write guidance actually recommend. It splits into three groups.

Those who name a separate account, subscription or tenant

AWS is the clearest. Its security blog says: “If you place the backup or replication into a separate account that is dedicated just for backup, this also helps to reduce the likelihood that a threat actor would be able to destroy or tamper with the backup” (AWS Security Blog). Its logically air-gapped vault keeps backups in an AWS-owned account and advises using a key “from another account in a secondary organization dedicated to recovery as a best practice” (AWS Backup docs). And a 2026 reference approach for cyber resilience sets out separate production, recovery and isolated-recovery accounts: “Most customers achieve this using separate AWS accounts inside an AWS Organization”, with the isolated environment having “no trust relationship to the Production Account” (AWS Architecture Blog).

Microsoft puts the boundary somewhere subtler. Its guidance on multi-user authorisation says: “To provide better protection, you can place Resource Guard in a subscription or tenant that’s different from the one that contains the vaults.” It then rates the options — same subscription gives the “least isolation”, a different subscription in the same tenant gives “medium isolation”, and a different tenant gives “maximum isolation between the backup admin and the security admin, which provides maximum security”. It also warns what breaks it: “The backup admin must not have Contributor, Backup MUA Admin, or Backup MUA Operator permissions for Resource Guard in any scenario. These permissions override the MUA protection on the vault” (Microsoft Learn).

Notice that Microsoft is talking about the approver, not the vault. The vault’s data already sits in a Microsoft-managed subscription (Azure Backup security overview); it is the vault’s settings that live in yours, and those are what an attacker reconfigures.

Google Cloud takes a third approach: its backup vault is “a Google-managed regional resource that provides isolated, immutable, and indelible storage for backups”, where backups “cannot be manually deleted by you, any other user, or Google until your specified duration has passed” (Google Cloud docs). Provider-managed isolation rather than a boundary you draw yourself.

Those who ask for separate identity or out-of-band approval

The UK’s National Cyber Security Centre (NCSC) published a set of principles for ransomware-resistant cloud backups. They are written mainly for backup providers, but they work well as questions to ask of any design. The first principle is that backups should be resilient to destructive actions, which it explains as making sure “an attacker who has compromised a system can’t make destructive requests without compromising another separate system”. It also asks for restore of older versions even when newer ones are corrupt, robust key management, and alerts on privileged actions (NCSC).

Microsoft’s own ransomware guidance says much the same: “Store backups in offline or off-site storage and/or immutable storage” and “Require out-of-band steps, such as MFA or a security PIN, before permitting modification or erasure of an online backup” (Microsoft Learn). The US CISA guide asks for offline, encrypted, tested backups and separate administrator accounts, and suggests considering “a multi-cloud solution to avoid vendor lock-in for cloud-to-cloud backups in case all accounts under the same vendor are impacted” (CISA).

Regulators, who require segregation without naming the boundary

If you work in financial services in Europe, the one that matters is DORA, the EU’s Digital Operational Resilience Act. Article 12(3) says: “When restoring backup data using own systems, financial entities shall use ICT systems that are physically and logically segregated from the source ICT system. The ICT systems shall be securely protected from any unauthorised access or ICT corruption” (EUR-Lex). Strictly, the sentence is about the systems used for restoration, but it is hard to argue that a recovery copy administered by the same identities as production is “logically segregated” from it.

In the UK, the Bank of England, PRA and FCA published their observations of effective practice in cyber response and recovery in October 2025. They describe firms “investing in immutable back-up capabilities”, using “a separate, segregated, tertiary facility designed to make it highly unlikely for an external actor to be able to gain unauthorised access”, and testing recovery “in a clean environment… without relying on potentially compromised backups or infrastructure” (Bank of England). That is observed practice, not a rule, but it tells you what the supervisor expects to see.

The common thread across all three groups: the recovery copy must be out of reach of a compromise of the primary system, including its administrators. Nobody tells you which boundary to draw. That is left to your risk assessment.

Where is OWASP in all this?

I expected the Open Worldwide Application Security Project (OWASP) — the organisation behind the Top 10 lists that most developers know — to have this risk catalogued somewhere. It does not, and in one case that is a deliberate decision.

The OWASP Top 10 for 2025 has no category that touches backups (OWASP Top 10:2025); nor did the 2021 edition. The Cloud-Native Application Security Top 10 is silent on it, as is the Kubernetes Top 10 and, more surprisingly, the Top 10 Insider Threats.

The Application Security Verification Standard (ASVS) version 4.0 had two generic requirements — that backups are taken and test-restored, and that they are “stored securely to prevent data from being stolen or corrupted” (ASVS 4.0, V8). Version 5.0 removed them. The discussion that led to the removal is public, and the reasoning was that backups are infrastructure, not application security: “I don’t think this should be in here. Different teams deal with such things” (ASVS issue #1462). A request to add an off-site backup requirement was declined on the same grounds (ASVS issue #1365).

The closest OWASP gets is the Software Assurance Maturity Model (SAMM), whose Operational Management practice notes that “failing to store backup media securely, can make the protections built into that application irrelevant” (OWASP SAMM), and the Secrets Management cheat sheet, which advises keeping backups of critical secrets in separate, cold storage and says to “monitor the backup location for (unauthorized) access and administrative actions” (OWASP Cheat Sheet Series). Both are process statements. Neither models an adversary holding the production control plane.

So if you want this risk in a recognised catalogue, look elsewhere:

MITRE ATT&CK describes it as technique T1490, Inhibit System Recovery: “In cloud environments, adversaries may disable versioning and backup policies and delete snapshots, database backups, machine images, and prior versions of objects designed to be used in disaster recovery scenarios.” Its mitigation, M1053, is explicit: “copy backups to other accounts or regions to isolate them from the original copies” (MITRE ATT&CK T1490). T1485, Data Destruction, covers the deletion itself, and its sub-technique T1485.001 covers the Codefinger trick of using lifecycle rules to do the deleting for you (MITRE ATT&CK T1485.001).
CIS Controls v8, Control 11 (Data Recovery), safeguard 11.4: “Establish and maintain an isolated instance of recovery data.” It sits in Implementation Group 1, which CIS considers the baseline for every organisation (CIS Controls 11.4).
NIST SP 800-53, control CP-6(1): “Identify an alternate storage site that is sufficiently separated from the primary storage site to reduce susceptibility to the same threats” (NIST CP-6), and CP-9 on protecting the confidentiality, integrity and availability of backup information (NIST CP-9).

The absence in OWASP is itself a useful finding. If your threat model is built only from application-security sources, this risk will not be in it.

What an attacker inside the subscription can still do

This is the part I found most useful, because it turns “separate is safer” into a list of specific things that are or are not fixed.

Assume a well-hardened single subscription: a locked immutable vault, soft delete that cannot be switched off, a locked WORM policy on the storage account holding exported metadata and encrypted secrets, resource locks on everything, purge protection on Key Vault, and multi-user authorisation with its Resource Guard in the same subscription. Now give an attacker Owner on that subscription — or a pipeline service principal with similar rights. What can they still do?

	Attacker action	Same subscription, fully hardened	Separate subscription, same tenant	Separate tenant
1	Delete existing recovery points early, or delete a vault that holds data	Blocked by locked immutability	—	—
2	Shorten retention, or switch immutability off	Blocked once locked	—	—
3	Delete the WORM storage account	Blocked — deletion “fails if there is at least one container with a locked time-based retention policy” (Microsoft Learn)	—	—
4	Remove resource locks	Possible — Owner can remove locks (Microsoft Learn); WORM still blocks row 3	Removed	Removed
5	Stop protection, keep the data, and let it expire	Possible. An immutable vault still lets you “stop protection of the instances while retaining data forever or until their expiry”. MUA would block this — but not when the Resource Guard is in the same subscription	Removed, if the vault’s owners and the Resource Guard are outside the platform team	Removed
6	Override MUA by granting oneself a role on the Resource Guard	Possible for Owner or User Access Administrator	Removed, unless the attacker also has rights there	Removed
7	Write junk into the WORM store (which then cannot be removed until it expires)	Possible with data-plane write rights	Removed, if production identities have no data rights there	Removed
8	Crypto-shred: delete or disable a customer-managed key held in production	Possible. Purge protection gives 7–90 days to notice; after that, anything encrypted with it is gone (Microsoft Learn, Key Vault recovery)	Removed only if the key moves out of production too	Removed, same condition
9	Cancel the subscription	Possible for Owner: storage goes read-only, and Microsoft deletes the data after 30–90 days (Microsoft Learn)	Removed, if the backup subscription’s owner and billing roles sit elsewhere	Removed
10	Global Administrator elevates to root and grants itself Owner anywhere	Possible	Not removed — this is Storm-0501	Removed
11	Stop new backups from the source side (revoke the backup identity’s read access, break the export job)	Possible	Not removed — it happens in production	Not removed
12	Slowly poison the source data so each new recovery point is quietly corrupt	Possible	Not removed	Not removed
13	Make Key Vault backups useless by destroying the production subscription	Possible	Not removed	Not removed

Row 13 was the surprise. A Key Vault backup blob can only be restored “into a key vault within the same Azure subscription and Azure geography” (Microsoft Learn). Wherever you store it, it is tied to the subscription it came from. If that subscription is gone, the backup is a blob you cannot open. Your secrets need a recovery story that does not depend on the production subscription surviving — re-issuing credentials from their source systems, with an escrow of whatever cannot be re-issued.

Reading the table top to bottom:

Immutability does the heavy lifting (rows 1–3). This matches the incident record: it is what held in Storm-0501 and Storm-3168.
A separate subscription removes rows 4–9. These are the “reconfigure, stop, flood, crypto-shred, cancel” attacks available to anyone whose rights end at the production subscription. That covers the most likely attackers: leaked pipeline credentials, over-privileged engineers, and insiders.
Only a separate tenant removes row 10. A Global Administrator reaches every subscription in the tenant. The cheaper partial answer is to put the MUA Resource Guard in a separate tenant, which takes the vault’s most dangerous operations away from that administrator without moving the vault.
Rows 11–13 are not isolation problems at all. They need detection (alerts on missing, late or shrinking backups), retention long enough to outlast slow corruption, regular restore drills, and a separate recovery design for secrets.

So, separate subscription or not?

Here is where I have landed.

Option A — a hardened single subscription closes rows 1–3 and leaves the rest open. Against the incident record and the regulatory wording, that is a hard position to defend. It is the Code Spaces design with better locks.

Option B — a dedicated backup subscription is the proportionate default for most platforms, with four conditions that the research made clear:

Put the Resource Guard in a different tenant. This is Microsoft’s own “maximum isolation” setting, and it is the cheapest way to take the Global Administrator path away from the vault’s most dangerous operations.
Do not hold the backup plane’s encryption keys in production. Use platform-managed keys, or keep customer-managed keys in the backup subscription with purge protection on. Otherwise crypto-shredding walks straight round the boundary.
Give the backup subscription an owner — and a billing owner — outside the platform team. No production identity should hold any role there beyond the write-only rights needed to deliver copies. Row 9 only goes away if the people who can cancel the subscription are different people.
Harden the Global Administrator path anyway. No synced accounts with Global Administrator; no standing Global Administrators (use just-in-time elevation); phishing-resistant multi-factor authentication; and an alert on every elevateAccess call. Storm-0501 began with a synced account that had none of these.

Option C — a separate tenant is the right answer when the risk assessment rates a tenant takeover as both likely enough and severe enough: a platform whose loss would be a regulatory event, say. It costs considerably more — separate identities and sign-in, cross-tenant replication that has to be explicitly allowed, and more awkward restores — and the vault services themselves generally cannot protect resources across a tenant boundary, so the design needs a copy step rather than a direct backup.

What does Option B cost? The subscription itself is free: “Cloud subscriptions don’t incur charges, only the resources within” (Microsoft Learn). Azure Backup supports cross-subscription backup for most workloads — vaulted backup of Data Lake Storage, for example, states it explicitly (Microsoft Learn). Data transfer within a region is free or close to it. The real cost is the operating model: separate access control and policy, monitoring owned by someone else, a break-glass procedure, and restore drills that cross the boundary. That is not nothing, but it is also not the barrier it is sometimes presented as.

The thing I keep coming back to

Every Azure incident I found started with an identity that could reach more than it should: a synced account with Global Administrator, a service principal with Contributor across several subscriptions. Every backup that survived did so because a lock or an immutability policy sat between the attacker and the delete button.

A subscription boundary is one more thing between the attacker and that button, and against the most common attackers it is a good one. It is not a substitute for immutability, and it is not a defence against a Global Administrator. Design for all three — immutability, a boundary, and a hardened identity path — and the question “same subscription or not?” answers itself.

But the finding that stays with me is not the technical one. It is the ASVS discussion.

Go back and read it. The maintainers of the most widely used application security standard looked at two requirements — take backups, and protect them — and removed them, on the grounds that “different teams deal with such things” and that it is “more infrastructure”. They were not wrong about how most organisations are set up. They were describing, accurately, a divide that most of us work inside every day: the application team builds the thing, and somebody else backs it up.

I think that divide is now a liability, for two reasons.

The first is that it no longer matches how software is delivered. In a DevOps world the application team writes the Terraform that provisions the storage account, the Key Vault, the managed identity and — if anyone does — the backup policy. The service principal that Storm-3168 used to delete a hundred storage accounts was not a legacy infrastructure credential; it was the kind of identity an application team creates for its own deployment pipeline, holding Contributor across subscriptions because that was the easiest way to make the pipeline work. When the application team owns the infrastructure, how the application is backed up and restored is not somebody else’s problem. It is theirs, and the standards they reach for should say so.

The second reason holds even without DevOps. Look at how these attacks actually work. Storm-0501 began with a non-human account that had no multi-factor authentication — an identity problem. It escalated through an Azure platform feature — an infrastructure problem. It ended by encrypting data with a customer-managed key the attackers created themselves — a cryptography and key-management problem, the sort of thing ASVS does cover, in a chapter that assumes the application is the thing being attacked rather than the thing being used. Codefinger was an application-layer API call made with stolen credentials. The insider cases were a joiner-and-leaver process that nobody ran. Not one of these fits neatly into “appsec” or “infrastructure”. They cross the line, because the attacker does not know or care where the line is.

Criminals in the physical world have always understood this. In the UK, the drug-dealing networks known as “county lines” gangs got their name from the way they operate: deliberately across the boundaries between police forces, because a force’s attention, intelligence and authority tend to stop at its own border. In the US, crossing a state line has been a way of shaking off the local sheriff for as long as there have been state lines. The gap between jurisdictions is not an accident the criminals stumble into; it is the terrain they choose.

The gap between an application team and an infrastructure team is the same kind of terrain. If your threat model is built from application-security sources, the destruction of your backups will not be in it. If it is built from infrastructure sources, the backup will be immutable and locked and sitting in the production subscription, reachable by the pipeline that deploys the application. Each team has done its job within its own jurisdiction, and the attacker has walked across the line between them. Neither team, on its own, will ask the question this post started with.

Somebody has to hold the whole picture — the identity, the infrastructure, the application and the recovery copy — and ask what happens when all of them are reached through one compromised credential. That is what “a holistic approach to security” means in practice. The question “same subscription or not?” goes unasked so often because it falls on a boundary, and the only people positioned to see it are the ones who refuse to accept that the boundary is where their responsibility ends.

References

Incidents

Microsoft Threat Intelligence, Storm-0501’s evolving techniques lead to cloud-based ransomware, August 2025
Microsoft Threat Intelligence, Storm-3168: agentic-driven cloud attacks using compromised service principals, September 2026
Microsoft Threat Intelligence, MERCURY and DEV-1084: destructive attack on hybrid environment, April 2023 — mass deletion through Global Administrator accounts; backups not discussed
Microsoft Threat Intelligence, DEV-0537 criminal actor targeting organizations for data exfiltration and destruction, March 2022 — locking victims out of their own tenant
Help Net Security, Code hosting Code Spaces destroyed by extortion hack attack, June 2014
Krebs on Security, Email provider VFEmail suffers ‘catastrophic’ hack, February 2019
TechTarget, CloudNordic loses most customer data after ransomware attack, August 2023
Halcyon, Abusing AWS native services: ransomware encrypting S3 buckets with SSE-C, January 2025
US Department of Justice, San Jose man pleads guilty to damaging Cisco’s network, August 2020, and the sentencing release, December 2020
BleepingComputer, Former IT employee gets 2.5 years for wiping 180 virtual servers, June 2024
Sophos, The impact of compromised backups on ransomware outcomes, 2024
Infosecurity Magazine, Backup repositories targeted in 93% of ransomware attacks (Veeam Ransomware Trends Report 2023)

Azure documentation

Stephen Masters

Software developer and architect. I build systems for places that move energy, commodities, and money around. I keep a bike-packing journal at velostevie.com.

github mastodon rss