When I first started thinking seriously about applying zero trust principles to the storage layer, it wasn’t because of some white paper or vendor presentation. It was because of what I saw happen during a ransomware incident that still keeps me up at night. The attackers didn’t just target production systems; they also went after backups. At that moment, I realized we’d been fooling ourselves about what true resilience looked like.
That gut-punch experience taught me something crucial: if your storage layer isn’t zero trust-ready, everything else you’ve built is standing on quicksand. This isn’t theoretical anymore. Let’s look at what happened to Change Healthcare in February 2024. The attackers didn’t stop with encrypting their data; they also systematically destroyed the organization’s ability to recover by targeting backups that weren’t properly isolated. Months of chaos. Billions in losses. All because storage was treated as a trusted afterthought.
The numbers can be scary. Ransomware attacks continue to get more frequent and more devastating. We’re not just dealing with more attacks — we’re dealing with smarter ones. Today’s ransomware isn’t content to just encrypt your files. Strains like Qilin are purpose-built to hunt down and destroy your backups. Dire Wolf goes even further, making restoration technically impossible. Criminals have industrialized their approach with Ransomware-as-a-Service platforms, such as Medusa, and are specifically targeting the one thing we’ve always counted on: our ability to recover.
Why storage remains our Achilles’ heel
After years of helping organizations implement zero trust for networks, identities and applications, I consistently observe the same pattern: storage is often overlooked. Every. Single. Time.
I’ve identified three reasons this keeps happening:
Storage feels invisible. Most teams view it as “back-end infrastructure”; something passive that simply sits there. However, the reality is that MITRE ATT&CK techniques such as T1485 (Data Destruction) and T1490 (Inhibit System Recovery) are specifically targeted at storage. Attackers know exactly where to hit us, and we’re still thinking of storage as scenery instead of a battlefield.
It’s genuinely complex. Try enforcing consistent policies across multiple cloud providers, regions and on-premises systems. I’ve seen teams spend months just mapping their storage footprint, let alone securing it.
We inherited bad assumptions. For years, we’ve treated data as “trusted” simply because the application accessing it was secure. But what happens when an attacker bypasses the application entirely and goes straight to the storage APIs? Game over.
3 principles that actually work
After implementing storage-layer zero trust across multiple organizations, I realized the importance of framing this challenge around three leadership principles to ensure strategic outcomes are understood by executives.
1. Control where data can be touched
Perimeter controls for storage require setting clear policy boundaries so that only trusted networks and environments can use storage APIs, rather than relying on a single firewall.
In one rollout I led, we used network boundaries to prevent cross-project sprawl in a multi-tenant cloud environment. The result was immediate: even with valid credentials, an attacker outside the perimeter had no pathway to sensitive datasets.
The important lesson here? Make “deny by default” the organizational norm, and treat every exception request as a risk decision.
2. Control who can touch it and when
Identity and Access Management (IAM) for storage needs to go beyond static role assignments. That means:
Least privilege: Only the permissions needed, for only as long as they’re needed.
Separation of duties: Different people control access rights and retention settings.
Just-in-time access: Privileges granted for a specific task, then revoked automatically.
This shift was tough — developers feared losing speed and operations disliked the added approval steps. But tying JIT to clear privilege and audit reductions drove adoption.
3. Make some data untouchable
Write-once-read-many (WORM) immutability isn’t just a compliance checkbox; it’s a strategic safeguard. Once applied, a retention lock ensures that even privileged insiders can’t alter or delete protected data until the lock expires.
I’ve seen the difference this makes. In a simulation, an “attacker” with administrative credentials was able to wipe entire datasets except for the immutable backups. That was the difference between a full-blown crisis and a quick recovery.
For leaders, the takeaway is clear: immutability buys you time and certainty, which are the two things you’ll want most in the middle of an incident.
When storage wasn’t ready: Real-world lessons
Every major breach teaches us something. These attacks all share one terrifying commonality — the attackers targeted recovery points as aggressively as primary systems.
Maersk (2017) got lucky in the worst possible way. When NotPetya wiped out their global infrastructure, including domain controller backups, the only surviving data came from a single server in Ghana that had been offline due to a power outage. One power outage. That’s what stood between a shipping giant and complete digital annihilation.
JBS Foods (2021) had backups that survived the REvil attack. They still paid an $11 million ransom. Why? Because recovery would have taken longer than their business could survive. Having backups isn’t enough — you need recovery that’s fast enough to keep your business alive.
Miljödata (2025) illustrates the evolution of supply chain attacks. One Swedish IT provider was hit, and suddenly, 200 municipalities were unable to process payroll. If your critical vendors aren’t following zero trust principles for storage, their vulnerabilities become your vulnerabilities as well.
DaVita (2025) faced the double-extortion nightmare — 1.5 TB of patient data stolen and systems encrypted. The Interlock group demanded ransom for both threats. A comprehensive zero-trust architecture directly counters this: perimeter controls make data exfiltration harder to achieve undetected, while immutable backups remove the leverage from encryption-based demands.
Looking through the governance lens
When I present these principles to executive teams, I focus on three clear outcomes for leaders: risk reduction, resilience and compliance. Executives should ensure the attack surface at the data layer is shrinking, that recovery points will survive if upstream defenses fail, and that retention and access policies are mapped to key regulations, such as SEC 17a-4(f) or HIPAA.
Policy as code has been a game-changer here — not because it’s “DevOps-cool,” but because it provides leaders with an auditable and reviewable change history for every critical control. For the board, this means we can answer questions like, “How do you know the backups are locked?” by pointing directly to the policy commit log, demonstrating transparency and accountability.
Lessons from the trenches
Extending zero trust to storage isn’t a weekend project. Here’s what I wish someone had told me before I started:
Expect pushback about speed and complexity, but automation, straightforward exception workflows and metrics can demonstrate that risk reduction needn’t harm productivity.
Simulations matter more than you think. Running a ransomware tabletop without testing your storage recovery is like conducting a fire drill without verifying that the exits are functional. You don’t know if your strategy holds up until you test it under pressure.
Finance leaders can become your biggest allies. I learned to bring CFOs into the design process early. Once they understood how retention policies translated into recovery assurance and protection against multi-million-dollar ransom payments, they became champions for funding.
The hard question
If you’re responsible for your organization’s cyber resilience, ask yourself this: If an attacker had valid credentials and network access right now, could they compromise your recovery points?
If you answered “yes” or “I’m not sure,” then your zero-trust strategy is incomplete.
Don’t wait until attackers are inside to find storage gaps. Zero trust for storage is a business imperative for survival, not just a technical upgrade.
We need to stop treating storage as invisible infrastructure and start treating it as the active attack surface it really is. Because when everything else fails, the speed and certainty of your recovery will be the only thing standing between your organization and catastrophe.
This article is published as part of the Foundry Expert Contributor Network.
Want to join?
No Responses