AWS Secrets Manager vs. KMS: what identity teams need to know

At a glance

What this is: AWS Secrets Manager handles runtime secrets, while AWS KMS handles the encryption keys behind those secrets and other data.

Why it matters: Identity and platform teams need the distinction to assign custody, rotation, and access controls correctly across NHI, workload, and application encryption workflows.

👉 Read Infisical's explanation of AWS Secrets Manager vs. KMS

Context

AWS Secrets Manager and AWS KMS solve related but different identity and cryptography problems. Secrets Manager stores application credentials that workloads need at runtime, while KMS governs the keys that encrypt those credentials and other data objects. The governance challenge starts when teams treat both as interchangeable just because both protect sensitive material.

For IAM and NHI programmes, the real issue is not which service is more secure, but which control surface applies at each layer. Secrets custody, key policy, cross-account access, and rotation responsibilities often sit with different teams, which means access reviews and lifecycle management need to be mapped to the right object type rather than the AWS label.

The distinction becomes sharper in regulated or multi-account environments where customer managed keys, grants, and Lambda-based rotation functions all create additional governance dependencies. That makes this a familiar NHI pattern: the more critical the environment, the less useful a single default service is as an operating model.

Key questions

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. Use AWS KMS when you need to control encryption keys for your own data, objects, or custom encryption flows. If your workflow needs both storage and encryption custody, treat them as separate control layers with separate ownership and policy review.

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. That means a failure in secret ownership creates authentication risk, while a failure in key policy creates broader decryption and custody risk. IAM teams need to review both layers independently because the blast radius is not the same.

Q: What breaks when customer managed keys are introduced without clear ownership?

A: What breaks is the boundary between platform administration and security governance. Once teams use customer managed keys, cross-account grants, and custom rotation functions, key usage becomes an entitlement problem as much as a cryptography problem. Without clear ownership, audits miss who can encrypt, decrypt, or rotate protected assets.

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.

Technical breakdown

Secrets Manager vs. KMS in the access path

AWS Secrets Manager returns secret values to applications at runtime, such as database passwords, API keys, and OAuth tokens. AWS KMS does not return the encryption key itself to the caller. Instead, applications or AWS services send data to KMS for encryption or decryption, and KMS controls the key material behind that operation. This separation matters because the secret is the object workloads consume, while the key is the control plane that protects it. Practitioners should treat these as different identity and custody layers, not interchangeable storage options.

Practical implication: Map application credentials to Secrets Manager ownership and encryption keys to KMS ownership so access reviews hit the correct control surface.

Envelope encryption and the hidden dependency chain

Secrets Manager uses envelope encryption, which means KMS generates a data key, that data key encrypts the secret value, and only the wrapped data key is handled through the KMS API. This design reduces direct exposure to raw key material while creating a dependency chain between the secret and the key policy that protects it. If the wrapping key is mis-scoped, rotated improperly, or made too broadly usable, the secret inherits that weakness. In practice, the confidentiality of the secret is only as strong as the custody and policy on the KMS key underneath it.

Practical implication: Review KMS key policies, grants, and rotation settings with the same care you apply to the secrets they protect.

When key governance becomes the primary control layer

Most teams can use the AWS managed key by default and never touch KMS directly. Once organisations move into customer managed keys, cross-account access, or compliance-driven key custody, KMS becomes a governance surface of its own. That is where lifecycle processes, resource policies, and key grants intersect with workloads that still expect to fetch secrets cleanly at runtime. The operational question changes from storing a credential safely to controlling exactly which key encrypts what and who is allowed to use it. This is where identity, cryptography, and platform governance converge.

Practical implication: Assign explicit ownership for customer managed keys, cross-account grants, and rotation automation before regulated workloads depend on them.

Threat narrative

Attacker objective: The objective is to turn one exposed secret or key path into authenticated access to applications, data, or encryption-protected assets.

1. Entry occurs when a workload or operator gains access to a stored secret or encryption path, often through mis-scoped permissions or exposed credentials.
2. Escalation follows if the same identity can also use the underlying KMS key or key grant, turning a single secret exposure into broader decryption capability.
3. Impact occurs when the attacker can authenticate to downstream systems or decrypt protected data, extending one compromised secret into wider environment access.

