DEV Community

Bala Paranj
Bala Paranj

Posted on

The CMK vs AWS-managed key trap in HIPAA S3

#hipaa #aws #s3 #security

✓ Human-authored analysis; AI used for formatting and proofreading.

"Which KMS key should I use for PHI in S3? We're using the default aws/s3 managed key. Our auditor is asking about key management but SSE-KMS is SSE-KMS, right?"

Wrong. The difference between an AWS-managed key and a customer-managed key (CMK) is the difference between having and not having a breach containment option.

What most teams get wrong

S3 offers three encryption options:

  1. SSE-S3 (AES-256) -- AWS manages everything. No KMS involvement.
  2. SSE-KMS with AWS-managed key (alias/aws/s3) -- KMS envelope encryption, but AWS controls the key lifecycle.
  3. SSE-KMS with customer-managed key -- You control key policy, rotation, and can disable or delete the key.

Teams often pick option 2 and consider the encryption box checked. KMS is involved. Envelope encryption is in play. The auditor sees "aws:kms" in the configuration and moves on.

The problem surfaces during incident response.

Why CMK matters for HIPAA breach response

HIPAA's Breach Notification Rule (SS 164.408) has a safe harbor: if encrypted PHI is breached but the encryption key was not compromised, you may not need to notify affected individuals. But this safe harbor only works if you can demonstrate the key is inaccessible to the attacker.

With an AWS-managed key:

  • You cannot disable the key
  • You cannot schedule the key for deletion
  • You cannot modify the key policy to revoke access
  • AWS controls the entire key lifecycle

With a customer-managed key:

  • You can disable the key immediately, rendering all encrypted objects unreadable
  • You can revoke access by modifying the key policy
  • You can schedule the key for deletion with a 7-30 day waiting period
  • CloudTrail logs every key usage event for forensic analysis

During an active breach, disabling the CMK is an immediate containment action. With an AWS-managed key, you have no equivalent lever.

How Stave detects this: CONTROLS.001.STRICT

The HIPAA profile includes CONTROLS.001.STRICT at CRITICAL priority, mapped to SS 164.312(a)(2)(iv). This control fails on any encryption configuration that does not use a customer-managed KMS key.

stave evaluate --snapshot observations/snap.json --profile hipaa
Enter fullscreen mode Exit fullscreen mode 
═══ HIPAA Security Rule ═══
Bucket:    phi-claims-data
Account:   ***234
Snapshot:  2026-04-08T09:00:00Z
Result:    FAIL

── CRITICAL ──

  [FAIL] CONTROLS.001.STRICT — critical
  Compliance: §164.312(a)(2)(iv) — CMK required for key revocation during breach response
  Finding: Encryption uses AWS-managed key — customer cannot revoke
  Remediation: Change default encryption to SSE-KMS with a customer-managed key
Enter fullscreen mode Exit fullscreen mode

CONTROLS.001.STRICT fails in four cases:

  • Encryption is disabled entirely
  • Algorithm is SSE-S3 (AES-256) instead of SSE-KMS
  • SSE-KMS is enabled but no KMS key ID is specified (defaults to AWS-managed)
  • KMS key ID is explicitly alias/aws/s3

The standard CONTROLS.001 control (which checks only that encryption is enabled) would pass here. The .STRICT variant is a separate control specifically for HIPAA workloads where key revocation capability is a requirement.

For HIPAA workloads, encrypted is not enough. You need encryption with a key you can revoke. Create a dedicated CMK for your PHI buckets, enable automatic key rotation, and restrict the key policy to the minimum principals that need access. When your auditor asks about key management, the answer is: Customer-managed KMS key with rotation enabled, revocable within seconds.

Top comments (0)