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.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Infisical's blog post: AWS Secrets Manager and KMS solve different identity-security problems, with one storing secrets for runtime use and the other controlling the keys that encrypt them.
Why it matters: IAM, IGA, and platform teams need to separate secret custody from key custody so rotation, policy, and cross-account access are governed at the right layer.
Context
AWS Secrets Manager and AWS Key Management Service (KMS) are often mentioned together, but they sit at different control layers. Secrets Manager holds application credentials such as API keys, OAuth tokens, and database passwords, while KMS manages the cryptographic keys used to encrypt and decrypt data.
The governance problem is not the technologies themselves, but the way teams collapse them into one mental model. Once secret storage, key policy, and rotation ownership are treated as the same control, access reviews and platform operating models become harder to define, especially in regulated or multi-account AWS environments.
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. The practical goal is one policy for ownership, rotation, access enforcement, and retirement across cloud, database, and Kubernetes environments. If those controls diverge by platform, governance will fracture into exceptions that are hard to audit and even harder to revoke.
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. Teams must align key policies, secret resource policies, cross-account grants, and rotation workflows. That adds accountability but also expands the number of decisions that can create privilege gaps if left undocumented.
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. Those are indicators that the control boundary has collapsed, even if both services are technically in use.
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.
Technical breakdown
Secrets storage versus key control in AWS
AWS Secrets Manager is a runtime credential store. Applications fetch a secret value when they need to authenticate, which makes it suitable for database passwords, API keys, and tokens that workloads use directly. KMS does not store those values. It creates and controls encryption keys, then services call it to encrypt or decrypt data without ever retrieving the key itself. That architectural split matters because the secret is the operational object, while the KMS key is the protecting control plane. When teams blur the two, they misassign responsibility for access policy, rotation, and audit scope.
Practical implication: separate the governance owner for secrets from the owner for encryption keys.
Envelope encryption and the hidden dependency between the two services
Secrets Manager uses envelope encryption under the hood. KMS generates a data key, that data key encrypts the secret, and only the wrapped version is stored or passed through the service boundary. This means every secret in Secrets Manager already depends on KMS, even when teams do not manage KMS directly. The security consequence is simple: compromise of the protecting key undermines the secrecy of whatever it encrypts. For practitioners, that makes key policy, grants, and key lifecycle controls part of the secrets-management problem, not a separate afterthought.
Practical implication: treat KMS policy and secret policy as linked controls during design and review.
Customer managed keys change the governance model
The moment a team uses customer managed keys, the problem moves from default service operation to explicit governance. Key policies must align with secret resource policies, cross-account access needs grant design, and rotation functions may need permission to use the key. That creates a second layer of access decisions that platform, compliance, and security teams must own deliberately. In mature environments, this is where secrets management stops being a simple application utility and becomes a governed identity-security surface with audit, delegation, and separation-of-duties implications.
Practical implication: review customer managed key use as part of access governance, not just encryption architecture.
Breaches seen in the wild
- Hugging Face Spaces breach 2024: Unauthorised access to Hugging Face Spaces may have exposed secrets users stored for AI apps; tokens were revoked and org tokens removed.
- OneLogin API flaw (CVE-2025-59363): A OneLogin API flaw exposed OIDC client secrets to anyone with an API key, including vendors (CVE-2025-59363); fixed with no customer impact.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
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.
Envelope encryption creates an unavoidable dependency on key governance: Even when teams never touch KMS directly, their secrets still rely on it. That means the secrecy of a secret is only as strong as the discipline around the key that wraps it. For IAM and PAM teams, the practical takeaway is that encryption policy cannot be separated from access policy once secrets are stored in a managed service.
Customer managed keys turn a technical choice into a control surface: Once organisations move beyond AWS managed keys, they inherit policy alignment, grants, and permission scoping as ongoing governance work. This is where key custody starts to resemble NHI governance: there is an identity boundary, a lifecycle boundary, and an audit boundary. Teams that ignore those boundaries end up with duplicated authority and weak accountability.
Named concept, layered custody gap: The core issue here is a layered custody gap, where the object being protected and the mechanism protecting it are handled as if they were interchangeable. They are not. The implication is that identity programmes need explicit ownership for secrets, keys, and the service interactions between them, rather than a single undifferentiated AWS security workstream.
From our research library:
- 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.
- Read next: Guide to the Secret Sprawl Challenge
What this signals
Layered custody gap: Secrets and encryption keys should not be treated as one governance object. Once teams separate the runtime credential store from the cryptographic key that protects it, ownership, review cadence, and exception handling become much clearer for IAM and platform teams.
The wider secrets-management problem is still one of sprawl and incomplete custody. According to the 2024 State of Secrets Management Survey, only 44% have a dedicated secrets management system, which explains why the control boundary between secret storage and key management is still so often blurred.
For practitioners
- Define separate ownership for secrets and keys Assign one team to application secret lifecycle and another to encryption key policy, rotation, and grants. Keep responsibility boundaries visible in RACI, change control, and audit evidence.
- 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.
- Set rotation ownership by control layer Make secret rotation a secrets-management process and key rotation a cryptographic governance process, with separate evidence for each during reviews and exceptions.
Key takeaways
- AWS Secrets Manager and KMS address different layers of control, so identity teams should not assign them the same governance owner.
- The key risk is not tool overlap but boundary collapse, where secret custody, key custody, and rotation policy become indistinguishable.
- Clear separation of policy, ownership, and audit evidence is the practical test for whether the control model is working.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, NIST CSF 2.0 and CSA Cloud Controls Matrix set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Secrets Manager is the control discussed for storing application secrets safely. |
| NHI-07 — Long-Lived Secrets | The article centres on secret rotation and the operational differences from key control. | |
| Recommendation — Inventory exposed secret paths and move them into governed secret storage. Reduce long-lived credential exposure by separating rotation from encryption-key governance. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Authenticator lifecycle governs the storage and rotation of application credentials. |
| Recommendation — Apply IA-5 to manage secret rotation, revocation, and reuse across workloads. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article focuses on who can access secrets and keys across AWS layers. |
| Recommendation — Review entitlements so secret access and key use stay aligned with business need. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | AWS secrets and key access are cloud identity controls with shared governance impact. |
| Recommendation — Map secret and key governance into cloud IAM controls and separate the owners. | ||
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.
- KMS Key: A KMS key is a cryptographic control used to encrypt and decrypt data stored in AWS. For log pipelines, the key must stay enabled and accessible to authorised services, or records may become unreadable. Key status and permissions therefore directly affect the integrity and availability of security logs.
- 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.
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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on July 14, 2026.
Updated on October 13, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org