Breaches seen in the wild

• 230M AWS environment compromise — 230M AWS environments compromised via exposed .env files with cloud credentials.
• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Key policy is now part of the identity perimeter. Customer managed keys, cross-account grants, and Lambda rotation functions turn KMS into an access-control layer, not just a cryptographic utility. That aligns directly with NIST Cybersecurity Framework 2.0 and NIST SP 800-53 Rev 5 Security and Privacy Controls, because the control problem is no longer storage alone but who can invoke encryption, decryption, and rotation under which policy. Practitioners need to treat key governance as a first-class entitlement domain.

Envelope encryption shifts the trust boundary, but it does not remove it. The wrapped data key limits direct exposure, yet the security of the secret still depends on KMS policy, grants, and lifecycle controls. That means the weak point is often not the secret store itself but the privileges around the key that protects it. For NHI programmes, this is a reminder that the cryptographic layer is still an identity layer when service accounts and automation call it.

Identity blast radius: One exposed secret can be operationally small on paper but existential when the same environment lets that identity use multiple encryption and authentication paths. The field should stop thinking about secrets as isolated values and start measuring how far a single credential can propagate through adjacent AWS control surfaces. Practitioners should model blast radius across secrets, keys, and downstream entitlements together.

Default-managed keys are acceptable until governance requirements change. Once regulated workloads, multi-account access, or external key custody enter the picture, the operating model changes materially. That is the point where lifecycle processes, audit evidence, and policy ownership must become explicit rather than inherited from AWS defaults. Teams should re-evaluate whether their current key model still matches their compliance and access boundaries.

From our research:

• 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.
• That pattern reinforces why teams need a broader lifecycle view, as seen in Guide to the Secret Sprawl Challenge, where exposure and governance failures are treated as operational, not theoretical.

What this signals

Key custody is becoming part of the identity programme, not a side concern. As more organisations move from default AWS managed keys to customer managed keys, the programme now has to govern who can invoke encryption, decryption, and rotation as a matter of entitlement design. That is the same shift seen in other workload-identity patterns, where OWASP Non-Human Identity Top 10 control thinking becomes more useful than traditional storage-centric security.

Runtime secret handling and key governance need different evidence. A platform team can prove a secret exists in a vault, but that does not prove the key policy, grant scope, and rotation flow are aligned. The practical signal is whether the same identity that can fetch a secret can also widen decryption access indirectly through KMS usage paths.

The next maturity step is not choosing one AWS service over the other, but measuring where governance responsibility stops. Teams that already centralise secrets workflows should add explicit key-owner review, especially in multi-account environments where a single mis-scoped grant can outlive the secret it protects.

For practitioners

• 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.
• Test secret compromise against downstream decryption Validate whether compromise of one stored secret also exposes the KMS usage path needed to decrypt adjacent data or rotate the secret safely.

Key takeaways

• Secrets Manager and KMS solve different identity problems, and confusing them creates governance blind spots.
• A secret is only as safe as the key and policy layer underneath it, which makes KMS ownership part of NHI control.
• Practitioners should separate secret custody, key custody, and rotation responsibility before regulated workloads depend on shared assumptions.

Key terms

• Secret Manager: A secret manager is a control that stores and sometimes rotates credentials such as tokens, keys, and certificates. It reduces exposure of sensitive material, but it does not by itself establish ownership, entitlement context, or revocation accountability, which means governance can still fail even when storage is secure.
• AWS KMS: A managed key service that creates, controls, and uses encryption keys without exposing raw key material to callers. It is the policy and custody layer for cryptographic operations, which means access to KMS is an entitlement decision, not just a technical encryption setting.
• Envelope Encryption: A two-layer encryption pattern that uses a short-lived data encryption key to protect the data and a longer-lived key encryption key to wrap that data key. It scales rotation, supports tenant separation, and keeps the primary key material out of direct data handling.
• Customer Managed Key: A key that an organisation creates and controls rather than using the cloud provider's default managed key. It gives the organisation more policy, audit, and custody control, but it also shifts responsibility for grants, rotation, and lifecycle governance onto the team that owns it.

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.

👉 Infisical's full post covers the envelope encryption flow, customer managed key trade-offs, and external KMS options.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.