AWS Secrets Manager vs Parameter Store for secrets governance

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Infisical's blog post: AWS Secrets Manager and Parameter Store solve different governance problems, with rotation and cross-account sharing driving the split more than basic secure storage.

Why it matters: IAM and security teams need to decide where credentials, configuration, and lifecycle controls belong before scale creates fragmented secret ownership and audit overhead.

Context

AWS gives teams two different places to store sensitive values, but the governance problem is not identical in each. One service is designed around credentials that need rotation and tighter access control, while the other is a general configuration store that can also hold secrets through encryption.

The practical issue is lifecycle, not storage. Once teams spread values across accounts, environments, and use cases, the question becomes which values need automatic rotation, which can be managed manually, and how to keep a defensible inventory of where each secret lives.

Key questions

Q: When should teams use a secrets manager instead of a parameter store?

A: Use a secrets manager when the value is a credential that needs automatic rotation, tighter access control, or direct cross-account sharing. Use a parameter store for configuration values and lower-risk secrets when you can manage rotation manually or do not need it. The decision should follow lifecycle need, not convenience.

Q: What breaks when secrets are split across multiple AWS stores?

A: The immediate break is governance visibility. Teams lose a single inventory, separate audit trails emerge, and ownership becomes harder to prove when values live in different services for different reasons. That is usually when the problem shifts from storage choice to lifecycle management and access review.

Q: How do cross-account secret sharing models affect access governance?

A: They change how revocation and accountability work. A direct secret policy gives clearer control over who can use the secret, while resource-sharing approaches add another layer to manage and review. In practice, the sharing model should match the organisation’s audit and offboarding expectations.

Q: Should teams use both AWS services deliberately or standardise on one?

A: Both can be the right answer when the split is intentional and governed. Standardise on one only if your environment is small, simple, and not dependent on differing rotation or sharing requirements. Otherwise, use both with a clear classification rule so the split does not become unmanaged drift.

Technical breakdown

Rotation is the real dividing line between the two services

AWS Secrets Manager is purpose-built for secrets that need ongoing credential lifecycle management. Its built-in rotation support, including Lambda templates for common databases, means the service is opinionated about secret turnover rather than just storage. Parameter Store can hold sensitive values as SecureString entries encrypted with KMS, but it does not provide native rotation. That makes it better suited to configuration values or secrets where the rotation process is owned elsewhere. The architectural difference is not encryption, because both can encrypt. It is whether the platform is taking responsibility for the secret’s lifecycle after write time.

Practical implication: Use the service that matches the lifecycle burden, not the one that merely stores the value securely.

Cross-account sharing changes the governance model

Secrets Manager supports resource policies on a secret, which means the secret itself can be shared directly across AWS accounts. Parameter Store is more constrained: only advanced-tier parameters can be shared cross-account, and that happens through AWS Resource Access Manager rather than a direct resource policy on the parameter. That distinction matters because sharing mechanism determines who can govern, audit, and revoke access. When access is policy-driven at the secret level, accountability is clearer than when sharing is routed through a separate resource-sharing construct. In multi-account environments, this can become the deciding factor for where a credential belongs.

Practical implication: Map cross-account credential distribution to the service whose sharing model matches your audit and revocation needs.

Scale turns split storage into a lifecycle problem

The article’s central point is that most teams end up using both services deliberately. Parameter Store handles lower-risk configuration values, while Secrets Manager is reserved for values that need rotation or sharing across accounts. That split works until it becomes a governance burden in its own right, because then teams no longer have one inventory, one review process, or one ownership model. At that point the challenge is not AWS storage choice. It is whether secret classification, ownership, and rotation cadence are governed consistently across environments and accounts.

Practical implication: Treat the split as an inventory and governance control, not just an architecture preference.

Breaches seen in the wild

• Toyota T-Connect key exposure 2022: A subcontractor left a T-Connect server key on public GitHub from 2017 to 2022; 296,019 customers' emails were exposed, misuse unknown.
• Rabbit R1 hard-coded API keys 2024: Rabbit R1 source code leaked by an employee held working ElevenLabs, Azure, Yelp and Google Maps API keys; an email key was misused, Rabbit says.

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 governance breaks when storage choice becomes a proxy for lifecycle design. The article shows that the important distinction is not secure storage, but whether a value needs rotation, cross-account sharing, and different review expectations. Once teams mix those requirements into one bucket, the governance model loses precision. Practitioners should classify secrets by lifecycle first, then decide storage.

