They should keep it if the estate is largely AWS-centric and the control model is acceptable for rotation, audit, and access governance. If workloads are hybrid or multi-cloud, the decision should shift toward whether the platform can support consistent lifecycle policy across environments. The real test is governance coverage, not brand preference.
Why This Matters for Security Teams
The decision is not really about whether AWS Secrets Manager is “good enough”; it is about whether a single cloud-native control can still enforce lifecycle, audit, and revocation when the application estate expands beyond AWS. That distinction matters because secrets are only as safe as their rotation cadence, access boundaries, and blast-radius limits. NHIMG’s research on the Guide to the Secret Sprawl Challenge shows how quickly unmanaged secrets accumulate across modern delivery pipelines, while the OWASP Non-Human Identity Top 10 frames credential lifecycle gaps as a core NHI risk rather than a storage problem.
For AWS-centric estates, Secrets Manager can be the primary control if it is paired with policy discipline and evidence that every secret follows a defined owner, TTL, and rotation path. For hybrid environments, the question shifts to governance consistency: can the team prove the same control intent across cloud services, CI/CD systems, and runtime workloads? In practice, many security teams discover their control gap only after a secret has already been reused outside AWS, rather than through intentional lifecycle design.
How It Works in Practice
A practical decision model starts with inventory. If a workload uses AWS Secrets Manager only for AWS-native services, and the surrounding controls already cover access reviews, rotation automation, and break-glass procedures, then it can remain the primary control. If the estate includes Kubernetes, SaaS APIs, GitHub Actions, on-premises workloads, or another cloud, then the better test is whether Secrets Manager is the system of record or only one storage endpoint.
Current guidance suggests evaluating three layers together:
- Lifecycle control: who creates the secret, who approves access, and what triggers rotation or revocation.
- Runtime consumption: whether applications retrieve secrets just in time, or cache them in ways that outlive the approved use.
- Governance evidence: whether audit logs, policy-as-code, and ownership metadata are uniform enough to satisfy review across environments.
NHIMG’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is useful here because it treats identity lifecycle as the control plane, not the vault alone. That aligns with the NIST Cybersecurity Framework 2.0 emphasis on governance, protection, and continuous monitoring. Teams should also compare AWS Secrets Manager against the Top 10 NHI Issues to see whether secret sprawl, stale credentials, or missing ownership are already undermining control effectiveness.
If the platform cannot enforce consistent rotation and revocation across non-AWS runtimes, then Secrets Manager is no longer the primary governance control, even if it remains one of the storage backends. These controls tend to break down when secrets are copied into CI/CD variables or application configs because the secret is no longer governed where it is actually used.
Common Variations and Edge Cases
Tighter centralization often increases operational overhead, so organisations have to balance governance consistency against application friction and cloud dependency. That tradeoff is acceptable in some AWS-first environments, but it becomes harder to justify when teams need identical controls across multiple clouds or legacy platforms.
Best practice is evolving for mixed estates. Some teams keep Secrets Manager as the primary AWS vault while using a separate control plane for cross-environment lifecycle policy. Others move to a platform-agnostic approach when they need uniform service identity, short-lived credentials, and automated revocation outside AWS. The right answer depends less on where the secret is stored and more on whether the secret can be governed end to end.
There is no universal standard for this yet, but the decision should be explicit in three situations: mergers with inherited cloud estates, application modernization programs that span AWS and non-AWS workloads, and regulated environments where audit evidence must cover every runtime. AWS-centric does not automatically mean AWS-only, and a vault without lifecycle consistency should not be treated as a complete primary control.
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 address the attack and risk surface, while NIST CSF 2.0 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 rotation and stale credentials are central to the control decision. |
| NIST CSF 2.0 | GV.OV-01 | This question is fundamentally about governance coverage across the estate. |
| NIST AI RMF | If AI or agent workloads consume secrets, risk management must cover lifecycle and misuse. |
Apply AI RMF governance to ensure secrets supporting AI workloads are inventoried, monitored, and revocable.
