AWS KMS Key Management: Key Policies, Customer-Managed Keys, and Rotation
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
AWS KMS appears straightforward: create a key, reference it in an S3 bucket policy or RDS configuration. The complexity surfaces when a service cannot decrypt data because the key policy did not include the right principal, or when an application breaks because it stores the key version and rotation invalidates cached references.
The key policy is the source of most KMS-related operational problems. Understanding how key policies interact with IAM policies, how grants work differently from policy statements, and what envelope encryption actually does prevents the access errors that break deployments and the audit findings that appear when key usage is unmonitored.
Key policy design: the access control foundation
A correct key policy is the prerequisite for every other KMS security property. The key policy document governs who can use a CMK for cryptographic operations and who can manage it, and unlike most AWS resources, an IAM policy alone is not sufficient to grant KMS access if the key policy does not explicitly permit it. Practitioners must understand the interaction between key policy statements and IAM policies, the risk of granting kms:PutKeyPolicy to key users, and why the root account statement must be present in every CMK policy to prevent a locked-out key from becoming permanently unmanageable.
Include the root account statement in every CMK key policy
The root account statement — granting arn:aws:iam::ACCOUNT_ID:root kms:* — does not grant root user operational access to the key in practice. It enables IAM-based access control to work alongside the key policy. Without this statement, if you remove all key administrator principals from the key policy, the key becomes permanently unmanageable: no one in the account can modify the policy, and AWS Support cannot recover it. Every CMK should include this statement as a safety net, with operational access controlled through separate key administrator and key user statements scoped to specific IAM role ARNs.
Never allow key users to call kms:PutKeyPolicy
A principal with kms:PutKeyPolicy permission on a key can replace the key policy with one that grants themselves or any other principal unrestricted access. Key users — application roles and service roles that call Encrypt, Decrypt, and GenerateDataKey — should have exactly those permissions and nothing else. Key administrators — the roles responsible for managing key configuration — should have key management permissions but not necessarily decryption permissions. Separating these two permission sets in distinct policy statements prevents privilege escalation through the key.
Operational patterns: rotation, envelope encryption, and audit
The operational disciplines that make a KMS implementation maintainable and auditable over time include configuring automatic rotation before ciphertext volume accumulates, using envelope encryption for any application data that exceeds 4KB, and establishing CloudTrail alerting that catches anomalous decryption before it becomes a data access incident. These three practices address the most common failure modes in production KMS deployments: stale cryptographic material, payload data transiting KMS unnecessarily, and unauthorized key usage that goes undetected for weeks. Each control is independent and can be implemented without changes to the others.
Enable automatic rotation at key creation, not after the fact
Automatic rotation for symmetric CMKs is a single checkbox at key creation time. Enable it at creation as a default for every CMK that does not have a specific reason to disable it. Confirming rotation is enabled is a quick CLI check: aws kms get-key-rotation-status --key-id KEY_ID returns RotationEnabled: true or false. Include this check in any CMK provisioning runbook. Attempting to evaluate rotation policy years after key creation, when existing ciphertext volume is large and application dependencies on key version are unclear, is significantly more work.
Build CloudTrail alerting for KMS anomalies before they become incidents
CloudTrail records every KMS API call with principal ARN, source IP, and encryption context. Three alerting patterns catch the most common KMS misuse: unexpected principals calling kms:Decrypt on a key (a service that should not have access is decrypting data), kms:DisableKey or kms:ScheduleKeyDeletion calls (someone is disabling an encryption key, which will break the service that uses it), and high-volume GenerateDataKey calls from an unexpected IP (credential theft and exfiltration using a stolen role). Create CloudWatch metric filters for these patterns and configure alarms with SNS notifications to the security team.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
The bottom line
AWS KMS key management is a policy design discipline more than a cryptography problem. AWS handles the cryptographic operations correctly — the practitioner's job is to write key policies that give exactly the right principals access to exactly the operations they need, enable rotation so cryptographic material does not persist indefinitely, use envelope encryption for application data so payload never transits KMS, and audit key usage through CloudTrail to detect anomalous decryption before it becomes an incident. A CMK with a correct key policy, automatic rotation enabled, and CloudTrail alerting configured is a secure foundation for any encryption implementation.
Frequently asked questions
What is the difference between AWS managed keys and customer-managed keys in KMS?
AWS managed keys are created and controlled by AWS services on your behalf with a default key policy that AWS owns, automatic annual rotation, and no direct policy modification. Customer-managed keys (CMKs) are keys you create with full control over the key policy, custom rotation schedules, cross-account access grants, and the ability to disable or schedule deletion. CMKs are required when you need to control who can use the key, audit usage with fine-grained CloudTrail detail, share the key across accounts, or use envelope encryption in your own applications.
How should I structure an AWS KMS key policy for least privilege?
A secure KMS key policy separates administrators from users in distinct policy statements. The root account statement allows the root principal kms:* permissions so IAM policies can be used for access control and the key does not become unmanageable from a misconfiguration. A key administrators statement allows IAM roles (not individual users) to perform management operations like enabling, disabling, rotating, and deleting the key. A key users statement restricts application and service roles to only kms:Decrypt, kms:GenerateDataKey, kms:DescribeKey, and kms:ReEncrypt, preventing them from modifying key configuration.
How does AWS KMS automatic key rotation work?
Automatic key rotation for a symmetric CMK generates new cryptographic material annually while preserving the same key ID, ARN, alias, and key policy. Existing ciphertext encrypted under old material remains decryptable because KMS retains all previous key material versions and selects the correct version during decryption automatically. This protects against long-term key exposure by limiting the data volume encrypted under any single cryptographic material version, reducing blast radius if old material is ever compromised. No application changes are required when rotation occurs.
When should I use KMS grants instead of key policy statements?
KMS grants are the correct mechanism for temporary, service-to-service access delegation where the grantee changes dynamically. Common use cases include AWS services requesting temporary decryption access when processing your data, Lambda functions needing decryption for a specific job, and cross-account access where adding every external account as a key policy principal would make the policy unmanageable. Grants are revocable per-grant without modifying the key policy and can include conditions and encryption context restrictions. Use key policy statements for permanent, human-managed roles and grants for dynamic service-initiated access.
What is envelope encryption and when should I use it with KMS?
Envelope encryption is required when you need to encrypt data larger than 4KB or need local encryption performance without a KMS API call per encrypt operation. Call GenerateDataKey with your CMK key ID to receive a plaintext data key and an encrypted data key. Encrypt your data locally using the plaintext data key with AES-256-GCM, then discard the plaintext key from memory immediately and store the encrypted data key alongside the ciphertext. To decrypt, call KMS Decrypt on the encrypted data key to recover the plaintext key, then decrypt locally. This keeps your data out of KMS entirely while using KMS as the key authority.
How do I audit AWS KMS key usage and detect unauthorized access?
CloudTrail records every KMS API call including the principal ARN, source IP address, user agent, key ID, and operation. Create CloudWatch metric filters and alarms for kms:Decrypt or kms:GenerateDataKey calls from unexpected principal ARNs, calls from IP addresses outside expected ranges, operations on keys outside business hours, and calls with unexpected encryption context values. Security Hub detects KMS best practice violations automatically. Also review KMS grants periodically and revoke grants that are no longer needed, as grants accumulate and represent access not visible in the key policy.
How do I configure cross-account KMS key access?
Cross-account KMS access requires configuration in both the key-owner account and the key-user account. In the key-owner account, add a key policy statement granting the external account's IAM role ARN kms:Decrypt and kms:GenerateDataKey permissions. In the key-user account, create an IAM policy granting those same KMS permissions and attach it to the role that needs access. Both the key policy and the IAM policy must allow the action for access to succeed. For AWS services in the external account such as S3 replication, use the service-linked role ARN in the key policy and ensure the service role has corresponding KMS permissions in its own account.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.