Offline Storage vs Cloud Backup for Ransomware Protection

Cloud backup stores data on infrastructure owned and operated by a third party provider, accessed over the internet through an identity-gated console or API. Offline storage holds a copy on hardware that has no active network connection for most of its life, brought online only for scheduled, identity verified connection windows.

Every major cloud provider operates under a shared responsibility model. The provider is generally responsible for the security of the underlying infrastructure, physical facilities and hypervisor layer. The customer is responsible for configuring identity, access control, encryption keys, retention settings and monitoring correctly on top of that infrastructure.

This division matters for ransomware resilience because most reported cloud backup failures are customer side failures within that model: a misconfigured retention policy, an over-privileged service account, or a set of credentials that were phished. NCSC's cloud security guidance sets out this division clearly and stresses that customers cannot outsource responsibility for identity and configuration to the provider.

Provider responsibility

Physical security, infrastructure availability, hypervisor and platform integrity.

Customer responsibility

Identity, access control, retention configuration, encryption key handling and monitoring.

Where ransomware usually lands

The customer side of the line, through compromised credentials or misconfiguration.

Cloud backup is managed through a console or API, both of which are reachable over the network and gated by identity. This is what makes cloud backup convenient, and it is also the specific property that ransomware operators exploit. Phished credentials, stolen session tokens or an escalated service account can grant access to the same management plane a legitimate administrator uses.

NIST SP 1339 discusses cybersecurity considerations specific to cloud backup, including the risk that an attacker who compromises an account can reach backup configuration directly. Because the backup control plane and the production identity system are frequently linked, a compromise of one can extend to the other.

Cloud providers typically charge for data transferred out of their platform, known as egress. Under normal operating conditions this is a modest, predictable cost, but during a full-scale recovery from a ransomware incident, an organisation may need to retrieve its entire backed-up estate in a short period. That combination of volume and urgency can produce a large, unplanned cost at exactly the point when budget flexibility is most constrained.

Offline storage does not involve an internet transfer for a restore, because the recovery happens over a local or direct connection during a scheduled window. This does not make offline storage free, but it removes a specific and variable cost that only appears at the worst possible time with a cloud based restore.

Restoring a small number of files from cloud backup is typically fast. Restoring an entire estate is a different problem, because the transfer is bound by available internet bandwidth, which is usually far lower than the throughput of a local storage connection. A large restore over a constrained internet link can take substantially longer than the same volume of data moving over a direct local connection.

Data sovereignty concerns which country's laws govern data based on where it is physically stored. Cloud providers often replicate data across multiple regions for resilience, which can create uncertainty about exactly where a given copy resides at a given time, and which legal jurisdiction applies to it.

Offline storage held in a specific, named facility gives an organisation direct visibility of, and control over, the jurisdiction in which its data sits. Firevault operates its Offline Secure Storage bunkers internationally, with European facilities, including the UK, live now, and facilities in the United States and the Middle East planned next. The jurisdiction in which a customer's copy is held is chosen by the customer, rather than being determined automatically by a cloud region assignment.

Cloud backup depends on the provider's own platform remaining available and the customer's account remaining accessible. Both assumptions can fail independently of ransomware. Regional or platform outages have, on occasion, made services temporarily unavailable across affected customers. Separately, billing disputes, terms of service enforcement or account-level compromise can result in a customer losing access to its own account, including any backup data held within it.

Neither scenario is a ransomware attack in the conventional sense, but the practical effect on an organisation, being unable to reach its own recovery data, is similar. An offline copy held outside any single provider's account structure is not exposed to either failure mode.

Neither model is universally superior. Cloud backup is well suited to frequent, granular recovery needs: restoring a single file, rolling back a recent change, or recovering a system shortly after a non-catastrophic failure. Its convenience and elasticity are genuine advantages for this kind of everyday use.

Offline storage is well suited to a narrower, more specific purpose: holding a clean, verified copy that shares no failure mode with production, to be used when the faster tiers have themselves been compromised, deleted or made unreachable. It is not designed to replace day to day backup operations.

• Have you mapped which recovery scenarios depend on cloud backup identity remaining intact?
• Do you know the egress cost of a full estate restore under your current cloud contract?
• Have you tested restore time at full scale, not just for individual files?
• Is at least one recovery copy held outside your primary cloud provider's account structure?
• Do you know, precisely, which jurisdiction each copy of your data is held in?
• Would an account lockout or billing dispute leave you without access to any backup copy?

Offline storage is not immune to failure. If refresh cycles are infrequent, the recovery point can lag behind business tolerance. If connection windows are poorly controlled, they can themselves become a reachable surface. Cloud backup is not inherently insecure either; many of its risks are addressed through disciplined identity hygiene, monitoring and correctly configured retention. The practical failure mode to avoid is treating either model as sufficient on its own for every recovery scenario an organisation might face.

Firevault provides Offline Secure Storage® as the offline half of a layered recovery strategy, designed to sit alongside an organisation's existing cloud or on-premises backup rather than replace it. The storage has no network interface while offline, so the credential and API-plane risks described in this explainer do not apply to it during that period.

Firevault operates bunkers internationally. European facilities, including the UK, are live now, with the United States and the Middle East planned next, and the jurisdiction in which a customer's copy is held is chosen by the customer. Connection windows are scheduled and identity verified under the Disconnect to Protect® approach, with a tamper evident record of every connection managed through Firevault Control, separately from production identity systems.

• NIST SP 800-209, Security Guidelines for Storage Infrastructure

  Guidance on securing storage systems, including access control, encryption and the boundaries of provider responsibility.

• ISO/IEC 27040, Storage Security

  International standard covering storage security controls, including considerations for offline and removable media.

• CISA, StopRansomware Guide

  Recommends offline, encrypted backup copies in addition to cloud or immutable backup tiers.

• NCSC, Cloud Security Guidance and Shared Responsibility Principles

  UK guidance on the division of security responsibility between cloud providers and customers.

• NIST SP 1339, Cybersecurity Considerations for Cloud Backup

  Considerations for cloud backup resilience, including identity risk and recovery planning.

Related Firevault guides