AWS Secrets Manager and the limits of native secrets governance

At a glance

What this is: This guide explains how AWS Secrets Manager works and where its governance limits show up in real operations.

Why it matters: It matters because IAM, NHI, and platform teams still have to manage access scope, rotation, auditability, and lifecycle controls even when secrets live inside AWS.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes - and as quickly as 9 minutes in some cases.

👉 Read Infisical's AWS Secrets Manager guide for setup, rotation, and cost detail

Context

AWS Secrets Manager is a managed secret store for credentials, API keys, OAuth tokens, and other secrets. The governance question is not whether it stores secrets securely, but whether its native model is enough once teams need lifecycle control, auditability, and consistent access policy across a growing estate of non-human identities.

For AWS-first workloads, the service reduces manual handling and supports runtime retrieval, versioning, and rotation. The practical gap appears when teams depend on Terraform state, cross-account access, or multi-cloud operations, because the secret is protected in AWS but the surrounding identity process is still only as strong as the programme around it.

Key questions

Q: How should teams govern AWS Secrets Manager in a multi-cloud environment?

A: Teams should use AWS Secrets Manager for AWS-native workloads, but they should not treat it as the only secrets governance layer. Multi-cloud estates need a common lifecycle model for rotation, offboarding, access review, and audit. If each platform manages secrets differently, teams lose consistent control over ownership, scope, and revocation.

Q: Why do AWS secrets still create risk when they are centrally stored?

A: Central storage reduces exposure, but risk remains when IAM scope is too broad, Terraform state retains plaintext values, or applications cache credentials beyond their intended use. The real security boundary is not the vault alone. It is the full path from creation to rotation to revocation across every consumer.

Q: What breaks when secret rotation is automated but downstream systems are not ready?

A: Automated rotation fails when the new value is promoted before databases, applications, or integrations can accept it. That can cause outages, stale sessions, or rollback confusion. Rotation must be tested against the actual consuming system, not just against the secret store’s label changes.

Q: How do security teams reduce credential sprawl in AWS-first programmes?

A: They should inventory every secret, standardise naming, restrict retrieval to exact ARNs, and use scanning to catch hardcoded values before they spread. They also need a clear ownership model for each secret so the organisation can rotate and revoke without delay when a leak is detected.

Technical breakdown

Runtime secret retrieval and version labels

AWS Secrets Manager does not hand applications a secret from a file or environment variable by default. Applications call the service at runtime, receive the current version, and the service uses staging labels such as AWSCURRENT, AWSPENDING, and AWSPREVIOUS to track rotation state. That model reduces hardcoded credential exposure, but it also means identity policy and version handling become part of runtime architecture, not just storage administration. If the wrong version is promoted or the retrieval path is too broad, the secret store becomes a control plane for access rather than a passive vault.

Practical implication: Scope runtime retrieval to exact secret ARNs and validate version promotion logic before treating rotation as safe.

IAM policy scope and resource-based control

Secrets Manager access is governed through AWS IAM identity policies and, where used, resource-based secret policies. That combination is powerful because it allows a role to retrieve only the secret it needs, rather than everything in a namespace. The important detail is that least privilege is enforced at the secret ARN level, and broad wildcard patterns can silently expand blast radius. In practice, the service is only as narrow as the policy design around it, especially when multiple workloads share the same account or naming hierarchy.

Practical implication: Review secret ARNs, path naming, and policy wildcards together so GetSecretValue cannot drift beyond the intended workload.

Rotation workflows, Lambda steps, and rollback

Managed rotation in AWS Secrets Manager is a four-step workflow. A Lambda function creates a pending secret, applies it to the downstream system, tests it, and then promotes it to current. This is more than password change automation, because rotation only succeeds if the downstream system accepts the new credential without breaking service continuity. The AWSPREVIOUS label provides rollback, but the real risk is assuming rotation is complete when the application or database still relies on the old version. Single-user and alternating-users rotation differ mainly in how much operational disruption they tolerate.

Practical implication: Match the rotation strategy to the workload tolerance, and test downstream acceptance before enabling automated rotation in production.

Threat narrative

Attacker objective: The objective is to turn a single exposed secret into repeatable access across applications, environments, or cloud services.

1. entry via a leaked secret, exported credential, or command-line exposure rather than a direct service exploit.
2. credential abuse through broad GetSecretValue access, plaintext Terraform state, or over-permissive IAM scope.
3. impact through secret reuse, lateral movement, or service compromise after the credential is pulled into runtime use.

Breaches seen in the wild

• Dropbox Sign breach — compromised Dropbox Sign service account exposed API keys and OAuth tokens.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

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

NHI Mgmt Group analysis

Native secrets storage is not the same as secret governance. AWS Secrets Manager reduces manual exposure, but the article also shows how Terraform state, IAM policy scope, and rotation orchestration remain separate governance problems. The service can centralize storage while the programme still leaves secrets scattered across deployment state and recovery paths. The implication is that teams should treat the surrounding identity process as part of the secret surface, not as an optional layer.

