Backblaze B2 makes AES-256 encryption at rest the default on every new upload
On August 27, 2026, Backblaze announced that SSE-B2 will automatically encrypt every new object with AES-256 starting September 14, at no extra cost and with no API changes. For self-hosters who back up to B2, encryption at rest stops being a checkbox you have to remember.
August 27, 2026. Backblaze published a post announcing that SSE-B2, its server-side encryption with Backblaze-managed keys, becomes the default behavior. September 14, 2026. That is the date the change takes effect. AES-256. That is the algorithm applied to every new object, with no added cost and no measurable performance impact. Why it matters: a large share of self-hosters who back up to Backblaze B2 never turned on encryption at rest, because it required remembering to do it. This default removes the forgetting.
Encryption at rest without a checkbox
Until now SSE-B2 was opt-in. A customer could enable it on a bucket or request it per upload, but nothing forced the choice. The result is a storage estate where some buckets are encrypted at rest and others are not, depending on each project’s history and how careful the person who created the bucket happened to be.
Starting September 14, 2026, Backblaze inverts the logic. Every newly uploaded or copied object is encrypted automatically with SSE-B2 and AES-256, whether the application asks for it or not. Encryption at rest becomes the baseline rather than the exception. New buckets get the behavior immediately; existing buckets are rolled over gradually, and once a bucket has switched, all of its new objects land under SSE-B2.
The central point is that nothing changes on the application side. No header to add, no bucket setting to flip, no extra charge, and no upload or download throughput penalty. Backblaze describes it as a behavioral update rather than a new API contract.
What actually changes for S3 integrations
Backblaze B2 is S3-compatible object storage, and that interface is what most self-hosted backup tools talk through: restic, rclone, Duplicati, or Borg pushed to a remote via rclone. All of these speak the S3 protocol without necessarily specifying server-side encryption.
Under the new default, a PutObject that sends no encryption header still receives SSE-B2. In S3-compatible responses, that effective encryption is represented by the value AES256. The example Backblaze published leaves no ambiguity: an aws s3api put-object command with no --server-side-encryption option produces an encrypted object.
aws s3api put-object \
--profile backblaze \
--endpoint-url https://s3.YOUR-REGION.backblazeb2.com \
--bucket YOUR-BUCKET-NAME \
--key hello.txt \
--body ./hello.txt
# No encryption flag: the object is still encrypted with SSE-B2 (AES256)The native B2 API follows the same logic: an upload that omits the X-Bz-Server-Side-Encryption header gets a response containing "serverSideEncryption": {"mode": "SSE-B2", "algorithm": "AES256"}. Existing objects keep their current encryption state — Backblaze does not retroactively re-encrypt data that is already stored.
What SSE-B2 does not solve, and why SSE-C remains
Be precise about what this default covers. SSE-B2 encrypts data at rest with keys managed by Backblaze. That satisfies the classic requirement for encrypting backups stored at a third party, and it closes the gap of the bucket left in cleartext. It does not replace end-to-end encryption: if you want Backblaze to be unable to read your objects at all, you must supply your own keys.
That is exactly what SSE-C does — server-side encryption with customer-provided keys. It remains available and keeps priority: an upload that specifies SSE-C continues to use SSE-C rather than falling back to SSE-B2. For a self-hoster the decision rule is simple. If your threat model demands that the provider never sees your backup contents, encrypt client-side with restic, rclone crypt, or Borg before sending, and keep SSE-C for objects where you want key control at the object level. Otherwise the SSE-B2 default is already a clear improvement over the previous state.
Why it matters to the self-hosted
The dominant B2 use case in the self-hosted community is offsite backup. You run services on Proxmox or a NAS and push encrypted snapshots to B2 to honor the 3-2-1 rule without managing a second physical site. B2’s at-rest encryption was technically available, but in practice many installs never enabled it, either out of ignorance or because the backup tool did not expose the option.
In concrete terms, nothing changes for the tools that target B2 through its S3 interface. restic, rclone, Duplicati, or a Proxmox Backup Server pointed at S3-compatible storage keep sending their objects without specifying a server-side encryption method, and B2 now encrypts by default. The one case where action was already in place — a tool that explicitly sent the SSE-B2 header — keeps working identically: the explicit request and the default land on the same result. For anyone maintaining a mix of encrypted and unencrypted buckets, the default is also a chance to normalize: over time everything entering B2 is encrypted, and the question stops being asked bucket by bucket.
By making encryption automatic, Backblaze removes a configuration decision from the chain. The result is a stronger security baseline with zero extra effort, and an immediate answer to auditors who ask “are your backups at the third party encrypted at rest?”. It is also a competitive move: on this criterion B2 now lines up with the big clouds that encrypt by default, while remaining substantially cheaper for large volumes.
For context, this matches the posture of Amazon S3, which has encrypted new objects with SSE-S3 by default since 2023, and of the other major object stores that quietly made encryption the baseline. B2 was one of the last large S3-compatible targets where the default was still cleartext. Closing that gap matters less for the provider and more for the self-hoster, whose auditors increasingly treat default-at-rest encryption as table stakes rather than a point of differentiation — and who would rather have the provider carry that burden than wire it into every backup job by hand.
What to verify after September 14
The rollout is gradual for existing buckets, which opens a window where two neighboring buckets can behave differently. The way to know whether a bucket has switched to the new default is to query its encryption configuration: over the S3-compatible API, a get-bucket-encryption returns SSEAlgorithm: AES256 once the switch is effective; over the native B2 API, an upload response carries the serverSideEncryption field with mode SSE-B2 and algorithm AES256.
For a self-hoster who drives backups from scripts, this deserves a check rather than blind trust. One test after the effective date is enough: upload an object with no encryption header, then read back its metadata to confirm SSE-B2 was applied. It is the kind of verification an auditor will ask for, and the answer fits in a single command.
# Verify the default encryption is active on a bucket
aws s3api get-bucket-encryption \
--profile backblaze \
--endpoint-url https://s3.YOUR-REGION.backblazeb2.com \
--bucket YOUR-BUCKET-NAME
# Expected after switchover: "SSEAlgorithm": "AES256"It is also worth remembering a limit of the default: SSE-B2 covers newly written objects, not those written before the switch. On an older bucket, historical data stays in the state it was written in. If compliance requires an entire bucket to be encrypted, the migration is to re-copy the objects via CopyObject, an operation that applies the new default to the destination.
Verdict
If you already back up to B2, there is nothing to do: the switch is transparent, free, and carries no measured performance impact. Just verify after September 14 that new objects report AES256 or SSE-B2 in responses, and keep SSE-C for objects you must encrypt with your own keys.
If you already encrypt client-side with restic, rclone crypt, or Borg, this default adds an at-rest layer that costs nothing and creates no conflict: your keys stay yours, and B2 additionally encrypts what it stores.
If you are comparing backup targets, note that B2 just removed one of the last criticisms it faced against hyperscalers, without touching its price. Encryption at rest is no longer a point of differentiation.