How to Block SSE-C Usage and Protect S3 With Versioning and Object Lock

Retrospective: this article looks back at events from January 2025, written in 2026 with the benefit of hindsight.

Codefinger ransomware encrypted S3 objects with SSE-C keys only the attacker held. Here is how to block SSE-C and make your S3 data recoverable.

Step 1: Check whether you use SSE-C

Few organizations use SSE-C. Check CloudTrail data events for PutObject requests with SSE-C headers, or ask application teams. If you don't use it, block it.

Step 2: Block SSE-C

Bucket policy: deny s3:PutObject when the SSE-C header is present:

{
  "Sid": "DenySSEC",
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:PutObject",
  "Resource": "arn:aws:s3:::example-bucket/*",
  "Condition": {"Null": {"s3:x-amz-server-side-encryption-customer-algorithm": "false"}}
}

Organization-wide: use an SCP with a similar condition to deny SSE-C uploads across all accounts. Also check for newer bucket-level encryption type controls AWS has introduced to block SSE-C directly.

Step 3: Enable versioning

Versioning keeps previous object versions, so an overwritten (encrypted) object can be restored. Pair with lifecycle rules to manage cost.

Step 4: Use Object Lock for critical data

Object Lock in compliance or governance mode prevents deletion or overwrite of versions for a retention period — protecting against both encryption and deletion.

Step 5: Back up to a separate account

Use AWS Backup for S3 with backups copied to a dedicated backup account with Vault Lock.

Step 6: Restrict lifecycle policy changes

Limit s3:PutLifecycleConfiguration to administrators and alert on changes.

Step 7: Remove long-lived keys

Codefinger needed valid credentials. Replace IAM user keys with roles.

Verify

Test restoring a previous version of an object after an overwrite.