Your Storage Was Hardened Once. It Isn’t Anymore.

Configuration drift: the silent creator of security risk in storage and backup systems.

Every storage and backup environment drifts. Firmware updates reset settings back to their defaults. Temporary changes made during an outage never get reverted. A vendor account created for a support engagement outlives it. A permission gets widened “just for now.” A retention policy gets adjusted to relieve pressure on a busy window.

None of these decisions is wrong in isolation, and none trips an alarm – but together they pull a storage system, quietly, away from the hardened state it started in.

The problem isn’t that drift happens. Drift is the unavoidable byproduct of a living environment – one that gets patched, migrated, and reconfigured to keep the business running. The problem is how long it goes unseen.

In storage and backup infrastructure, the gap between drifted and detected is often measured in months. These systems are rarely checked with the same rigor as the compute and network layers around them.

That neglect shows up clearly in the data. Core6’s 2025 Security Maturity of Storage & Data Protection Systems report drew on StorageGuard risk assessments across 323 enterprise environments in North America and EMEA, spanning 11,435 devices.

The finding: the average storage or data protection device carries 10 distinct security risks – five of them rated high or critical.

Across the sample analyzed, 6,085 discrete misconfigurations and vulnerabilities were detected, spanning more than 390 security principles that weren’t adequately followed.

This isn’t a story about a few sloppy outliers. It’s the baseline state of the industry.

Common storage and backup hardening gaps

Drift is a general phenomenon, but it concentrates in a handful of specific, consequential places. Core6’s report ranked the five most common risk categories across every environment assessed, and they’re worth walking through, because they’re the exact areas where a drifted setting does the most damage:

• Authentication and identity management (the single most common category). This is where over-privileged and orphaned accounts pile up. The vendor account created for a support engagement that outlived it. The admin whose privileges were never scoped back down. The service account with far more access than it needs. It also covers factory default accounts that were never locked or renamed, missing multi-factor authentication, and the absence of Dual Control over destructive operations like backup deletion or immutability changes. These are among the most basic controls in security – yet they remain the number-one source of storage risk. And they matter doubly here: an immutability lock can often be removed by whoever holds storage-admin identity, so protecting those accounts is as important as the locks themselves. The report notes that the 2024 UnitedHealth attack, which caused weeks of disruption, could have been avoided or significantly reduced by better enforcing identity best practices on its storage and data protection systems.

• Unaddressed CVEs. Storage and backup systems run a surprisingly large stack of proprietary firmware and software. Vulnerabilities in them are published constantly. The problem is that mainstream vulnerability management tools mostly don’t see them — they scan server OSes and network gear, not storage platforms. The result: 281 distinct CVEs were found across the environments assessed, with 39% of analyzed devices exposed to at least one. And these aren’t obscure. Recent examples include critical, actively exploited flaws in Dell, Veeam, Acronis, and Veritas Backup Exec products — several used directly by ransomware groups.

• Network and protocol security. This is the classic “exposed front door” problem. Storage arrays, backup appliances, and data protection software each ship with management consoles and interfaces — too often left broadly reachable. Legacy or insecure protocols are routinely left enabled: SMBv1, NFSv3, cleartext HTTP management sessions, insecure SNMP community strings. Add failures to enforce secure versions of storage-specific protocols like NDMP, replication, and SAN fabric management, and you have a set of well-understood weaknesses that quietly reappear after every migration. Restricting and monitoring administrative access is one of the most basic hardening steps — and one of the most commonly skipped.

• Encryption and key management. Immutability prevents deletion and modification — but not reading. A backup repository that’s network-accessible and not encrypted at rest can still be exfiltrated wholesale. Other common gaps: obsolete cipher suites (TLS 1.0/1.1 left enabled, SSL 2.0/3.0 not disabled — some of which must be off for PCI-DSS compliance), and unencrypted management, replication, and backup transport. Most critical of all: backup copies protected with weaker encryption than the source data they’re meant to safeguard.

• Access control and authorization. A large number of devices showed over-exposure: unrestricted access to shared storage, unrecommended zoning and masking, storage elements reachable from external networks. A recurring failure is backup copies that are less restricted than the production data they protect. When the copy is easier to reach than the original, the protection is illusory.

Beyond the top five, the report flags several high-severity patterns that map directly to backup resilience. The most important concerns immutability itself. Adoption is rising year-on-year, which is genuinely welcome. But the report detected a significant number of misconfigured deployments – and a partial or incorrect implementation creates a false sense of security that can be worse than none.

