TL;DR: Google Cloud Secret Manager gives GCP teams versioned, IAM-governed storage for database passwords, API keys, and OAuth tokens, but its rotation is notification-only and its replication choices are immutable, according to Infisical. The real governance issue is that secrets management still depends on lifecycle discipline, per-secret access design, and external tooling once teams move beyond a single cloud.
At a glance
What this is: This is an analysis of Google Cloud Secret Manager as a GCP-native secrets service, with the key finding that its governance model is strong inside Google Cloud but breaks down around immutable replication, notification-based rotation, and multi-cloud use.
Why it matters: It matters because IAM teams need to know where native secret management ends and where lifecycle, rotation, and cross-environment governance have to be owned elsewhere for NHI and workload access.
Context
Google Cloud Secret Manager is a managed secrets store for database passwords, API keys, OAuth tokens, and other sensitive values, with access controlled through GCP IAM and every access recorded in Cloud Audit Logs. The governance question is not whether it stores secrets securely, but whether its access, replication, and rotation model still fits when secret estates grow.
The article’s main point is that GCP-native secret storage solves the first layer of secrets sprawl, then creates new operational decisions around versioning, immutable replication policy, and notification-based rotation. For IAM and NHI practitioners, that shifts the problem from storage to lifecycle control, blast-radius management, and cross-platform governance.
Key questions
Q: Where does Google Cloud Secret Manager fail as a governance model at scale?
A: It fails when teams assume a native GCP store can also solve lifecycle, rotation, and multi-cloud governance. The service stores and versions secrets well, but replication is immutable, rotation is notification-only, and external workloads still need another access model. That combination makes the control plane narrower than many teams expect.
Q: Why do overbroad API permissions increase breach risk so quickly?
A: Because an authenticated caller may still receive data or functions it never needed. When object-level and field-level access are not constrained, a compromise of one token or service account can expose far more than the original request should have allowed.
Q: How should teams handle rotation when Secret Manager only sends notifications?
A: They should treat rotation as an orchestrated workflow, not a built-in action. That means the notification triggers code or automation that creates a new credential, updates the dependent database or service, and writes the new version back. Without that workflow, the schedule exists but the credential does not change.
Q: What is the practical difference between Secret Manager and a broader secrets governance layer?
A: Secret Manager is a GCP-native store for secrets, while a broader governance layer handles workflows that span clouds, teams, and approval states. The difference is not just storage. It is whether access review, rotation ownership, and audit remain unified once workloads move outside one cloud.
Technical breakdown
Versioning and secret states in Google Cloud Secret Manager
Secret Manager stores the secret value in numbered versions, while the secret itself is a container. That lets teams keep auditability and roll back safely, but it also means every update creates another billable and governable object. Versions can be enabled, disabled, or destroyed, and disabling before destruction gives teams a reversible checkpoint when a credential may still be in use. The operational trap is version accumulation, because frequent rotation can leave many active versions behind unless teams actively retire them. This is a lifecycle control problem as much as a storage problem.
Practical implication: Track secret version state explicitly and disable stale versions before destruction so rotation does not turn into version sprawl.
IAM scoping and least privilege for GCP secrets
Access to Secret Manager is governed through IAM, usually via roles/secretmanager.secretAccessor. The key design choice is scope: project-level binding makes a service account eligible to read every secret in the project, while secret-level binding confines access to one credential and one workload. That matters because Secret Manager is often used for production database passwords, API keys, and tokens where one overbroad binding increases blast radius immediately. In governance terms, this is classic entitlement design, but the object being protected is a secret rather than an application resource. Audit logs help, but they do not compensate for excessive access scope.
Practical implication: Bind secretAccessor at the individual secret level for production credentials and review project-level grants as an exception path only.
Notification-based rotation versus managed rotation
Google Cloud Secret Manager does not perform the credential change itself. It publishes a rotation notification on schedule, and the team must build the downstream automation that creates the new credential, updates dependent systems, and writes the new version back. That is a very different operating model from turnkey rotation, because the hard part is not scheduling but orchestration across the dependent service, the secret store, and any workload consuming the secret. The article also notes that this becomes brittle as secret counts and service diversity increase. Rotation therefore remains a governance workflow, not a button.
Practical implication: Treat rotation as an external workflow with ownership, retry logic, and downstream update steps, not as a native Secret Manager feature.
Threat narrative
Attacker objective: The attacker aims to reuse a leaked or overexposed secret to reach adjacent cloud resources and expand access beyond the intended workload boundary.
- Entry occurs through overbroad access to a secret or by keeping a credential in locations that Secret Manager was meant to replace, such as config files or shell history.
- Credential access is then amplified when secretAccessor is granted too widely or when long-lived versions remain available after they should have been retired.
- Impact follows when a compromised service account or exposed secret can reach downstream databases, APIs, or cloud services with more privilege than the workload actually needs.
Breaches seen in the wild
- Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.
- Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.
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
Immutable replication policy is a governance decision, not a convenience setting. Once a secret is created in Google Cloud Secret Manager, its replication choice cannot be changed. That makes the initial decision a compliance and cost boundary, not a later optimisation. Teams that treat replication as reversible end up discovering that residency requirements and regional cost assumptions were fixed at creation time. The practitioner conclusion is simple: the first replication decision has lifecycle consequences.
Secret-level scoping is the real blast-radius control in GCP-native secrets governance. Project-wide secret access creates a hidden entitlement model where one service account inherits every credential in the project. Secret Manager’s design supports least privilege, but only if teams bind access to individual secrets and keep production credentials isolated by workload. This is where IAM practice and secrets governance meet: the secret is the asset, but the entitlement is still the attack surface.
Notification-only rotation creates an external dependency chain that many teams underestimate. Secret Manager schedules the event, but the real rotation workflow lives in Cloud Function or Cloud Run logic, downstream service updates, and version management. That means the governance problem is not merely secret expiry, but the reliability of the automation that replaces the credential everywhere it matters. The practitioner conclusion is to treat rotation as a distributed process with failure points, not a storage feature.
Cross-cloud secrets governance is where native secret storage stops being a complete programme. GCP-native secrets work well inside one cloud, but the moment a team also runs AWS, Azure, on-premises, or SaaS workloads, the operating model fragments into parallel stores and separate audit paths. Secrets governance gap: the assumption that one cloud provider can remain the source of truth fails as soon as access spans multiple execution environments. The practitioner conclusion is that a unified lifecycle model becomes a programme requirement, not a tooling preference.
Cloud Audit Logs record access, but they do not close the lifecycle gap. Logging shows who read which secret and when, yet it does nothing to constrain version sprawl, reduce overbroad IAM bindings, or replace the rotation logic teams must maintain themselves. The governance lesson is that observability is necessary but not sufficient. Practitioners need to distinguish evidence of access from control of access, because the two are not the same thing.
From our research library:
- The average enterprise SaaS platform connects to 42 or more third-party applications through OAuth tokens, API keys, webhooks and automation platforms.
- Read next: NHI Lifecycle Management Guide
What this signals
Secrets governance becomes a lifecycle problem once a team leaves a single cloud boundary. Secret storage can be centralised inside Google Cloud, but the access model fragments quickly when the same organisation also runs other clouds, on-premises systems, or SaaS workflows. The next control question is not where the secret lives, but whether the organisation can still govern its issuance, use, and retirement consistently.
Rotation workflows now matter more than secret storage features. In practice, the hardest part is not saving a new value but coordinating the dependent service, the consuming workload, and the retired version without creating outages. Teams that cannot describe ownership for that sequence do not really have rotation governance, only rotation intent.
For practitioners
- Bind secret access at the secret level Grant roles/secretmanager.secretAccessor only on the specific secret a workload needs, and treat project-level grants as temporary exceptions that require review.
- Design replication before creating the secret Choose automatic, user-managed, or regional replication up front, because the replication policy is immutable and affects residency, latency, and cost.
- Build rotation as an owned workflow Use Pub/Sub, Cloud Function, or Cloud Run to generate the new credential, update downstream systems, and write the new secret version with retries and ownership assigned.
- Remove stale versions deliberately Disable versions before destroying them, then clean up old versions that remain billable or still reachable through workflows that were never updated.
- Separate GCP-native and cross-cloud secret governance Map which workloads can rely on Secret Manager alone and which need a broader lifecycle layer for multi-cloud access, approval, and unified audit.
Key takeaways
- Google Cloud Secret Manager reduces secret sprawl inside GCP, but its governance model still depends on how teams scope access, manage versions, and handle replication decisions.
- The article’s core operational tension is that rotation and cross-cloud use remain outside the native control plane, which is where many programmes lose consistency.
- Practitioners need to treat Secret Manager as one layer in a broader secrets lifecycle model, not as a complete answer to NHI governance.
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, NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article centres on exposed API keys, OAuth tokens, and secret handling paths. |
| NHI-05 — Overprivileged NHI | Project-level secret access expands blast radius beyond the workload that needs the secret. | |
| NHI-07 — Long-Lived Secrets | The article discusses version retention and the need to retire stale secret versions. | |
| Recommendation — Scan for secret leakage in configs, shell history, and pipelines, then revoke any exposed credential immediately. Scope NHI access to the individual secret or workload instead of granting broad project-wide permissions. Retire stale secret versions and shorten credential lifetime wherever rotation creates overlapping exposure. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Secret rotation and credential lifecycle are directly governed by authenticator management. |
| Recommendation — Apply IA-5 to manage secret issuance, rotation, and retirement as a controlled lifecycle. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Least-privilege secret access and entitlement scope are central to the article. |
| Recommendation — Review entitlements so secret access stays aligned to the minimum workload requirement. | ||
| CIS Controls v8 | CIS-5 — Account Management | Service account scoping and secret lifecycle ownership are account-management problems at scale. |
| Recommendation — Govern service and workload accounts as part of secret lifecycle management and entitlement review. | ||
Key terms
- Secret Versioning: Secret versioning is the ability to retain previous credential states after an update or rotation. It is useful for rollback and troubleshooting, but it also creates governance requirements for who can see historical values and when older versions are purged.
- Secret-Level IAM Binding: Secret-level IAM binding grants access to one specific secret rather than to every secret in a project or folder. For workload identity and NHI governance, this is the clearest way to keep blast radius tied to a single credential and a single application boundary.
- Notification-Based Rotation: Notification-based rotation is a model where the secret store emits an event telling another system to perform the actual credential change. It separates scheduling from execution, which makes ownership, retries, and downstream updates part of the control design rather than a built-in service feature.
- Replication policy: Replication policy defines where a secret is stored and how it is distributed across regions. In Google Cloud Secret Manager, this is a one-time design choice that affects residency, resilience, and compliance. The policy is not just an availability setting. It is part of the secret's governance posture and can force future rebuilds if chosen poorly.
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 July 8, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org