Amazon S3 SSE-C Default Disable (April 2026): Migration Playbook

In April 2026, Amazon S3 rolled out a default bucket security setting that disables SSE-C (server-side encryption with customer-provided keys) for all new general purpose buckets, and for existing buckets in accounts that had no SSE-C encrypted objects. New SSE-C uploads then fail with HTTP 403 AccessDenied unless you explicitly re-allow SSE-C via PutBucketEncryption (What’s New, FAQ, blocking guide).

This is the migration / audit playbook. It does not repeat the KMS CMK architecture post.

Artifacts: audit checklist, CLI probe script, architecture diagram (draw.io).

What changed (operator view)

When blocked, SSE-C on PutObject / CopyObject / PostObject / multipart / replication returns 403. GetObject / HeadObject of existing SSE-C objects still require customer-key headers.

Figure: writers migrate from customer-provided keys to SSE-KMS; bucket encryption shows BlockedEncryptionTypes SSE-C; legacy objects remain readable with old keys until rewritten. Open draw.io

Opinionated recommendation

Do not re-enable SSE-C for net-new apps. Prefer SSE-KMS when you need key policy, audit, and cross-account grants; SSE-S3 when default protection is enough. Use SSE-C only as a dated exception with an owner and kill date.

SSE-C forces every reader/writer to possess the raw key, which is hostile to IAM roles, Lake Formation grants, and most AWS analytics services.

Audit sequence

1. Account question: Did we ever store SSE-C objects? Inventory encryption columns + CloudTrail x-amz-server-side-encryption-customer-algorithm.
2. Writer hunt: Grep for SSECustomerKey, customer algorithm headers, third-party “client-side key” wrappers that still speak SSE-C to S3.
3. Bucket sample: get-bucket-encryption; look for BlockedEncryptionTypes → SSE-C.
4. Probe: intentional SSE-C PutObject should 403 when blocked (staging buckets only).

# Spot-check encryption config (AWS CLI v2)
aws s3api get-bucket-encryption \
  --bucket amzn-s3-demo-bucket \
  --region us-east-1

Explicit allow (exception path)

If you truly need SSE-C on a new bucket: create the bucket, then call PutBucketEncryption clearing the block (BlockedEncryptionTypes → NONE per FAQ examples). Requires s3:PutEncryptionConfiguration. Document the exception and remove it when the writer migrates.

What to do this week

1. Complete the account-level “any SSE-C objects?” scan.
2. Ticket every upload path that still sets customer-key headers.
3. Migrate those writers to SSE-KMS (or SSE-S3) in staging first.
4. Confirm BlockedEncryptionTypes includes SSE-C on high-risk buckets.
5. Add a CI check that fails if new code introduces SSE-C headers.

What this post doesn’t cover

• Client-side encryption SDKs that never used SSE-C headers (different model)
• Full CMK rotation / key policy design: KMS architecture
• Macie classification of historical SSE-C objects: Macie + Detective
• Directory buckets / S3 Express nuances: verify current docs for those API surfaces

We have not re-tested Middle East (Bahrain/UAE) exceptions after April 2026, so re-read the FAQ before assuming region behavior.

Related: Cloud security · Compliance services · KMS cost traps

Frequently asked questions