Use a narrower key-management permission set that matches the specific KMS actions the identity actually needs, rather than the AWS AWSKeyManagementServicePowerUser Managed Policy. Prefer task-specific access for key administration, usage, or read-only inspection, and review whether the principal needs direct KMS permissions at all before granting them.
What should replace the AWS AWSKeyManagementServicePowerUser policy?
Use a narrower KMS permission set that matches the job, not a broad managed policy. The right replacement is usually a task-specific combination of key administration, key usage, or read-only inspection permissions, and in some cases no direct KMS permissions at all if another layer can mediate access more safely.
The practical shift is from “can manage most KMS functions” to “can do only the exact KMS actions this principal needs.” That means separating administrative access from cryptographic usage, keeping inspection-only workflows read-only, and avoiding permissions that let a principal create unnecessary blast radius. Where possible, pair this with a role design that makes the permissions temporary and narrowly scoped.
For AWS environments, the safer pattern is to start from the smallest KMS action set you can justify, then expand only when a concrete workflow breaks. A team that only encrypts or decrypts data should not inherit key administration capability, and a team that only audits KMS usage should not get write or policy-changing permissions. If the principal can operate through another service role, use that boundary instead of granting direct KMS authority.
Risk and Threat Considerations
Overbroad KMS permissions create a larger-than-needed failure domain. If a role, token, or workload is abused, the attacker may be able to change key policy, rotate access patterns, or use the key material more broadly than the business intended, turning one compromised principal into a much wider encryption exposure.
Failure mechanism: A managed policy that bundles administration, usage, and inspection capabilities can collapse separation of duties, so compromise or misuse of one principal becomes enough to alter or abuse key access.
Impact: The result can be unauthorized decryption, inappropriate key changes, harder incident containment, and a larger recovery effort because too many workflows depended on the same permission set.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | KMS access should be limited to the exact actions a role needs. |
| IA-5 — Authenticator Management | KMS access often depends on managing credentials, tokens, and keys safely. | |
| AC-5 — Separation of Duties | Administration and cryptographic use should not be combined in one broad role. | |
| Recommendation — Restrict KMS permissions to the minimum actions required for the task. Control credential and key lifecycle for principals that use KMS. Separate KMS administration from KMS usage privileges. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Least-privilege KMS access is an access control design decision. |
| A.8.2 — Privileged access rights | Broad KMS admin permissions are privileged access and need tighter control. | |
| Recommendation — Define KMS access rights by business need and role. Review and limit privileged KMS access rights. | ||
Practitioner Guidance
What to verify: Confirm the exact KMS verbs the principal uses in production, then compare that to the role’s effective permissions. If the identity never creates, rotates, disables, or updates keys, remove those actions from its scope. If it only needs to encrypt or decrypt through an application path, consider whether the application role, not the human or operator role, should hold the permission.
Decision rule: If a principal needs only one KMS function, grant only that function; if it needs multiple functions, separate them into distinct roles so administration and cryptographic use are not bundled together. For temporary tasks, prefer time-bound elevation over permanent broad access.
Practitioner takeaway: Least privilege for KMS is not about finding the closest broad policy, it is about proving whether the principal needs direct key authority at all, then granting only the smallest action set that survives operational testing.
Related resources from NHI Mgmt Group
- Guide: AWS IAM Policies and Roles Guide
- What should be used instead of the AWS AmazonBedrockLimitedAccess managed policy for least privilege?
- What should be used instead of the AWS AmazonDynamoDBFullAccess managed policy for least privilege?
- What should be used instead of the AWS AmazonBedrockReadOnly managed policy for least privilege?
- What should be used instead of the AWS AmazonEKSVPCResourceController managed policy for least privilege?