Split-brain secret management is a control plane problem, not a tooling problem. Using two AWS-native services can be perfectly rational, but it creates dual inventories, dual access paths, and dual audit trails. That duplication is manageable at small scale and brittle at larger scale. The implication is that the governance layer must track ownership and purpose, not just destination.

Cross-account access is where ownership becomes visible. If a secret can be shared directly through a resource policy, the governance story is clearer than when sharing depends on a separate resource-sharing mechanism. That matters because access review, revocation, and exception handling all depend on knowing who controls the object. Security teams should treat distribution method as part of the identity decision, not an implementation detail.

Rotation should be reserved for values whose risk profile justifies it. The article makes a strong case that automatic rotation is not universally required and not universally free. Applying it everywhere can add cost and operational overhead without improving governance for low-risk configuration. The practical conclusion is to align rotation with credential criticality, not with storage convenience.

Per-value classification is the right operating model for mature IAM teams. Small organisations may start with one store, but larger environments eventually need a repeatable decision rule for every value. That rule should answer whether the item is configuration, credential, or shared secret, and whether its lifecycle is managed manually or automatically. Practitioners should standardise that classification before the estate fragments further.

From our research library:

• Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control, according to the State of Secrets in AppSec.
• Enterprises manage far more machine secrets than human ones: 20 times as many according to Enterprise Strategy Group, and 45 times according to GitGuardian.
• Read next: Guide to the Secret Sprawl Challenge

What this signals

Secret governance debt grows when teams treat storage destinations as interchangeable. The important programme question is not where a value sits, but whether its lifecycle is explicit, owned, and reviewable across accounts and environments. That is why secret classification has to precede storage standardisation.

Per-value governance is the only scalable model for mixed AWS estates. Once configuration, credentials, and shared secrets all live in different places, teams need a consistent rule for deciding where rotation, review, and offboarding live. Without that rule, the estate drifts into exceptions faster than audits can reconcile them.

For practitioners

• Classify every stored value by lifecycle criticality Separate low-risk configuration values from credentials that require rotation or cross-account sharing, then assign a storage path based on that classification rather than defaulting everything into one service.
• Reserve automatic rotation for true credentials Use rotation for database passwords, API credentials, and other secrets whose exposure window must be shortened, and do not pay the operational cost for values that never need it.
• Document cross-account sharing decisions Record which secrets are shared through resource policies and which parameters depend on resource sharing so revocation, ownership review, and exception handling stay auditable.
• Build a single inventory across services Track secrets and configuration values across both AWS stores so teams can see where each item lives, who owns it, and whether it is governed by rotation or manual control.

Key takeaways

• The core risk is not that one AWS store is insecure and the other is safe. The risk is that mixed use cases create fragmented ownership, inconsistent rotation, and unclear audit scope.
• The article shows that the split becomes harder to manage as environments grow across accounts and values multiply. At that point, the storage decision itself becomes part of the governance workload.
• The practical answer is to classify values by lifecycle need, then place rotation-sensitive credentials and shared secrets under the control model that matches them.

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.
• Parameter Store: AWS Systems Manager Parameter Store is a general-purpose configuration store that can also hold sensitive values using encryption. It works well for feature flags, endpoints, and low-risk secrets, but it does not provide the same native rotation or credential-first governance model.
• Cross-Account Access: Cross-account access is a trust relationship that allows a principal in one account to reach resources in another account. It is often necessary for operations, but without tight scope and review it becomes one of the most common paths for unintended NHI exposure.
• Secret Classification: Secret classification is the practice of assigning context to a credential based on sensitivity, environment, owner, and business purpose. It helps security teams decide how tightly to protect, monitor, and retire each secret instead of applying one uniform policy to all access.

Deepen your knowledge

NHI governance, identity lifecycle management, and secrets management 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.