The specifics are telling. Ransomware-protection features are frequently licensed but left inactive, or enabled without following vendor best practices. Immutable copies that aren’t actually locked. Time services left unhardened, letting an attacker roll the clock to bypass retention enforcement. Retention locks never configured – so an attacker can flood the backup pool with junk data and force the system to delete existing backups to make room. Dual authorization for deletes missing entirely.

On top of that, a notable share of systems were running end-of-support, receiving no security updates at all. And in more than 10% of environments, approved API and CLI access paths weren’t properly hardened, with undocumented entry points discovered whose purpose couldn’t even be accounted for.

A final, quieter gap runs underneath all of these. Many organizations never test whether their backups are actually recoverable. And they don’t log or alert on unauthorized access to backup and storage systems. The combination is dangerous: a compromised or poisoned backup job can run undetected for months, revealing itself only at the worst possible moment – during an attempted recovery.

None of these are exotic. They’re the everyday gaps that open quietly as real environments get updated, migrated, patched, and reconfigured. The through-line the report draws is worth sitting with: storage and data protection systems suffer equally. There was no meaningful difference in hardening between primary storage and backup environments. Both drift, both are under-secured — and any one of these gaps can turn a recoverable incident into an unrecoverable one.

How these gaps get exploited in the real world

This isn’t theoretical. Attackers have shifted decisively toward the data layer, targeting storage and backup either as a primary objective – exfiltrating large volumes of data “under the radar” from less-defended copies – or as a secondary one, destroying every backup copy just before triggering a ransomware payload.

The CVE examples are concrete and recent. A critical flaw in Acronis Cyber Infrastructure (CVE-2023-45249) was flagged by CISA as actively exploited, allowing remote code execution via default passwords. A patch was available for months, but many organizations never applied it – and were exploited in the wild.

The ALPHV/BlackCat group used a set of Veritas Backup Exec (a Cohesity company) vulnerabilities for initial access to deploy ransomware. A critical Veeam flaw (CVE-2024-40711) was used in Frag ransomware attacks, prompting a warning from NHS England. In each case, the weakness lived in the backup or storage layer itself – the very system meant to be the last line of defense.

Backups are now a primary target precisely because destroying them removes the victim’s leverage. The 2024 UnitedHealth attack is the reference case. The company restored core services in about a month, but fully resolving the fallout took several months — especially for the healthcare providers who depend on it. Core6’s report notes that stronger enforcement of identity best practices on its storage and data protection systems could have avoided or significantly diminished the incident.

The pattern underneath these headlines is the same one the maturity data describes. The attackers aren’t necessarily using novel techniques; they’re walking through doors that drift left open – an unpatched CVE, a default password, an over-exposed backup share, an immutability setting that was licensed but never actually locked.

Configuration baselines: the foundation of security and compliance

If drift is the problem, a baseline is the reference point that makes it visible. A configuration baseline is simply the documented, known-good state your systems are supposed to be in. It defines what “secure” means for your environment: the specific settings, access controls, encryption requirements, immutability and retention parameters, and hardening options.

Without a baseline, you can’t detect drift, because you have nothing to measure against. “Secure” becomes a matter of memory and assumption. With a baseline, every configuration can be continuously compared against the intended state — and any deviation becomes an answerable question rather than a silent risk.

Baselines are also where security and compliance meet. Established frameworks – NIST, CIS Benchmarks, and vendor-specific hardening guides – give you a defensible, externally recognized definition of secure, rather than one you invented internally. That matters enormously in regulated industries. Auditors increasingly want evidence not just that you were compliant on the day of the audit, but that your systems stayed within their baseline continuously. Cyber-insurers now expect demonstrable, tested hardening rather than a signed attestation. A baseline turns “trust us, it’s secure” into “here is the standard, and here is proof we’re meeting it.”

Maintaining secure baselines at scale

Defining a baseline is the easy part. The hard part – the part that defeats most organizations – is keeping real environments aligned to it as they change, across a multi-vendor estate, at enterprise scale.

This is precisely where the traditional approach falls apart. Storage and backup vendors ship their systems with only a minimal base level of security – deliberately, since they can’t know your environment. It’s left to the infrastructure team to define a hardening baseline, implement it, and – in the report’s own words – ensure that configuration is enforced continuously over time, not just at initial deployment. That last part is where most programs break down.

A quarterly audit tells you your posture on one day and leaves the rest of the quarter as a blind spot. And in an estate spanning primary storage, secondary storage, backup appliances, and multiple vendors – each with its own settings and its own ways of drifting – manual, periodic checking simply cannot keep up.

