Backblaze B2 encryption will leave older objects unchanged
Backblaze B2 will make encryption automatic for new uploads and copies starting September 14, 2026, but the change will not encrypt older data already in storage. In its August 27 announcement, Backblaze said the default will apply to new buckets, the containers used to organise stored files, in every B2 region at launch. Existing buckets will receive it gradually, so the important question for their owners is when their particular bucket has been enabled.
The change uses Server-Side Encryption with Backblaze-managed keys (SSE-B2), meaning the storage provider encrypts the data and manages the keys needed to read it. It protects object data, the files held in cloud object storage, using AES-256, the Advanced Encryption Standard with 256-bit keys. This is encryption at rest, protection for data while it is stored. Backblaze says the change requires no application modifications, adds no encryption charge and has no effect on upload or download performance. Normal storage and application programming interface (API) charges still apply; an API is the interface software uses to request operations from a service.
Previously, customers could enable SSE-B2 for a bucket or request it for a particular upload. Once the new default reaches a bucket, every new upload and destination copy receives SSE-B2 unless the request explicitly selects SSE-C, server-side encryption using a customer-provided key. Buckets already configured for SSE-B2 keep their configuration. Server-side encryption cannot be switched off for new writes after enablement: clearing or deleting an explicit bucket encryption setting will not restore an unencrypted default.
That removes a configuration choice from each application and deployment process. The transferable benefit is consistency: stored-data protection no longer depends on every uploading tool remembering to request it, and there are fewer settings that can diverge over time. The boundary matters just as much, however. An automatic default for future data is not evidence that every historical file has the same protection.
Backblaze describes this as a change in behaviour rather than a change to the API contract, the rules governing software requests and responses. Existing upload, copy, download and multipart-upload operations, which send a file in separate pieces, remain valid. B2 automatically decrypts SSE-B2 objects for authorised reads, so applications retrieve files as before. The rollout also adds support for SSE-B2-encrypted files to B2 Snapshots and downloads through the Backblaze web console, without requiring users to change those workflows.
For developers using the S3-Compatible API, an interface compatible with Amazon S3 storage requests, uploads without encryption headers automatically receive SSE-B2. Headers are extra instructions attached to a request. Backblaze says PutObject, CopyObject and multipart uploads all apply the default to the destination object, while valid SSE-C headers take priority. The S3-compatible representation of the encryption is AES256. In Backblaze's command-line example, an aws s3api put-object upload uses a profile, regional endpoint, bucket, object name and local file but omits --server-side-encryption. Its separate aws s3api get-bucket-encryption example reports "SSEAlgorithm": "AES256".
The B2 Native API, Backblaze's own request interface, follows the same principle. Applications may omit SSE-B2 fields and headers for ordinary uploads, large-file uploads and destination copies. Backblaze's curl example, using a command-line tool for sending web requests, includes authorisation, the file name, content type and a SHA-1 checksum, a value used to check file integrity. It leaves out X-Bz-Server-Side-Encryption, yet the response reports serverSideEncryption with mode SSE-B2 and algorithm AES256. Explicitly requesting SSE-B2 remains supported but is no longer necessary to obtain encryption at rest once the default is active.
Because B2 applies the protection, existing software development kits (SDKs), collections of code for connecting applications to a service, and command-line interfaces (CLIs), tools operated through typed commands, need no upgrade for this change. Existing integrations need no special encryption flag either. Backblaze says its web consoles will display SSE-B2 or AES256 as the effective bucket default while continuing to show the encryption actually used by each object. This distinction helps users avoid confusing a bucket's current default with the condition of older files inside it.
Customer-controlled keys remain an option. A request carrying valid SSE-C headers uses the supplied AES-256 key instead of Backblaze-managed encryption for that object. Customers must supply the required headers when uploading, copying or accessing SSE-C objects. Backblaze does not retain those keys and cannot recover a lost one, leaving customers responsible for protecting and retaining them. Encrypting data on the client side, before it is uploaded, also remains possible. SSE-KMS, server-side encryption integrated with a key management service, is not included in this update.
For existing data, nothing changes retroactively. Backblaze says it will neither rewrite stored customer files in the background nor change historical encryption metadata, the descriptive information recording how an object is protected. Older objects retain the state they had when written. To give an older unencrypted object SSE-B2 protection, upload it again or create a new destination copy after the bucket's default is enabled. Object-information and download responses will continue to describe the encryption actually used for that particular object.
For businesses considering managed infrastructure, AEU Data's European cloud and data-infrastructure services include managed databases, backups and encrypted storage, capabilities relevant to protecting stored business data. The practical lesson from Backblaze's rollout is to verify both the active default and the protection of existing files: a stronger setting for tomorrow's uploads does not, by itself, change yesterday's data.