Summary

  • Backblaze's native Cloud Replication excludes SSE-C files. A buyer cannot assume that separately available features work together.
  • A customer-controlled alternative may still be possible, but its staffing, authority and maintenance belong in the purchase decision.
  • The constraint does not make customer-held keys a poor choice. It makes the organization responsible for explaining how its chosen combination will operate.

Two requirements do not automatically make one service

A storage purchase can satisfy two departments on paper and leave a third with an unpriced job. Security wants the organization to retain its encryption keys. Infrastructure wants a second copy maintained by the storage platform. Each requirement sounds ordinary. The difficulty appears when the buyer asks whether the exact encryption mode belongs in the exact replication service it plans to use.

Backblaze's answer is specific: its documented Cloud Replication feature does not support SSE-C. That is a product-compatibility boundary, not a claim that customers cannot copy their data by any means. It is also not evidence of a recently introduced restriction. This analysis uses the public documentation available on 3 September 2026. Cloud Replication scope.

The commercial consequence comes before any disaster. Someone must select an alternative process, make it work and keep it working. A purchase order for storage does not identify that person. Neither does a security approval that treats key custody as an isolated setting. The storage provider can supply what it documents while a buyer still discovers that the combination it intended to buy requires its own operating layer.

This is where apparently simple cloud procurement becomes an organizational decision. A feature matrix normally rewards the presence of capabilities. It is less good at representing the work created when two capabilities cannot be combined in the preferred way. The missing item is not another checkmark. It is a funded responsibility.

Control has an operating side

With SSE-C, the customer supplies encryption material that Backblaze cannot recover if the customer loses it. This differs from the provider-managed SSE-B2 option. Both are server-side modes; customer custody should not be described as a promise that the supplied key never enters an authorized server-side operation. Encryption responsibilities.

There can be sound reasons to choose the customer-held arrangement. An organization may already have a well-run custody service, a defined separation of duties and applications designed around that responsibility. Its preferred trust model need not be the one that minimizes integration work. Declaring provider-managed keys universally preferable would confuse administrative convenience with the buyer's actual objective.

But control is not exhausted by the decision to keep a secret. It includes continuity of authority: which system may use it, which successor can take over, and which changes require approval. These duties persist when the employee who selected the mode changes jobs or the original application is retired. A low-touch storage relationship can therefore coexist with a high-touch internal custody obligation.

The language of keys can hide a second confusion. Backblaze application keys govern API access and can carry restricted capabilities. They are not the same material as an SSE-C encryption key. Replacing an access credential is not a substitute for preserving the separate decryption requirement. Application-key model.

That distinction has a practical budgeting effect. Access administration may already belong to a cloud team, while encryption custody belongs elsewhere. If the alternative copy process needs both, its operator depends on two continuing grants of authority. Neither team can infer that the other has accepted the whole job merely because a connection test succeeded.

A copying operation is not a managed copying service

Backblaze's copy-file operation provides a useful boundary check. Copying an SSE-C source requires matching source encryption parameters; destination encryption is specified separately. The documented operation is within one account. It is not, by itself, a managed cross-region service. Copy-file requirements.

An organization may build or contract for a different process. The point is not that this necessarily costs more than every alternative. A customer with established software and custody operations may incur little additional effort. A small team starting from a storage-only purchase may face a much larger step. Public documentation does not disclose those customer-specific costs, so neither a universal saving nor a universal penalty can be calculated here.

The work is broader than making a command succeed once. The operator has to decide which data belongs in the second copy, what should happen after an interrupted attempt, and how a change in the source is reflected at the destination. It must also know whether the destination remains under the intended custody policy. These are requirements for a chosen alternative, not assertions that Backblaze supplies or fails to supply an undocumented service.

This creates a different commercial relationship with a managed-service provider. A quote for storage administration can cover accounts, invoices and access without covering the continuing copy process. Conversely, a higher quote may include genuine operating responsibility rather than merely reselling capacity. Buyers need to compare the deliverable: who remains accountable for the second copy after setup is complete?

The old data does not vanish with the old design

A change of architecture introduces a period in which different data cohorts may have different dependencies. Newly produced data can follow one policy while an older archive still requires another. The organization cannot establish that the older obligation has ended by changing the preferred setting for future work.

Version management makes that distinction commercially visible. Backblaze's lifecycle rules govern older stored versions, subject to applicable protection. A successful new copy is not evidence that earlier versions have been removed. Lifecycle behavior.

Nor is keeping a protected version the same as keeping it readable. Object Lock concerns deletion resistance, while ordinary storage charges still apply. That separation is a reason to coordinate retention and custody, not a recommendation to weaken protection or destroy keys. Object Lock boundaries.

The buyer can otherwise retire an operational responsibility too early. An application disappears from the active estate, its support owner moves on, and the archive looks administratively quiet. Yet the purpose of retaining it may still require a usable key and an accountable operator. The continuing liability is organizational even when there is no change in the visible storage service.

Nothing in the evidence establishes that a Backblaze customer has made this mistake, lost data or paid an unjustified bill. The sources establish a service boundary and the conditions around it. The market conclusion is narrower: customer-held encryption and second-copy maintenance should be bought as one designed operating arrangement, with any excluded native capability made explicit. The valuable product is the arrangement the buyer can sustain, not the sum of features it can tick.