S3 disables SSE-C by default on new buckets: what changes and what to check

A default setting, when it changes, can go unnoticed until something stops working. That’s the case with an update Amazon Web Services (AWS) began rolling out in April 2026 for its S3 storage service: encryption with a customer-provided key, known as SSE-C, is no longer active by default on new buckets. A bucket is the basic container in which S3 keeps files, which in the service’s jargon are called objects, the same concept reused by the more recent vector buckets for semantic search. For most people using S3, nothing changes. But anyone with automation or applications that rely on SSE-C has good reason to check their configurations before the change reaches everywhere.

What SSE-C is, and where it fits

S3 offers server-side encryption: data is encrypted automatically when it’s written to disk and decrypted on read, without the application having to deal with it. The difference between the variants comes down to a single question: who owns and manages the key.

SSE-S3 - the key is generated and managed by AWS. It’s the simplest option and the default.
SSE-KMS - the key lives in AWS Key Management Service (KMS), the dedicated key-management service. In exchange you get fine-grained access controls through IAM policies (AWS’s permission system) and a record of every use of the key in CloudTrail, the account’s activity log, a level of traceability that lines up well with the accountability required under GDPR.
SSE-C - the key is supplied by the customer, and sent to S3 with every write and read request. S3 uses it to encrypt or decrypt on the fly, but never stores it anywhere. Control of the key stays entirely with whoever produces it.

That last point is what makes SSE-C distinctive: because S3 doesn’t store the key, without it the data can’t be read, not even on AWS’s side. It’s a strong guarantee, but also a heavy operational constraint.

What actually changes

The update concerns general purpose buckets, the standard kind used in the vast majority of cases.

New buckets: SSE-C is disabled by default. Every bucket created after the rollout starts with SSE-C blocked.
Existing buckets: it depends on the account. If the account contains no SSE-C-encrypted objects, S3 disabled SSE-C on the existing buckets too. If even a single bucket in the account holds SSE-C objects, S3 left every configuration in that account untouched, so as not to break what’s in use.
Timing and Regions: the rollout began in April 2026 and reached 37 AWS Regions, including the AWS China and AWS GovCloud (US) Regions. The Middle East (Bahrain) and Middle East (UAE) Regions are an exception, at least for now, where the new default doesn’t apply. The change didn’t come out of nowhere: AWS published an advance notice back in November 2025.

It’s worth stressing that this is a real, already-live change, not a beta or a proposal: the default really did change.

Why AWS is doing it

The stated rationale is that SSE-C, today, offers little advantage over the alternatives. Because S3 doesn’t keep the key, it has to be resent with every single request: sharing access to the data with other users or services becomes awkward, and it lacks the traceability KMS provides naturally through IAM and CloudTrail. Ever since KMS arrived - letting you create, own and manage keys with access controls and usage logging - the practical benefit of SSE-C has effectively thinned out, and most modern workloads have stopped using it.

The change of default is therefore best read as a secure-by-default choice: turning off a rarely used feature reduces the surface where configuration mistakes can arise, while still leaving those who genuinely need it the option to turn it back on.

What happens to anyone still using SSE-C

On a bucket where SSE-C is blocked, any request that explicitly asks for SSE-C is rejected with an HTTP 403 AccessDenied error, in other words an “access denied”. This covers uploads (PutObject), copies (CopyObject), PostObject requests, multipart uploads and cross-bucket replication.

For an application that expects to write with SSE-C, this shows up as a sudden and potentially widespread failure. Hence the value of noticing it in advance, as a planned check rather than a production incident.

What to verify first

It helps to work through two questions, in order.

First question: is SSE-C used anywhere? It isn’t always obvious, especially in automation written a while ago. To find out, you can look in CloudTrail at which encryption methods appear in requests to S3, and use S3 Inventory reports to list objects already encrypted with SSE-C. To check the encryption configuration of a single bucket, you can query the API with a read-only command:

aws s3api get-bucket-encryption --bucket your-bucket-name

Second question: if SSE-C is genuinely needed, how do you turn it back on? On a new bucket it has to be enabled explicitly by calling the PutBucketEncryption API (which requires the s3:PutEncryptionConfiguration permission), after which applications keep including the usual SSE-C headers in their requests. The same API also handles the bucket-level setting introduced for this change, which lets you block or unblock SSE-C in a controlled way, bucket by bucket.

For anyone who discovers they still depend on SSE-C, this is also a good moment for a more fundamental question: does that data really need a key managed outside AWS, or would SSE-KMS cover the need while adding traceability and access controls? The answer varies case by case, but it’s worth asking now, calmly, rather than in front of a failed upload.

In short

The operational message is simple. The change is already rolling out, was announced months ahead, and for most users is transparent, while nudging toward a more cautious default. For anyone who invested in SSE-C - often in pipelines or scripts no one has looked at in a while - the task is clear: find where SSE-C is in use, decide whether it still makes sense or whether switching to SSE-KMS is better, and where needed re-enable it explicitly on the right buckets before the updated default makes a write fail, exactly the way you’d test a restore before you actually need it.

# S3 disables SSE-C by default on new buckets: what changes and what to check