Notifications
Clear all
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.
NHIMG editorial — based on content published by Infisical: AWS Secrets Manager vs. KMS: Understanding the Difference
Questions worth separating out
Q: How should teams decide between AWS Secrets Manager and KMS?
A: Use AWS Secrets Manager for credentials, tokens, and database passwords that applications fetch at runtime.
Q: Why do Secrets Manager and KMS create different governance risks?
A: Secrets Manager governs what workloads authenticate with, while KMS governs the key material that protects those values and other data.
Q: What breaks when customer managed keys are introduced without clear ownership?
A: What breaks is the boundary between platform administration and security governance.
Practitioner guidance
- Separate secret ownership from key ownership Assign different control owners for runtime secrets in Secrets Manager and encryption keys in KMS so reviews, approvals, and incident response do not blur the two layers.
- Audit KMS key policies and grants first Check which workloads, roles, and rotation functions can use the key, then verify that the grant set matches the secret’s actual business boundary.
- Review cross-account secret access paths Trace how customer managed keys, resource policies, and assumed roles interact when one account needs to read or rotate a secret stored in another account.
What's in the full article
Infisical's full blog post covers the operational detail this post intentionally leaves for the source:
- Step-by-step guidance on when Secrets Manager alone is enough and when KMS becomes a separate governance requirement.
- Examples of customer managed key use cases across regulated and multi-account AWS environments.
- Details on how envelope encryption works inside Secrets Manager and why the wrapped data key matters operationally.
- Infisical's external KMS support, HSM backing, and KMIP-related deployment considerations.
👉 Read Infisical's explanation of AWS Secrets Manager vs. KMS →
AWS Secrets Manager and KMS: where identity teams draw the line?
Explore further
14/07/2026 4:30 pm
Secrets custody and key custody are not the same governance problem. Secrets Manager governs the values workloads use to authenticate, while KMS governs the encryption keys that protect those values. When teams collapse the two into one control bucket, access reviews and ownership models become ambiguous. The result is a programme that cannot tell whether it is reviewing secret access, key usage, or both, which is exactly where NHI governance breaks down.
A few things that frame the scale:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to The State of Secrets Sprawl 2026.
- AI-related credential leaks surged 81.5% year-over-year in 2025, with surrounding AI infrastructure leaking 5x faster than core LLM providers.
A question worth separating out:
Q: How should security teams govern secrets management when using end-to-end encryption?
A: Security teams should treat end-to-end encryption as one control in a broader governance model. The priority is to manage who can retrieve secrets, how keys are protected, where secrets are replicated, and how quickly access is revoked when workflows or ownership change. Encryption reduces exposure, but governance decides the blast radius.
👉 Read our full editorial: AWS Secrets Manager vs. KMS: what identity teams need to know
