TL;DR: Teams often need broader access and lifecycle controls than a single cloud secret store can provide, especially when managing secrets, just-in-time access, and auditability across mixed infrastructure, according to StrongDM. Secrets governance breaks when access, rotation, and offboarding are treated as separate problems rather than one lifecycle.
At a glance
What this is: This article compares Google Cloud Secret Manager with alternatives and concludes that secrets governance weakens when teams need broader access, lifecycle, and audit control across heterogeneous infrastructure.
Why it matters: It matters because IAM, PAM, and NHI programmes fail when secrets are managed as isolated storage objects instead of governed identities with lifecycle, privilege, and offboarding controls.
Context
Secrets management is not just about storing values securely. When teams manage API keys, passwords, certificates, and tokens across cloud services, servers, databases, and Kubernetes, the control problem becomes lifecycle governance, not simple vaulting.
This article argues that Google Cloud Secret Manager fits a narrower Google Cloud use case, while broader infrastructure often needs integrated access controls, just-in-time access, and auditability. That is an NHI and privileged access problem as much as a storage problem.
Key questions
Q: What breaks when secrets are hard-coded or left in public storage?
A: Hard-coded or publicly stored secrets turn a runtime credential into persistent data that can be copied, indexed, and reused long after the original team forgets it exists. The control fails because disclosure and propagation happen faster than revocation, so one leak can become many access paths.
Q: Why do cloud environments create more secrets risk than traditional datacenters?
A: Cloud environments multiply machine identities across apps, containers, pipelines, and services, so the number of credentials grows faster than manual control processes. That expansion increases the chance of stale, duplicated, or exposed secrets. Traditional access models were built for slower, more centralized environments and are less effective when credentials are created and consumed dynamically.
Q: How should teams know whether secret zero governance is working?
A: Secret zero governance is working when every bootstrap credential is inventoried, ownership is clear, rotation is routine, and offboarding removes access paths promptly. If teams cannot answer where the credential lives or who can use it, the programme is already operating with hidden exposure.
Q: What is the difference between secrets management and access management for workloads?
A: Secrets management stores and rotates credentials. Access management decides whether a workload should receive access, under what conditions, and for how long. The first protects the secret itself, while the second governs the runtime decision that determines whether the secret should exist in the first place.
Technical breakdown
Why secrets storage and access governance diverge
A secret store holds credentials, but it does not by itself govern who can use them, how long they remain valid, or whether access is still appropriate after a role change. In practice, secrets management spans issuance, retrieval, rotation, logging, and revocation. When those controls live in separate tools, teams can secure the vault while still leaving privilege creep, stale access, and weak offboarding in place. That is why a single cloud-native secret repository often stops short of end-to-end governance for mixed environments.
Practical implication: Treat secret storage and secret access as one lifecycle control surface, not two separate operational problems.
Just-in-time access changes the risk model for NHI credentials
Just-in-time access reduces standing privilege by issuing credentials only when a task requires them. That matters because API keys, service credentials, and temporary access paths are often the real blast-radius multiplier in cloud operations. If a team can only store secrets centrally but cannot time-box usage, it still has standing access risk. PAM-style controls are therefore the governance layer that determines whether a secret is merely protected at rest or actually constrained in use.
Practical implication: Use JIT and least privilege to limit how long an NHI credential can be active after it is retrieved.
Why auditability matters more in mixed infrastructure
Mixed estates usually include cloud services, databases, applications, and on-prem or clustered systems, each with different secret lifecycles and logging expectations. A secret manager that only covers one cloud domain can leave gaps in visibility across the rest of the stack. Auditability becomes the key control because teams need to know who accessed which credential, when, and for what resource. Without that trace, compliance reviews and incident investigations both lose evidentiary value.
Practical implication: Centralise logs and access records across all secret-consuming systems, not just the primary vault.
Breaches seen in the wild
- DeepSeek database exposure 2025: An unauthenticated DeepSeek ClickHouse database exposed over a million log lines with plaintext chat history and API keys in 2025.
- Hugging Face Spaces breach 2024: Unauthorised access to Hugging Face Spaces may have exposed secrets users stored for AI apps; tokens were revoked and org tokens removed.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Secrets governance fails when teams mistake storage for control. A vault can protect the value of a secret and still leave the organisation exposed if issuance, usage, rotation, and revocation live elsewhere. That split creates hidden risk because the lifecycle is what determines whether a credential remains trustworthy. Practitioners should judge secret platforms by governance reach, not just secure storage features.
Google Cloud Secret Manager alternatives are really about scope, not preference. The article’s core point is that broader infrastructure often needs access mediation across servers, databases, applications, and Kubernetes, not just a repository for cloud-native secrets. Once secrets become part of heterogeneous operations, the governance question shifts to who can use the credential and under what conditions. That is why access management and secrets management increasingly converge.
Standing privilege is the real structural problem in secrets programmes. A stored secret that can be reused indefinitely creates the same governance weakness as any persistent credential. Short-lived, task-scoped access changes the control model because the secret is no longer a durable entitlement. Practitioners should treat persistent secret reuse as a privilege design flaw, not merely an operational convenience.
Identity lifecycle and secret lifecycle are the same discipline applied to different objects. Offboarding a human, revoking a service account, and retiring a credential all depend on the same governance logic: access must end when the need ends. The article points toward a broader control model in which secrets are not treated as isolated assets but as identities with use, audit, and retirement rules. Practitioners should align secret governance with lifecycle governance across the stack.
Multi-cloud and mixed-environment reality makes single-vault thinking brittle. When organisations rely on one secret manager for one cloud but operate across several platforms, they create control fragmentation. The result is usually inconsistent logging, uneven rotation cadence, and unclear ownership of revocation. Practitioners should evaluate whether their current model can still answer basic governance questions once the environment stops being cloud-homogeneous.
From our research library:
- DeepSeek alone generated 113,000 new exposed API keys in 2025, illustrating how new AI providers create credential exposure before security guardrails catch up, according to the State of Secrets Sprawl 2026.
- 43% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases, according to the State of Secrets in AppSec.
- Read next: API Key Management Guide
What this signals
Ephemeral credential trust debt: the more often teams rely on temporary secrets without lifecycle governance, the more they accumulate hidden trust assumptions about who can reuse, forward, or recover those credentials. The practical signal is that retrieval controls must be evaluated alongside revocation controls, because the risk lives in the gap between issuance and retirement.
Google Cloud-centric secret stores are useful, but they do not erase the identity problem that surrounds every credential. The reader takeaway is to test whether their programme can answer the ownership question, the rotation question, and the offboarding question for every secret, regardless of where it sits.
For practitioners
- Map every secret to an owner and lifecycle Inventory API keys, passwords, certificates, and tokens by system owner, business purpose, rotation interval, and offboarding trigger so no credential exists without a governance accountable party.
- Move high-risk access to just-in-time issuance Use task-scoped access for administrators and service workflows where persistent credential reuse creates unnecessary standing privilege, especially in mixed cloud and infrastructure estates.
- Unify audit trails across secret-consuming systems Correlate retrieval, usage, and revocation events across the secret store, identity system, and target workload so access reviews can validate actual use rather than assumed entitlement.
- Set separate rotation rules for durable and ephemeral secrets Define different handling for long-lived application credentials, temporary access tokens, and platform-generated secrets so one policy does not under-protect or over-rotate the entire estate.
Key takeaways
- Secrets governance fails when teams separate storage, access, and offboarding into different workflows, because the credential lifecycle is where risk accumulates.
- Broader estates with servers, databases, applications, and Kubernetes need access mediation and auditability, not just a single cloud-native secret repository.
- The strongest control model treats secrets as governed identities with ownership, rotation, and revocation rules that travel with the workload.
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | The article centres on excess secret access across cloud and mixed infrastructure. |
| NHI-07 — Long-Lived Secrets | The article contrasts persistent secrets with just-in-time and temporary access patterns. | |
| Recommendation — Reduce standing secret use by constraining NHI access to the minimum required scope. Shorten credential lifetime and eliminate secrets that remain valid beyond the task that needs them. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The piece discusses secret rotation, revocation, and lifecycle control for credentials. |
| Recommendation — Apply authenticator lifecycle controls to rotate, revoke, and retire secrets on a defined schedule. | ||
| CIS Controls v8 | CIS-5 — Account Management | Offboarding and access review concerns map to account and credential governance. |
| Recommendation — Tie secret offboarding to account management so access ends when ownership or need changes. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article focuses on controlling who may use secrets and under what conditions. |
| Recommendation — Review and limit secret entitlements so access remains aligned to current business need. | ||
Key terms
- Secrets Governance: Secrets governance is the discipline of controlling where credentials are stored, who can use them, how long they remain valid, and how they are removed. It links discovery, rotation, offboarding, and auditability so that a secret does not outlive the legitimate need for access.
- Just-in-Time Access Request: Just-in-Time Access Request is a pattern that grants access only when it is needed and only for the duration required. It reduces standing privilege by making access temporary, policy driven, and task scoped. This approach is especially useful for contractors, sensitive systems, and short-lived operational work.
- Standing Privilege: Standing privilege is access that remains active even when no immediate task requires it. For NHI programmes, it is a common failure mode because long-lived credentials and persistent roles create unnecessary exposure. Reducing standing privilege usually means tighter expiry, on-demand access, and clearer review of who or what still needs access.
- Off-boarding: Off-boarding is the process of removing a departing user’s access, credentials, and related entitlements from the environment. In mature IAM programmes, it also includes reviewing sessions, shared secrets, delegated roles, and linked non-human identities so that exit events do not leave behind hidden access paths.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle 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.
Published by the NHIMG editorial team on June 7, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org