Always-on SSE-B2 brings AES-256 encryption at rest to every new upload and destination copy—with no application changes, additional cost, or performance impact.
Security works best when it doesn’t depend on one more checkbox. Starting September 14, 2026, we’re making server-side encryption the automatic baseline for Backblaze B2 Cloud Storage.
Backblaze B2 will automatically encrypt all newly uploaded and copied object data at rest using Server-Side Encryption with Backblaze-managed keys (SSE-B2) and AES-256. The default applies immediately to new buckets. Existing buckets will receive the default gradually; once enabled for a bucket, newly uploaded and copied objects use SSE-B2 automatically. If an application doesn’t specify an encryption method, B2 handles it automatically.
Here’s the TL;DR: You don’t need to update your application, add an encryption header, or turn on a bucket setting. There is no additional charge for SSE-B2 and no impact on upload or download performance. New uploads are encrypted by default, existing objects keep their current encryption state, and SSE-C remains available when you want to provide your own key for an individual object.
Secure by Default, Without Extra Work
SSE-B2 encrypts object data at rest with AES-256 while Backblaze manages the encryption keys. Until now, customers could choose to enable SSE-B2 for a bucket or request it for an individual upload. With always-on encryption, SSE-B2 becomes the baseline for every new upload and destination copy when SSE-C is not explicitly requested.
That means fewer settings to manage, fewer opportunities for configuration drift, and a stronger security baseline across your storage environment. Teams can meet encryption-at-rest requirements without building another check into every application or deployment process. Server-side encryption cannot be disabled for new writes.
For new buckets, the default applies immediately. Existing buckets receive it gradually; once enabled for a bucket, new uploads and destination copies receive SSE-B2 automatically. Buckets already configured for SSE-B2 remain configured as they are, and requests that explicitly use SSE-C continue to use SSE-C.
What This Means for Your Existing Workflows
The best kind of security improvement is one that doesn’t force you to rebuild what already works. Always-on encryption is a behavioral update, not a new API contract. Existing integrations can keep using the same upload, copy, multipart-upload, and download operations they use today. B2 automatically decrypts SSE-B2 data for authorized reads, so the way you access objects does not change either.
See the Default in Action
The important part of these examples is what is missing: Neither upload explicitly requests SSE-B2. After this update, Backblaze applies it automatically.
S3-Compatible API: Upload Without an Encryption Flag
aws s3api put-object \
--profile backblaze \
--endpoint-url https://s3.YOUR-REGION.backblazeb2.com \
--bucket YOUR-BUCKET-NAME \
--key hello.txt \
--body ./hello.txt
There is no --server-side-encryption option in the command. B2 still encrypts the new object with SSE-B2. In S3-compatible responses, that effective encryption is represented as AES256.
aws s3api get-bucket-encryption \
--profile backblaze \
--endpoint-url https://s3.YOUR-REGION.backblazeb2.com \
--bucket YOUR-BUCKET-NAME
# Response includes
"SSEAlgorithm": "AES256"
B2 Native API: Omit the SSE-B2 Header
curl "$UPLOAD_URL" \
-H "Authorization: $UPLOAD_AUTHORIZATION_TOKEN" \
-H "X-Bz-File-Name: hello.txt" \
-H "Content-Type: text/plain" \
-H "X-Bz-Content-Sha1: $SHA1_OF_FILE" \
--data-binary @hello.txt
# Response includes
"serverSideEncryption": {"mode": "SSE-B2", "algorithm": "AES256"}
The request does not include X-Bz-Server-Side-Encryption. The response still reports SSE-B2 with AES256 because it is now the effective default.
Using the S3-Compatible API?
Requests that omit encryption headers receive SSE-B2 automatically, reported through the S3-compatible AES256 value. PutObject, CopyObject, and multipart uploads all use the new default for the destination object. Valid SSE-C headers still take precedence.
Using the B2 Native API?
You can continue to omit SSE-B2 fields and headers. New uploads, large-file uploads, and destination copies use SSE-B2 by default. Applications can still explicitly request SSE-B2, but doing so is no longer necessary to receive encryption at rest.
Using an SDK, CLI, Integration, or the Web Console?
Because the protection is applied by B2, tools that already upload to Backblaze B2 benefit automatically. No special encryption flag, SDK upgrade, CLI update, or integration change is required. The Backblaze web consoles will show SSE-B2 or AES256 as the effective bucket default and continue to display the encryption actually used for each object.
SSE-C Is Still Available
Some organizations need direct control over the key used for a particular object. SSE-C continues to support that workflow. When a request includes valid SSE-C headers, Backblaze uses the customer-provided AES-256 key instead of SSE-B2 for that object.
As before, Backblaze does not retain the customer key. Customers using SSE-C are responsible for protecting and retaining their keys; a lost key cannot be recovered by Backblaze. You can also continue to encrypt data on the client side before uploading it. SSE-KMS is not part of this update.
What About Objects Already Stored in B2?
Always-on encryption is not retroactive. Objects already stored in a bucket keep the encryption state they had when they were written. We are not rewriting customer data in the background or changing the encryption metadata of historical objects.
If you want an older unencrypted object to use SSE-B2, upload it again or create a new destination copy. The new object is encrypted using the always-on default. Object-information and download responses continue to describe the encryption actually used for each object.
Why Always-On Encryption Matters
Encryption at rest is a foundational part of modern data protection. Making it automatic helps teams establish a consistent security baseline without adding another deployment step or relying on every application to make the same configuration choice.
It also keeps the developer experience simple. Teams can focus on moving, protecting, and using their data while Backblaze applies the default protection behind the scenes—with no added encryption charge or performance trade-off. That’s the kind of cloud storage experience we want to deliver: secure by design, straightforward to operate, and compatible with the tools customers already use.
Frequently Asked Questions
No. Applications that omit encryption settings automatically receive SSE-B2 for new uploads and destination copies. Existing request formats remain valid.
No. SSE-B2 is the effective default when SSE-C is not requested. Clearing or deleting an explicit bucket encryption configuration does not create an unencrypted default.
No. Existing objects retain their original encryption state. Uploading or copying an object again creates a new object that uses the always-on default.
Yes. Supply the required SSE-C headers when you upload, copy, or access an SSE-C object. SSE-C takes precedence over the SSE-B2 default for that object.
No. SSE-B2 is applied at no additional charge and has no impact on upload or download performance. Normal Backblaze B2 storage and API charges still apply.
Available Starting September 14, 2026
Always-on SSE-B2 is available on September 14, 2026 for new buckets in every Backblaze B2 region. Existing buckets will be enabled gradually. For most customers, there’s nothing to turn on and nothing to migrate: once the default is enabled for a bucket, every new upload and destination copy receives SSE-B2 automatically unless you explicitly request SSE-C.
Ready to put secure-by-default cloud storage to work? Get started with Backblaze B2 Cloud Storage.
