BucketDeskSSE-C in AWS S3: how customer-provided keys work
SSE-C makes you send the encryption key with every S3 request. AWS never keeps it, so a lost key means lost files. When it fits, and what it breaks.
SSE-C gives you the strongest key custody in Amazon S3: you send the key with every request, AWS keeps only an HMAC, and nobody, including AWS, can decrypt the files without you. It also means a lost key is lost data, the S3 console cannot open the files, and every tool and presigned URL needs the key. Use SSE-C only when a requirement forbids the provider from holding keys, and keep files your team works with on SSE-KMS with a customer-managed key.
An auditor asks for proof that your cloud provider cannot decrypt your data, even under a subpoena. SSE-C in AWS S3 (Server-Side Encryption with Customer-Provided Keys) is the encryption type built for that requirement: you send a 256-bit key with every upload and download, Amazon S3 uses it for that one request, and AWS never stores it.
That control has a price. AWS cannot recover a lost SSE-C key, the S3 console cannot open SSE-C objects, and every person or tool that reads a file needs the key in hand. This guide covers how SSE-C works, when it beats SSE-KMS, and what it breaks for teams that need to browse and share files.
How SSE-C AWS encryption works
SSE-C is an Amazon S3 encryption mode in which the caller supplies the encryption key on every request. Each upload (PUT) and download (GET) carries a 256-bit, base64-encoded key in its HTTP headers. S3 uses that key to encrypt the object with AES-256 on write and to decrypt it on read.
AWS does not store the key in any service or metadata field. After the request completes, S3 removes the key from memory. The cloud environment never holds a persistent copy of the secret that protects the data.
Three headers carry the key on every request: x-amz-server-side-encryption-customer-algorithm, x-amz-server-side-encryption-customer-key and x-amz-server-side-encryption-customer-key-MD5. The MD5 header is a checksum of the key that lets S3 confirm the key arrived intact.
Why AWS cannot recover a lost SSE-C key
S3 keeps only a salted HMAC (Hash-based Message Authentication Code) of each SSE-C key. The HMAC is a fingerprint that verifies future requests, and it cannot be reversed to rebuild the key.
On a GET request, S3 checks the key you send against that HMAC. If it matches, S3 decrypts the object, returns it and discards the key. If it does not match, S3 refuses the request.
There is no administrative bypass. AWS Support cannot reset an SSE-C key or grant emergency access, because AWS never had the key. If your copy of the key is deleted or corrupted, the objects it encrypted are permanently unreadable.
SSE-KMS works differently. AWS KMS stores and manages the key, and IAM and key policies decide who may use it. An administrator who loses local credentials still has a way back in, because the key lives in KMS.
SSE-C vs SSE-KMS vs SSE-S3: which to choose
Choose SSE-C only when a compliance framework forbids the cloud provider from ever holding the key. Choose SSE-KMS when you want your own key, a key policy you control and CloudTrail records of every key use. Choose SSE-S3 when bucket permissions are the whole story.
SSE-C moves key storage, rotation and the mapping of keys to objects into your own system. Your application must track which key encrypted which object version and fetch that key for every request. That key store has to be as durable as S3 itself, or a vault outage becomes a data outage.
Since April 2026, SSE-C is blocked by default on new general purpose buckets, and on existing buckets in accounts that had no SSE-C objects. To use it, an administrator sets BlockedEncryptionTypes to NONE with PutBucketEncryption.
Amazon S3 encryption at rest: SSE-S3, SSE-KMS, DSSE-KMS or SSE-C
- Key management: SSE-S3 is handled by AWS; SSE-KMS uses AWS KMS keys; SSE-C uses your own external key store.
- Key storage: SSE-S3 keys stay in S3; SSE-KMS keys stay in KMS; SSE-C keys stay wherever you keep them, and AWS keeps none.
- Request headers: SSE-S3 needs none; SSE-KMS takes an optional KMS key ID; SSE-C requires the key and its MD5 on every request.
- Audit trail: S3 server access logs and CloudTrail data events record requests for all three; only SSE-KMS adds a KMS log entry for every key use, and SSE-C key use is logged only by your own key store.
Why SSE-C files break the S3 console and file sharing
The AWS Management Console cannot supply customer-provided keys. Even a user with full administrator access cannot view, download or preview an SSE-C object in the console.
Browsers and ordinary file-sharing tools cannot add the three SSE-C headers to a request either. A plain link to an SSE-C object fails, so the files are reachable only through the AWS CLI, the SDKs or custom code that holds the key.
For a business team, that turns an SSE-C bucket into a developer-only silo. Anyone who needs to open a contract or a scan has to ask an engineer to fetch it.
How to access Amazon S3 files without the AWS consoleS3 access for non-technical teams
How presigned URLs work with SSE-C objects
A presigned URL for an SSE-C object must include the x-amz-server-side-encryption-customer-algorithm header in its Signature Version 4 (SigV4) calculation. If you pass the key when you presign, the AWS SDKs also sign the key's MD5, which ties the URL to that one key.
The presigned URL does not carry the key itself. The client that opens the URL must still send the raw key in the x-amz-server-side-encryption-customer-key header. If the request omits the headers, or sends a different key, S3 rejects it.
In the AWS SDKs, set the SSECustomerKey and SSECustomerAlgorithm parameters when you presign. The application that signs the link needs the key at that moment, usually fetched from a vault. Keep these links short-lived, because a short expiry narrows the window in which an intercepted URL is useful.
Does AWS store my SSE-C keys?
No. S3 never stores SSE-C keys; it keeps only a salted HMAC to check later requests. You send the key with every read and write, and S3 removes it from memory once the operation completes.
Can I convert an S3 bucket from SSE-S3 to SSE-C?
No, not as a bucket setting. SSE-C applies to individual objects, so you first unblock SSE-C on the bucket, then re-encrypt each object with a CopyObject request that carries the new SSE-C headers. In a versioned bucket, the copy becomes a new version and the SSE-S3 version stays until you delete it.
How do I preview SSE-C encrypted files in a web browser?
A browser cannot preview an SSE-C object on its own, because it cannot send the key headers. You need middleware or a custom interface that holds the key and adds the SSE-C headers to each request.
What happens if I lose the encryption key for an SSE-C object?
The object is permanently unrecoverable. AWS has no master key and no recovery path for SSE-C, so a durable, backed-up key store of your own is the only protection.
Keep team files readable with SSE-KMS
BucketDesk never holds your keys, so it cannot open SSE-C objects: they still appear in the folder list, but previews and downloads fail and zip downloads skip them. For files your team browses, previews and shares, a customer-managed KMS key gives you your own key and access you can revoke.
- Keep SSE-C where it is required
systems that must hold their own keys keep them, and BucketDesk never asks for them.
- Encrypt team folders with your KMS key
its key policy decides which roles may use it.
- Add the key ARN to your BucketDesk connection
the stack grants the role kms:Decrypt on that one key, only through S3, so your team browses and previews in the browser, and revoking it in the key policy stops all reads at once.
What BucketDesk needs from your bucket, including KMSHow the IAM role and External ID work
Primary sources
Discussion
0 comments · open to guests · moderatedLiked this? Get the next article by email. No schedule, no digest, one click to leave.