Topic starter
14/07/2026 4:23 pm
TL;DR: AWS Secrets Manager stores application secrets such as API keys and database credentials, while AWS KMS controls the encryption keys that protect those secrets and other data, according to Infisical. The operational difference matters because credential custody, encryption policy, and rotation responsibilities sit at different layers, and teams often confuse them until governance gets messy.
Editorial analysis by NHI Mgmt Group, based on content published by Infisical: “AWS Secrets Manager vs. KMS: Understanding the Difference”.
Key questions
Q: How should security teams govern secrets across AWS and non-AWS environments?
A: They should treat secrets governance as a cross-platform identity problem, not an AWS-only storage task.
Q: Why do customer managed keys change the governance burden?
A: Customer managed keys move the organisation from default service behaviour to explicit control ownership.
Q: What are the signs that AWS secrets and keys are being governed as one control?
A: Common signs include shared ownership between platform and application teams, undocumented cross-account access, unclear rotation responsibility, and audit evidence that cannot distinguish secret handling from key handling.
Practitioner guidance
- Define separate ownership for secrets and keys Assign one team to application secret lifecycle and another to encryption key policy, rotation, and grants.
- Map every secret to its backing KMS dependency Inventory which workloads rely on AWS managed keys versus customer managed keys, and record where cross-account access or Lambda-based rotation needs additional KMS permissions.
- Review cross-account access paths Check whether key policies and secret resource policies allow the same principals, then remove any excess permission that lets a workload decrypt data it should not read.
Bottom line: AWS Secrets Manager and KMS address different layers of control, so identity teams should not assign them the same governance owner.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
14/07/2026 4:30 pm
Secrets custody and key custody are different governance problems: Secrets Manager governs the operational value that applications consume, while KMS governs the cryptographic control that protects it. Treating them as one control obscures who owns runtime access, who owns encryption policy, and who approves cross-account use. The result is not just architectural confusion, but mis-scoped identity governance. Practitioners should draw a hard line between credential lifecycle and key lifecycle.
A few things that frame the scale:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
- 54% of organisations are dissatisfied with their current secrets management solution because not all secrets are secured, and 43% cite lack of central management, according to the 2024 State of Secrets Management Survey.
A question worth separating out:
Q: What should teams do when Secrets Manager and KMS access policies do not match?
A: Reconcile the two policy layers before expansion or exception handling. If a principal can read a secret but should not decrypt broader data, or can use a key without business need, the access model is already overextended. Remove the mismatch and document the intended custody model.
👉 Read our full editorial: AWS Secrets Manager vs. KMS: what identity teams need to know