Secret blast radius is still determined by policy design, not by storage location. A secret in AWS is safer than a hardcoded value, but least privilege only works when the ARN scope, path naming, and resource policies are narrow enough to match the workload. Broad policy patterns convert a managed vault into a high-value credential hub. Practitioners should evaluate where access scope is being inferred from convenience rather than from actual workload need.

Terraform state is an identity governance problem, not just an infrastructure hygiene issue. The article is explicit that plaintext state can retain secret values even when the secret itself sits inside AWS. That means the governance failure is persistence outside the vault boundary, which breaks assumptions about central control and audit completeness. The implication is that infrastructure teams must align secret lifecycle controls with their IaC workflow, not with the secret store alone.

Rotating a credential does not automatically rotate the trust relationship around it. Secrets Manager can replace the value, but downstream systems, cached credentials, and external integrations may still reflect the old trust state. That creates a familiar governance gap: the secret changes before the programme has verified that every consumer has actually shifted to the new identity state. Practitioners should distinguish value rotation from operational trust revalidation.

Secret sprawl remains the structural problem even when the platform is managed. The article points toward a world where AWS-native tooling is one layer, not the whole programme, especially once multi-cloud or cross-team access enters the picture. That is where central governance, lifecycle control, and audit consistency matter more than the storage primitive. The practitioner conclusion is to govern secrets as a population, not as isolated objects.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• Guide to the Secret Sprawl Challenge shows how fragmented secret stores and hardcoded credentials turn lifecycle control into an operational problem, not just a storage problem.

What this signals

Secret lifecycle discipline is now the differentiator between managed storage and managed risk. AWS-native secret storage helps only when teams can also prove ownership, rotation, offboarding, and policy scope across pipelines and environments. The broader signal is that secret sprawl is no longer a tooling issue alone, because even mature teams can carry leaked secrets for weeks before full remediation.

27 days to remediate a leaked secret is long enough for the trust boundary to collapse. When applications, CI systems, and shared credentials are all involved, one leaked value can outlive the review cycle that is supposed to contain it. That is why secrets governance has to be measured by revocation speed and scope containment, not by the mere presence of a vault.

Teams that standardise on runtime retrieval and exact policy scope will be better positioned for hybrid identity control. The same discipline that narrows AWS secret access also helps when human access, machine access, and workload identity have to be governed together. The programme signal is clear: secret management has become an identity architecture problem, not a storage decision.

For practitioners

• Audit Terraform state for secret persistence Check whether secret values, plan output, or data sources are leaving plaintext credentials in state backends or pipeline logs. Treat state storage as sensitive infrastructure and remove any workflow that allows production credentials to be written there.
• Tighten secret ARN scope and policy wildcards Review every GetSecretValue permission for exact secret ARNs, narrow path prefixes, and any wildcard patterns that could expand access across services or environments. Pair identity-based policies with resource policies only where the extra control is needed.
• Separate rotation strategy from business tolerance Use alternating-users rotation for services that cannot absorb connection blips, and validate that Lambda-based rotation steps succeed against the downstream system before promoting a new version. Do not assume a successful label change means every consumer is using the new secret.
• Add secret scanning to every code and build path Scan repositories, CI logs, and deployment artifacts so leaked credentials are found before they are reused outside the intended trust boundary. Tie findings back to owner, environment, and revocation workflow so response time does not drift into multi-week remediation.

Key takeaways

• AWS Secrets Manager improves secret handling, but it does not remove the governance burden around access scope, Terraform state, or downstream trust.
• The evidence points to a recurring pattern where leaked secrets stay live too long, making revocation speed and policy precision more important than storage convenience.
• Teams should treat secrets as a governed identity population and align retrieval, rotation, scanning, and offboarding with the rest of their IAM programme.

Key terms

• Secrets Manager: A managed secret store keeps credentials, API keys, and tokens in one place and serves them at runtime rather than hardcoding them into applications. In practice, its security depends on encryption, policy scope, versioning, and rotation working together across the full identity lifecycle.
• Staging Label: A staging label is a pointer to a secret version, such as current, pending, or previous. It lets secret rotation move traffic from one credential value to another without changing the secret name, which makes rollback and controlled promotion possible.
• Terraform State: Terraform state is the record of infrastructure that Terraform keeps so it can compare desired and actual configuration. For secrets, state becomes sensitive because values can be stored in plaintext, which means infrastructure automation can unintentionally become a secret retention layer.
• Alternating-Users Rotation: Alternating-users rotation is a credential rotation pattern that uses two accounts so one can stay live while the other is changed in the background. It reduces service disruption, but it still requires accurate downstream configuration and careful control over which account is active.

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 AWS Secrets Manager setup patterns for console, CLI, and Terraform workflows
• Rotation configuration details for single-user versus alternating-users strategies
• Pricing mechanics and cost control considerations for large secret populations
• Product-specific comparison points for teams deciding when AWS-native secrets management is enough

👉 Infisical's full post covers implementation steps, rotation trade-offs, and pricing considerations in more depth

Deepen your knowledge

NHI governance, agentic AI identity, machine identity security, IAM, and workload identity security 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 programme maturity, it is worth exploring.