# Ensure S3 bucket has server-side encryption with AWS KMS - Source: https://support.icompaas.com/support/solutions/articles/a_1793292247273838-ensure-s3-bucket-has-server-side-encryption-with-aws-kms - Section: [Solutions](https://support.icompaas.com/support/solutions) › [AWS_Checks_v5.39.1](https://support.icompaas.com/support/solutions/c_1793285913477877) › [AWS Checks](https://support.icompaas.com/support/solutions/folders/f_1793287194371224) - Last updated: 2026-10-29 - Publisher: iCompaas, Inc. (https://www.icompaas.com) **Description** Ensure that every Amazon S3 bucket uses server-side encryption with AWS KMS keys as its default encryption. The default encryption type must be SSE-KMS (aws:kms) or dual-layer DSSE-KMS (aws:kms:dsse). Buckets that use the default SSE-S3 encryption (AES256) do not meet this requirement. **Rationale** With SSE-S3 only, encryption keys are fully managed by Amazon S3 and cannot be controlled through key policies or grants. AWS KMS encryption adds a second layer of access control: a user must have permission to use the KMS key as well as to read the object. It also allows keys to be disabled or rotated, and records every key use in AWS CloudTrail, which helps detect misuse. A customer managed key with least-privilege access should be used, and S3 Bucket Keys can be enabled to reduce KMS costs. **Impact** - Adds key-based access control and CloudTrail audit records for object encryption and decryption - The new default applies only to objects uploaded after the change; existing objects keep their current encryption until they are copied or re-uploaded - Users, roles and services that read the bucket need kms:Decrypt permission on the key, and cross-account access requires a customer managed key - KMS requests add cost, which can be reduced by enabling S3 Bucket Keys **Default Value** Since January 2023, all S3 buckets have default encryption with Amazon S3 managed keys (SSE-S3, AES256). KMS encryption is not enabled by default. **Pre-Requisites** - IAM permissions: s3:ListAllMyBuckets, s3:GetEncryptionConfiguration and s3:PutEncryptionConfiguration - If a customer managed key is used: a KMS key in the same region as the bucket, with a key policy that allows the users and services that read and write the bucket - A list of the applications and accounts that access the bucket, to confirm they have permission to use the key **Remediation** **Test Plan** **Console:** 1. Sign in to the AWS Management Console at [https://console.aws.amazon.com](https://console.aws.amazon.com/). 2. Open the Amazon S3 console and select a bucket. 3. Open the **Properties** tab and find the **Default encryption** section. 4. Check that **Encryption type** is **Server-side encryption with AWS Key Management Service keys (SSE-KMS)** or **Dual-layer server-side encryption with AWS Key Management Service keys (DSSE-KMS)**. 5. Repeat for each bucket. 6. If any bucket uses SSE-S3 or has no default encryption, follow the implementation steps. **CLI:** Show the default encryption type of a bucket: aws s3api get-bucket-encryption --bucket --query "ServerSideEncryptionConfiguration.Rules\[0\].ApplyServerSideEncryptionByDefault.SSEAlgorithm" --output text A bucket fails if the result is not aws:kms or aws:kms:dsse, or if no encryption configuration is found. **Implementation Steps** **Console:** 1. Sign in to the AWS Management Console at [https://console.aws.amazon.com](https://console.aws.amazon.com/). 2. Open the Amazon S3 console and select the bucket. 3. Open the **Properties** tab and, in **Default encryption**, choose **Edit**. 4. Select **Server-side encryption with AWS Key Management Service keys (SSE-KMS)**. 5. Choose the AWS managed key (aws/s3) or a customer managed key. 6. Under **Bucket Key**, select **Enable** to reduce KMS costs. 7. Choose **Save changes**. 8. Repeat for each affected bucket. **CLI:** Set SSE-KMS with the AWS managed key as the bucket's default encryption: aws s3api put-bucket-encryption --bucket --server-side-encryption-configuration '{"Rules":\[{"ApplyServerSideEncryptionByDefault":{"SSEAlgorithm":"aws:kms"},"BucketKeyEnabled":true}\]}' To use a customer managed key instead: aws s3api put-bucket-encryption --bucket --server-side-encryption-configuration '{"Rules":\[{"ApplyServerSideEncryptionByDefault":{"SSEAlgorithm":"aws:kms","KMSMasterKeyID":""},"BucketKeyEnabled":true}\]}' **Backout Plan** Before making changes, save the current encryption settings: aws s3api get-bucket-encryption --bucket > bucket-encryption-backup.json To roll back: 1. Sign in to the AWS Management Console at [https://console.aws.amazon.com](https://console.aws.amazon.com/). 2. Open the Amazon S3 console and select the bucket. 3. Open the **Properties** tab and, in **Default encryption**, choose **Edit**. 4. Select the previous encryption type from the saved backup, for example **Server-side encryption with Amazon S3 managed keys (SSE-S3)**. 5. Choose **Save changes**. **CLI:** aws s3api put-bucket-encryption --bucket --server-side-encryption-configuration '{"Rules":\[{"ApplyServerSideEncryptionByDefault":{"SSEAlgorithm":"AES256"}}\]}' Note: objects uploaded while KMS encryption was the default stay encrypted with the KMS key, so the key must not be disabled or deleted while those objects are needed. **Reference** - [https://docs.aws.amazon.com/AmazonS3/latest/userguide/default-bucket-encryption.html](https://docs.aws.amazon.com/AmazonS3/latest/userguide/default-bucket-encryption.html) - [https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingKMSEncryption.html](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingKMSEncryption.html) - [https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucket-key.html](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucket-key.html) - [https://docs.aws.amazon.com/cli/latest/reference/s3api/put-bucket-encryption.html](https://docs.aws.amazon.com/cli/latest/reference/s3api/put-bucket-encryption.html) ## Related compliance guidance - [SOC 2 compliance: a practical implementation guide for cloud-native SaaS teams](https://support.icompaas.com/compliance/soc-2-trust-services-criteria): Configuration checks like this one are the technical half of a SOC 2 / ISO 27001 programme — the guide shows where they fit, what else an auditor expects, and how to evidence them. - [ISO/IEC 27001:2022 compliance: a practical implementation guide](https://support.icompaas.com/compliance/iso-27001-2022): ISO 27001 Annex A.8 (technological controls) is where cloud hardening evidence lands; the guide shows how to run the ISMS around it.