Maintaining baselines at scale requires three things periodic review can’t provide. Continuous assessment, rather than point-in-time snapshots. Coverage that spans every vendor and platform in the estate, rather than checking them in isolation. And prioritization that surfaces the deviations that actually matter, so teams aren’t buried under thousands of undifferentiated alerts. The goal isn’t to eliminate drift – that’s impossible in a living environment. It’s to shrink the time between when something drifts and when you know about it, from months down to something you can act on.

This is exactly the problem StorageGuard was built to solve. It continuously assesses configurations across enterprise storage, backup, and recovery systems from multiple vendors. It checks them against established baselines like NIST and CIS, as well as vendor-specific hardening guidelines. And it flags drift and security exposures as they emerge – catching the retention lock that was never configured, the immutability setting that got disabled, the access control that quietly widened. Rather than proving your environment was hardened at a single point in time, it keeps the gap between drift and detection short. Configuration drift stops being a silent risk and becomes a managed one.

Configuration drift will never be fully eliminated. The thing that causes it – a working environment that changes over time – is also the thing that keeps your business running. The organizations that stay secure aren’t the ones that somehow freeze their environments. They’re the ones that define what secure looks like, then catch the drift away from it fast enough that it never has time to matter.

Want to know where you actually stand?

Reading through five domains is one thing; knowing how your own estate scores against them is another. That’s exactly why we built the Enterprise Storage & Backup Security Self-Assessment.

It walks you through these same five domains and gives you back a weighted scorecard that surfaces your gaps and shows you which controls to fix first.

Take the Enterprise Storage & Backup Security Self-Assessment

---

Frequently Asked Questions (FAQs)

What is configuration drift in storage and backup systems?

Configuration drift is the gradual divergence of a system’s actual settings from its intended, secure configuration over time. In storage and backup environments, it happens through routine operational changes — firmware updates that reset settings to defaults, temporary changes that are never reverted, vendor accounts that outlive their purpose, widened permissions, and adjusted retention policies. Each change is individually reasonable and none triggers an alarm, but together they move the environment away from its hardened baseline. The scale is significant: Core6’s 2025 Security Maturity report found the average enterprise storage or data protection device carries 10 distinct security risks, five of them high or critical — evidence that drift, left unchecked, is the normal state of these systems rather than the exception.

Why is configuration drift such a significant security risk?

Configuration drift is dangerous because it is invisible and cumulative, and because storage and backup systems are checked far less rigorously than the compute and network layers around them. Core6’s 2025 research found 281 distinct CVEs across the environments assessed, with 39% of analyzed devices exposed to at least one — largely because mainstream vulnerability management tools don’t scan storage platforms. In storage and backup specifically, drift can disable immutability, misconfigure retention locks, or leave management interfaces exposed, turning a recoverable ransomware incident into an unrecoverable one. Because attackers now routinely target backup repositories before encrypting production, a drifted backup configuration directly undermines an organization’s ability to recover without paying a ransom.

What are the most common storage and backup hardening gaps?

The most common gaps include immutability or retention locks that are not actually enabled or are undermined by misconfigured policies; exposed management interfaces and unchanged default credentials on arrays and backup appliances; over-privileged or orphaned accounts, including vendor accounts that outlived their engagement; untested backups and unmonitored access that let compromised or poisoned backup jobs run undetected; and encryption or protocol gaps that leave network-accessible repositories open to exfiltration. These gaps are rarely the result of negligence — they open naturally as environments are updated, migrated, and reconfigured, which is why continuous checking is needed to catch them.

What is a configuration baseline and why does it matter?

A configuration baseline is the documented, known-good state that storage and backup systems are supposed to maintain — the specific settings, access controls, encryption requirements, and immutability and retention parameters that define a secure configuration. Baselines matter because you cannot detect drift without a reference point to measure against. They also form the foundation of compliance: frameworks like NIST and CIS Benchmarks provide an externally recognized definition of secure, and auditors and cyber-insurers increasingly want evidence that systems stay within their baseline continuously, not just on the day of an audit. A baseline turns security from an assumption into something verifiable.

How can organizations maintain secure configuration baselines at scale?

Maintaining baselines at scale requires continuous assessment rather than periodic reviews, coverage across every vendor and platform in the estate, and prioritization that surfaces the deviations that matter most. Periodic auditing cannot keep pace with drift, because drift occurs continuously through everyday operational changes while manual reviews happen only occasionally — and mainstream security tools largely don’t cover storage and backup platforms at all. Solutions like StorageGuard address this by continuously assessing configurations across multi-vendor storage, backup, and recovery systems, checking them against baselines such as NIST and CIS and vendor hardening guidelines, and flagging drift and exposures as they emerge — shrinking the gap between when a system drifts and when the team becomes aware of it from months down to a timeframe teams can act on.