--- title: Amazon S3 SSE-C Default Disable (April 2026): Migration Playbook description: After the April 2026 S3 default that blocks SSE-C on new buckets (and on existing buckets in accounts with zero SSE-C objects), a SaaS media platform (~2.4 PB, 418 buckets) found 11 legacy upload paths still sending customer-key headers — all failing 403 until migrated to SSE-KMS. url: https://www.factualminds.com/blog/amazon-s3-sse-c-default-disable-migration-playbook-2026/ datePublished: 2026-07-08T00:00:00.000Z dateModified: 2026-07-08T00:00:00.000Z author: palaniappan-p category: Security & Compliance tags: aws, amazon-s3, encryption, sse-c, sse-kms, security --- # Amazon S3 SSE-C Default Disable (April 2026): Migration Playbook > After the April 2026 S3 default that blocks SSE-C on new buckets (and on existing buckets in accounts with zero SSE-C objects), a SaaS media platform (~2.4 PB, 418 buckets) found 11 legacy upload paths still sending customer-key headers — all failing 403 until migrated to SSE-KMS. **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](https://aws.amazon.com/about-aws/whats-new/2026/04/s3-default-bucket-security-setting/), [FAQ](https://docs.aws.amazon.com/AmazonS3/latest/userguide/default-s3-c-encryption-setting-faq.html), [blocking guide](https://docs.aws.amazon.com/AmazonS3/latest/userguide/blocking-unblocking-s3-c-encryption-gpb.html)). This is the **migration / audit playbook**. It is **not** a remake of [KMS CMK architecture](/blog/aws-kms-encryption-architecture-cmk-strategy-2026/). Artifacts: [audit checklist](https://www.factualminds.com/examples/architecture-blog-2026/s3-sse-c-migration-playbook/sse-c-audit-checklist.md), [CLI probe script](https://www.factualminds.com/examples/architecture-blog-2026/s3-sse-c-migration-playbook/audit-ssec-inventory.sh), [architecture diagram (draw.io)](https://www.factualminds.com/examples/architecture-blog-2026/s3-sse-c-migration-playbook/s3-sse-c-migration-architecture.drawio). > **First-party benchmark silhouette** — **SaaS media platform**, **~2.4 PB**, **418 buckets**, multi-account. Inventory + CloudTrail scan after the April rollout found **11 upload paths** (mobile SDK + 2 ETL jobs) still attaching SSE-C headers. Those paths began returning **403** on buckets that received the default block. Cutover to **SSE-KMS CMKs** cleared errors in **4 engineer-days**; remaining SSE-C objects kept readable-with-key until a cold archive rewrite. ## What changed (operator view) | Account state before April 2026 | Existing buckets | New buckets | | ------------------------------- | ------------------------ | ---------------------------- | | No SSE-C objects anywhere | SSE-C writes **blocked** | SSE-C **blocked** by default | | Any SSE-C object in the account | Config **unchanged** | SSE-C **blocked** by default | When blocked, SSE-C on `PutObject` / `CopyObject` / `PostObject` / multipart / replication → **403**. `GetObject` / `HeadObject` of **existing** SSE-C objects still require customer-key headers. ![S3 SSE-C block default with SSE-KMS migration path](../../assets/images/blog/amazon-s3-sse-c-default-disable-migration-playbook-2026.webp) _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](https://www.factualminds.com/examples/architecture-blog-2026/s3-sse-c-migration-playbook/s3-sse-c-migration-architecture.drawio)_ ## 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 — 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). ```bash # Spot-check encryption config (AWS CLI v2) aws s3api get-bucket-encryption \ --bucket amzn-s3-demo-bucket \ --region us-east-1 ``` > **Reproduce this** — Run [audit-ssec-inventory.sh](https://www.factualminds.com/examples/architecture-blog-2026/s3-sse-c-migration-playbook/audit-ssec-inventory.sh) per critical bucket, then work the [sse-c-audit-checklist.md](https://www.factualminds.com/examples/architecture-blog-2026/s3-sse-c-migration-playbook/sse-c-audit-checklist.md) with security + platform owners. > **What broke** — Day after rollout. A partner integrator still used SSE-C on a **new** logging bucket. Uploads returned **403 AccessDenied**; on-call assumed IAM regression. **Root cause:** default `BlockedEncryptionTypes`. **Fix:** switched integrator to SSE-KMS; did **not** clear the block. **Lesson:** treat 403 + SSE-C headers as the new default, not an IAM mystery. ## 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](/blog/aws-kms-encryption-architecture-cmk-strategy-2026/) - **Macie classification of historical SSE-C objects** — [Macie + Detective](/blog/aws-macie-detective-data-security-investigation/) - **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 — re-read the FAQ before assuming region behavior. **Related:** [Cloud security](/services/aws-cloud-security/) · [Compliance services](/services/cloud-compliance-services/) · [KMS cost traps](/blog/aws-kms-pricing-keys-requests-multi-region/) ## FAQ ### Did AWS change encryption on every existing bucket? Only if the account had no SSE-C encrypted objects — then existing buckets had SSE-C disabled for new writes. If any bucket in the account already held SSE-C objects, AWS left existing bucket configs alone; new buckets still default to SSE-C blocked. ### When should we NOT re-enable SSE-C on a new bucket? Almost always. Prefer SSE-S3 or SSE-KMS. Re-enable SSE-C only when a validated legacy integration cannot move yet — and treat that as a time-boxed exception with an owners list. ### What breaks when SSE-C is blocked? PutObject, CopyObject, PostObject, multipart upload, and replication requests that specify SSE-C return HTTP 403 AccessDenied. Existing SSE-C objects remain readable if the caller still supplies the customer key headers. ### Which regions got the default? AWS documents completion across 37 regions including China and GovCloud in April 2026. FAQ notes newly created buckets default-disable in all regions except Middle East (Bahrain) and Middle East (UAE) at publication time — verify current FAQ before change windows. ### How is this different from the KMS architecture post? The KMS post designs CMK strategy and request quotas. This playbook handles the April 2026 S3 default change: finding SSE-C debt and choosing block vs explicit allow. ### Do we need s3:PutEncryptionConfiguration? Yes — changing BlockedEncryptionTypes via PutBucketEncryption requires s3:PutEncryptionConfiguration. Audit which roles in CI can flip that setting. --- *Source: https://www.factualminds.com/blog/amazon-s3-sse-c-default-disable-migration-playbook-2026/*