The secrets manager often enters the roadmap as a “quick win”: passwords and tokens are migrated out of the repository and out of environment variables, it is pointed to a Key Vault/Secrets Manager, and the chapter is considered closed. That’s where the trap appears: confusing storing secrets with operating them securely.
The set-and-forget syndrome is not usually bad faith; it is pressure to deliver, fear of breaking deployments, and lack of clear ownership between platform, security, and product teams. The typical result is a central store set up “well,” but with broad permissions, manual (or non-existent) rotation, and auditing that no one looks at… until the incident.
What went wrong: when the Key Vault becomes a single point of failure
The pattern repeats in companies: a single vault is created per account/subscription/project, dozens or hundreds of secrets are uploaded, and to avoid startup errors generic permissions are granted. In AWS it shows up as policies with secretsmanager:GetSecretValue on *; in Azure, identities with broad access to the vault’s secrets; in GCP, service accounts with roles/secretmanager.secretAccessor at too large a scope. It works… until a compromised workload can read “everything.”
The real consequence is not theoretical: a single Lambda/Function/Cloud Run with RCE or leaked credentials stops being “a service down” and becomes a credential extractor at scale. The vault becomes the attacker’s accelerator: with mass read permissions, enumeration and exfiltration are a matter of minutes.
Also, many secrets are stored as-is (plain text) assuming that “it’s already encrypted.” Yes, the service encrypts at rest, but that does not replace minimal access controls or rotation. If IAM allows reading it, the secret comes out in cleartext because that is the purpose of the service. The mistake is assuming backend encryption compensates for excessive privileges.
The most expensive confusion: believing the secrets manager “encrypts access” at the network level
I have seen organizations assume that “since it’s in Key Vault, nobody outside the VNet/VPC touches it.” In reality, network control depends on how the service is consumed: private endpoints, firewall restrictions, routes, and access conditions. If the team doesn’t configure it, the secret will still be accessible from anywhere a valid identity can authenticate.
In day-to-day work, friction appears when an application fails to start because it can’t list or read a secret. The typical reaction is to open permissions until it stops failing. The problem is that many SDKs and libraries try to list to discover names, or make validation calls that lead to granting List and Get indiscriminately. The “fix” is fast, but the blast radius grows silently.
- List permission as a door to enumeration
When you enable “list everything,” you make it easier for any identity with access to discover what exists: secret names, conventions (prod/dev), even hints about third parties (for example, stripe_live, db_admin). In an incident, that enumeration saves time and reduces attacker noise.
- Access without network guardrails
If you don’t use network controls (depending on the provider and the service), the “perimeter” becomes IAM again. In companies with distributed identities (many service accounts, many functions), a compromised credential from a development machine can turn into access to production secrets if the scope is poorly bounded.
Rotation: what is promised in design and what is operated in reality (AWS, Azure, GCP)
Automatic rotation is the point where set-and-forget is most noticeable. In presentations it is assumed “we will rotate every 30/60/90 days,” but in production the secret depends on a backend (RDS, a third-party API, a user in an LDAP) and you have to orchestrate the change without taking services down. If no one is responsible for that integration, rotation becomes a manual task… that gets postponed.
In AWS, the typical mechanism relies on a Lambda-based rotation (a rotator) and a rotation schedule in Secrets Manager. That works well when the secret corresponds to a system where you can create new credentials, verify, promote, and revoke. But it requires code, minimum permissions to modify the backend, and rollback tests. If the team “only uploads the secret” and does not implement the rotator, there is no magic.
In Azure, Key Vault supports rotation policies for secrets when there is an integrated or automated renewal mechanism, but the operational value is in the organization defining which secrets are rotatable, how the new value is validated, and who responds if renewal fails. In GCP, Secret Manager can schedule rotation, but again real rotation depends on there being a process that generates the new secret and updates consumers without outages. In all three cases, the typical corporate failure is to enable the “schedule” without completing the circuit of updating the backend and the application.
- Early signal: rotation configured but with no evidence of successful executions
It is common to see “nice” schedules with no traces of effective rotations, or with recurring failures ignored. If there is no periodic review of executions and alerts, the schedule becomes a placebo.
- Early signal: “eternal” secrets for critical integrations
Third-party tokens, database credentials, or service keys that do not change for months/years are usually the symptom that the operational process does not exist. When a leak happens, there is no rapid response capability because rotating “breaks things” and no one has rehearsed it.
How to do it in practice: limit reads by tags, and prove it with auditing
The most cost-effective improvement is usually to reduce scope without re-architecting: move from “any workload can read any secret” to “each workload only reads the secrets for its application/environment.” The most pragmatic technique in enterprises is to base it on labels/tags (and consistent naming conventions) and apply guardrails in IAM/policies so that the runtime identity can only access secrets with the expected tags.
This also avoids the classic argument of “if I don’t grant broad permissions, something will fail”: if you define a simple contract (mandatory tags per app and environment) and automate it in CI/CD, the system fails explicitly and fixably, not with permanent excessive permissions.
Operational example (AWS IAM) with tag-based control for a Lambda/Role that should only read secrets for its application and environment:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ReadOnlyTaggedSecrets",
"Effect": "Allow",
"Action": [
"secretsmanager:GetSecretValue",
"secretsmanager:DescribeSecret"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"secretsmanager:ResourceTag/app": "billing-api",
"secretsmanager:ResourceTag/env": "prod"
}
}
},
{
"Sid": "DenyListingToReduceEnumeration",
"Effect": "Deny",
"Action": [
"secretsmanager:ListSecrets"
],
"Resource": "*"
}
]
}In practice, this pattern forces secrets to be correctly tagged and prevents a service from “discovering” others’ secrets. If an application needs List due to library behavior, the remedy should not be to open global List; it is usually to pin the secret name/ARN in configuration, or to encapsulate resolution in a controlled internal layer.
Validation and auditing (last 90 days): what changes the game is proving who read what. In AWS, review CloudTrail events associated with GetSecretValue and DescribeSecret and correlate by role/service account; in Azure, review Key Vault diagnostic logs (secret operations) in Log Analytics; in GCP, filter Cloud Audit Logs for access to Secret Manager. If you can’t answer in an hour “which identities have accessed this secret in 90 days,” the vault is in set-and-forget mode.
Recommendations for corporate environments
The Key Vault trap is not technological: it is operational. The secrets manager protects storage, but it does not compensate for massive permissions, lack of rotation, and the belief that the network is “encrypted” or “closed” by default. When access is expanded to avoid startup failures, the vault becomes the impact multiplier for any identity compromise.
To get out of the set-and-forget syndrome, the focus has to be on three evidences: minimal read scopes (ideally by tags/project/environment), rotation that actually runs and is monitored, and usable (queryable) auditing of at least 90 days of access. If those three pieces are alive, the secrets manager becomes a security control again; if not, it’s just another place to store plain text with good UX.
Interested in Cloud Security?
Technical analysis, hands-on labs and real-world cloud security insights.