# Ensure SQS queues have Server Side Encryption enabled

- Source: https://support.icompaas.com/support/solutions/articles/a_179329222640636-ensure-sqs-queues-have-server-side-encryption-enabled
- 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 server-side encryption (SSE) is enabled on every Amazon SQS queue. With SSE, the bodies of messages are encrypted at rest, either with an AWS Key Management Service (KMS) key (SSE-KMS) or with encryption keys managed by SQS (SSE-SQS). SSE-KMS with a customer-managed key gives the most control over who can use the key.

**Rationale**

Messages often contain secrets, tokens or personal data. Without server-side encryption, message bodies are stored unencrypted at rest and can be exposed through privilege misuse, misconfiguration or unintended integrations. Using SSE-KMS with a customer-managed key adds key-level access control, rotation and an audit trail of key use, and allows access to be revoked by disabling the key.

**Impact**

-   Protects message bodies at rest
    
-   With SSE-KMS, access to messages also requires permission to use the KMS key, and key use is logged in AWS CloudTrail
    
-   With SSE-KMS, producers, consumers and AWS services that send messages to the queue need kms:GenerateDataKey and kms:Decrypt permissions on the key
    
-   SSE-KMS incurs AWS KMS request charges, which can be reduced with the data key reuse period
    

**Default Value**

Queues created after SSE-SQS became the default have SSE-SQS enabled automatically. Older queues, or queues where encryption was turned off, have no server-side encryption.

**Pre-Requisites**

-   IAM permissions: sqs:ListQueues, sqs:GetQueueAttributes and sqs:SetQueueAttributes
    
-   For SSE-KMS with a customer-managed key: a KMS key whose key policy allows the producers, consumers and AWS services that use the queue
    

**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 SQS console and select **Queues**.
    
3.  Select a queue and open the **Encryption** tab.
    
4.  Check that server-side encryption is enabled.
    
5.  Repeat for each queue in each region in use.
    
6.  If encryption is disabled for any queue, follow the implementation steps.
    

**CLI:**

List the queues in a region:

aws sqs list-queues --region <REGION> --query "QueueUrls"

Show the encryption settings of a queue:

aws sqs get-queue-attributes --region <REGION> --queue-url <QUEUE\_URL> --attribute-names KmsMasterKeyId SqsManagedSseEnabled

A queue fails if the output has no KmsMasterKeyId and SqsManagedSseEnabled is not true.

**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 SQS console and select **Queues**.
    
3.  Select the queue and choose **Edit**.
    
4.  Expand the **Encryption** section.
    
5.  Set **Server-side encryption** to **Enabled**.
    
6.  Select the encryption key type:
    
    -   an AWS KMS key (SSE-KMS), choosing alias/aws/sqs or, preferably, a customer-managed key, or
        
    -   an Amazon SQS key (SSE-SQS).
        
7.  Choose **Save**.
    
8.  Repeat for each affected queue in each region in use.
    

**CLI:**

Enable SSE-KMS with a KMS key:

aws sqs set-queue-attributes --region <REGION> --queue-url <QUEUE\_URL> --attributes KmsMasterKeyId=<KMS\_KEY\_ID\_OR\_ALIAS>

Or enable SSE-SQS:

aws sqs set-queue-attributes --region <REGION> --queue-url <QUEUE\_URL> --attributes SqsManagedSseEnabled=true

**Backout Plan**

1.  Sign in to the AWS Management Console at [https://console.aws.amazon.com](https://console.aws.amazon.com/).
    
2.  Open the Amazon SQS console, select **Queues** and select the queue.
    
3.  Choose **Edit** and expand the **Encryption** section.
    
4.  Set **Server-side encryption** back to its previous setting.
    
5.  Choose **Save**.
    

Note: rolling back leaves new messages unencrypted at rest. Keep the KMS key enabled until all messages encrypted with it have been processed.

**Reference**

-   [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-server-side-encryption.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-server-side-encryption.html)
    
-   [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-configure-sse-existing-queue.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-configure-sse-existing-queue.html)
    
-   [https://docs.aws.amazon.com/cli/latest/reference/sqs/set-queue-attributes.html](https://docs.aws.amazon.com/cli/latest/reference/sqs/set-queue-attributes.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.