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.
Why This Matters for Security Teams
The choice between AWS Secrets Manager and KMS is usually framed as a product decision, but it is really a control-boundary decision. Secrets Manager is designed to store and rotate secrets that applications retrieve at runtime, while KMS governs encryption keys used to protect data, objects, and custom crypto workflows. Mixing those responsibilities creates blind spots in ownership, rotation, and audit scope. The distinction matters even more in environments already struggling with secret sprawl, which NHIMG research has shown is often under-managed across teams and tools, as highlighted in the Guide to the Secret Sprawl Challenge and the Top 10 NHI Issues.
In practice, many security teams discover the difference only after a workload breaks because a key was treated like a secret, or a secret was left with key-like custody expectations.
How It Works in Practice
A practical decision starts with the artifact you are protecting. If the application needs a username/password, API token, database credential, or certificate material at runtime, use OWASP Non-Human Identity Top 10 style thinking and store that secret in Secrets Manager. The service is built for retrieval, rotation, and auditing around secrets lifecycle events. If the workload needs to encrypt data, sign requests, or manage envelope encryption for your own payloads, use KMS because the key itself is the control object, not the application credential.
That separation is important because it maps to different operational duties:
- Secrets Manager: store and rotate secrets, then fetch them at runtime with application access controls.
- KMS: define key policy, grant usage, and control who can encrypt, decrypt, or rewrap data.
- Both: when a workflow needs a secret to access a system and a key to protect data, treat them as separate layers with separate owners.
Use the runtime question as the test. If the workload is asking, “What credential do I present to log in or authenticate,” that points to Secrets Manager. If it is asking, “What key material governs the encryption boundary,” that points to KMS. For broader operational discipline, NIST’s Cybersecurity Framework 2.0 supports this split by separating asset management, access control, and protective technology into distinct governance activities. The same logic appears in NHIMG’s 230M AWS environment compromise coverage, where weak boundary handling turns routine cloud usage into a broad exposure issue.
These controls tend to break down when teams use KMS as a generic secret store or embed long-lived secrets in code, because the policy model no longer matches the way the workload actually authenticates.
Common Variations and Edge Cases
Tighter separation often increases operational overhead, requiring organisations to balance cleaner control boundaries against faster developer workflows. That tradeoff shows up most clearly when a service needs both a bootstrap secret and a key to decrypt downstream data.
Current guidance suggests a few patterns:
- Use Secrets Manager for application login material, especially when rotation and runtime retrieval are required.
- Use KMS for encryption keys, data-key wrapping, and any custom crypto workflow where you control the key policy.
- Do not assume KMS key policy alone is enough for secret lifecycle management, because it does not replace secret rotation or secret retrieval workflows.
- Do not store secrets in KMS just because they are “encrypted.” Encryption at rest is not the same as lifecycle governance.
There is no universal standard for every hybrid design yet, but the safest approach is to treat secrets custody and encryption custody as separate review tracks. That is especially important in pipelines, ephemeral compute, and cross-account architectures where one team owns the application secret while another owns the encryption boundary. NHIMG’s Ultimate Guide to NHIs — Static vs Dynamic Secrets is a useful reference when deciding whether a secret should be long-lived, rotated, or replaced with a more ephemeral pattern.
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 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Secret storage and rotation are central to deciding between Secrets Manager and KMS. |
| NIST CSF 2.0 | PR.AC-4 | The question hinges on controlling who can access secrets versus encryption keys. |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero trust helps split authentication secrets from encryption trust boundaries. |
| CSA MAESTRO | IAM-02 | Agentic and cloud workloads need clear handling of secrets, keys, and delegated access. |
| NIST AI RMF | AI RMF supports governance over tool access, credentials, and operational accountability. |
Establish ownership, monitoring, and review for each workload credential and key boundary.
Related resources from NHI Mgmt Group
- How should teams decide whether to keep AWS Secrets Manager as the primary control?
- How should security teams decide between dynamic secrets and rotation?
- How should teams decide between AWS roles and policies for access control?
- How should security teams authenticate AI agents in enterprise environments?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on July 14, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
