Advanced notice: Amazon S3 to disable the use of SSE-C encryption by default for all new buckets and select existing buckets in April 2026

Starting on April 6, 2026, we will be changing how server-side encryption with customer-provided keys (SSE-C) is enabled for Amazon S3 buckets. With this change, SSE-C will be disabled by default on all new S3 general purpose buckets. Furthermore, SSE-C will also be disabled for all existing buckets in Amazon Web Services (AWS) Accounts that do not have any SSE-C encrypted data. This change will start on April 6, 2026 and will be rolled out to all AWS Regions within weeks.

When this change has been rolled out to a Region, all new buckets in the Region will have SSE-C encryption disabled. With this change, the few applications that need SSE-C encryption must enable the use of SSE-C on the desired buckets through the PutBucketEncryption API and then continue to include the necessary SSE-C request headers to their PutObject requests. As a result of this change, you may need to update automation scripts, AWS CloudFormation templates, or other infrastructure configuration tools to ensure that SSE-C is enabled on new or existing buckets where your workflows use it. Moreover, if your account does not have any SSE-C encrypted objects, then you will also see this encryption type disabled for your existing buckets. If you have SSE-C encrypted objects in any of your buckets in an account, then all your existing buckets will continue to support SSE-C encryption.

Amazon S3 added support for SSE-C encryption in June 2014 to provide customers with control over when encryption keys could be used. Just months later in November 2014, the AWS Key Management Service (AWS KMS) launched with the capability to encrypt S3 data with SSE-KMS encryption. With the launch of AWS KMS, there was no longer a practical security benefit to use SSE-C because customer-managed keys in AWS KMS provide encryption keys that you create, own, and manage. Furthermore, you can use AWS KMS keys to define granular key and AWS Identity and Access Management (IAM) policies for the specific conditions, services, and principals that can perform key operations. SSE-KMS encryption also supports logging key operations in AWS CloudTrail to give customers insight into the users, roles, and AWS services using their encryption keys.

Today, hundreds of thousands of customers use SSE-KMS to encrypt their S3 data while using AWS data analytics, AI and machine learning (ML) applications, media tools, or other cloud-native services that integrate with AWS KMS to realize new insights into their data. When using SSE-KMS, customers can update AWS KMS key policies or IAM policies to control which users, roles, or AWS services can access the keys needed to decrypt their encrypted S3 data. This access to encryption keys can be updated whenever you want without having to share the actual encryption keys with the entities that need to use them. However, S3 does not store the encryption key when you use SSE-C, thus this design forces you to supply the encryption key every time you want anyone to download your SSE-C encrypted data from S3.

SSE-C’s requirement to provide the encryption key each time you interact with your SSE-C encrypted data makes it impractical to share your SSE-C key with other users, roles, or AWS services that you want to read data from your S3 buckets in order to operate on your data. Due to the widespread support for SSE-KMS across AWS, most modern workloads do not use SSE-C encryption because it lacks the flexibility of SSE-KMS. Therefore, to streamline the encryption options that customers need to consider, we are disabling SSE-C encryption for all new and most existing buckets, necessitating that you explicitly enable the use of SSE-C encryption if needed.

For situations where you have unique encryption requirements that SSE-KMS doesn’t meet, you may want to evaluate client-side encryption. For example, if you wanted to encrypt specific column chunks in a parquet file under different encryption keys, SSE-KMS can’t support this because each entire parquet object is encrypted under a single unique encryption key. To accomplish encrypting data with different keys inside a single object, you would use client-side encryption to encrypt the column chunks with the desired encryption keys, then assemble your object and upload it to S3. AWS offers the open source AWS Encryption SDK and S3 Encryption Client libraries to help with your client-side encryption needs, and you can use either AWS KMS or your own key management solutions to manage the keys.

What’s changing

In this section we take a closer look at the change that we are making by showing the response to a GetBucketEncryption API call to a new bucket after the change is deployed in April. All new buckets will now have SSE-C as BlockedEncryptionType by default.

HTTP/1.1 200 OK
            x-amz-id-2: kDmqsuw5FDmgLmxQaUkd9A4NJ/PIiE0c1rAU/ue2Yp60toXs4I5k5fqlwZsA6fV+wJQCzRRwygQ=
            x-amz-request-id: 5D8706FCB2673B7D
            Date: Mon, 6 Apr 2026 12:00:00 GMT
            Transfer-Encoding: chunked
            Server: AmazonS3
            <ServerSideEncryptionConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
             <Rule>
               <ApplyServerSideEncryptionByDefault>
                   <SSEAlgorithm>aws:kms</SSEAlgorithm>
                   <KMSKeyID>arn:aws:kms:us-east-1:123456789012</KMSKeyID>
               </ApplyServerSideEncryptionByDefault>
               <BlockedEncryptionTypes>
                    <EncryptionType>SSE-C</EncryptionType> 
               </BlockedEncryptionTypes>             
             </Rule>
            </ServerSideEncryptionConfiguration>

A subsequent attempt to upload an object with SSE-C encryption specified will be rejected with an HTTP 403 Access Denied error. If you need to use SSE-C encryption with a new bucket, then you can create it as usual and update the bucket’s Default Encryption settings by calling the PutBucketEncryption API. You will need the s3:PutEncryptionConfiguration permission to call this function. Read Blocking or unblocking SSE-C for a general purpose bucket to learn more about the function and the permissions.

If you want to review if you’re using SSE-C encryption in any of your buckets, then you can use tools such as CloudTrail to monitor access to your data. This AWS Storage Blog post shows you how to audit encryption methods for object uploads in real-time. You can also reference this re:Post article to guide you through the querying S3 Inventory reports to see if you have any SSE-C encrypted objects.

Stay tuned

We will publish a What’s New post when we start to deploy this change on April 6th, 2026.