GCP service account governance at scale for 40,000 identities

At a glance

What this is: This case study shows how one insurance provider brought 40,000+ GCP service accounts under governance by eliminating static keys, automating rotation, and centralising visibility across 1,000+ projects.

Why it matters: It matters because service accounts without ownership, rotation, and rightsizing become durable access paths that IAM, IGA, and cloud teams must govern together, not as separate workstreams.

By the numbers:

• The service account estate was growing at 5% monthly before governance changes.

👉 Read P0 Security's analysis of GCP service account governance at scale

Context

GCP service account governance is the discipline of discovering, owning, reviewing, and reducing machine identities that can authenticate into cloud resources. In this case, the problem was not just scale but accumulated exception handling: thousands of service accounts grew across more than 1,000 projects while ownership, key handling, and permission scope drifted away from control.

The governance gap was operational, not theoretical. Static keys supported third-party integrations, but those same keys created long-lived access paths that manual reviews could not keep up with, especially when visibility was fragmented across projects and tools.

For IAM and NHI teams, the important signal is that cloud-native scale exposes lifecycle weaknesses first. Once service-account governance depends on one-off effort, the control plane stops matching the actual identity estate.

Key questions

Q: What breaks when GCP service accounts have no clear owner?

A: Governance breaks because no one can approve rotation, confirm business need, or take responsibility for offboarding. At scale, an ownerless service account becomes a permanent access path, even when the workload that created it no longer exists. The result is hidden privilege, slow remediation, and weak accountability across cloud projects.

Q: Why do long-lived service account keys create more risk than they solve?

A: Long-lived service account keys create standing access that survives beyond the workload, so one leak can enable repeated use, lateral movement, or delayed abuse. They also make rotation brittle because the organisation must track every copy and dependency. Short-lived, scoped credentials reduce both exposure and operational drag.

Q: How do security teams know if service account governance is actually working?

A: Governance is working when every service account has an owner, a workload, a retirement condition, and an auditable rotation path. Teams should also see reduced stale access, fewer unknown accounts, and fewer secrets stored outside managed controls. If the organisation cannot explain why an account still exists, governance is not yet effective.

Q: Should organisations treat service accounts like human users in access reviews?

A: Not exactly, but they should put service accounts into the same governance process. Service accounts often accumulate standing privileges faster than humans and are easier to forget during offboarding or restructuring. Access reviews should therefore cover human and non-human identities together, while applying different usage and ownership criteria to each.

Technical breakdown

Why static keys become a governance bottleneck in GCP service accounts

Service accounts often need keys when external systems cannot use federated workload identity or when integrations still assume reusable credentials. That creates a lifecycle problem: the key becomes the real bearer instrument, not the account itself. As the number of projects and integrations grows, each static key adds review, rotation, and offboarding burden. In practice, the issue is less about issuance and more about persistence. A credential that remains valid across many workloads and owners is hard to scope, hard to attribute, and easy to forget.

Practical implication: track every static key as a governed asset with an owner, expiry expectation, and revocation path.

How ownership and usage visibility change service account governance

Service-account governance depends on knowing who owns the identity, what consumes it, and which resources it can reach. Without that mapping, security teams cannot tell whether an account is unused, over-privileged, or tied to a critical integration. Discovery matters because service accounts are often created by developers and later consumed by platforms, pipelines, or external services with no single clear custodian. Once the inventory is incomplete, rightsizing becomes guesswork. Centralised visibility turns service accounts from hidden exceptions into managed identities with accountable lifecycles.

Practical implication: build a complete inventory that links each service account to an owner, consumer, and reachable resource set.

Why automation is required for key rotation and permission right-sizing at scale

Manual remediation does not scale when service accounts number in the tens of thousands and project sprawl spreads access decisions across many teams. Rotation and permission management need to run as repeatable controls, not periodic campaigns, otherwise stale keys and excess privileges accumulate faster than teams can clear them. Automation matters because the relevant state changes continuously: workloads move, integrations change, and unused identities remain active unless explicitly removed. A scalable programme therefore governs both credentials and entitlement scope as an ongoing process.

Practical implication: automate rotation and entitlement reduction so service accounts stay within a defined access boundary as the environment changes.

Threat narrative

Attacker objective: Obtain durable cloud access through neglected service-account credentials and use that access to move across GCP resources with excessive privilege.

1. Entry occurs through long-lived static keys attached to GCP service accounts, especially where third-party integrations still depend on reusable credentials.
2. Credential access expands because thousands of service accounts and keys create a large exposed surface, and many identities lack clear ownership or timely review.
3. Escalation happens when over-privileged accounts retain broader access than their actual workload requires, giving those credentials more reach than intended.
4. Impact is persistent cloud access across more than 1,000 projects until the estate is inventoried, rotated, and rightsized.

Breaches seen in the wild

• ASP.NET machine key attacks 2025: Developers copied ASP.NET machine keys from public sources; attackers used one to run Godzilla via ViewState. Microsoft found 3,000+ such keys.

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

Service-account ownership is now a first-class governance control, not an administrative detail. This case shows that once machine identities proliferate across thousands of projects, ownership determines whether access can be reviewed, rotated, and revoked at all. When no human or process is accountable for the identity, the account becomes operationally permanent even when it should not be. The practitioner conclusion is that service-account ownership must be explicit before scale makes remediation impossible.

Static-key dependence is the core failure mode, not just a hygiene issue. Long-lived credentials convert every third-party integration into a standing trust relationship that survives far beyond the original business need. That is why the most important concept here is credential persistence debt: the longer a key remains valid, the more it outlives the assumptions under which it was issued. Practitioners should treat every non-rotated key as accumulated governance debt, not a minor exception.

Inventory alone is insufficient unless it is connected to actionable lifecycle controls. Discovering 40,000 identities is useful only if the organisation can also identify which are unused, over-privileged, or tied to business-critical consumers. The governance model needs a path from visibility to remediation, otherwise the inventory becomes a reporting layer with no control effect. The practitioner implication is that discovery, ownership, and entitlement reduction must operate as one programme.

Cloud identity governance and IGA can no longer be separated by identity type. Traditional IGA remains useful for human lifecycle processes, but service accounts require the same governance intent with different control mechanics. This article reinforces that machine identity governance is not a side quest for cloud teams; it is part of core identity architecture. Practitioners should align cloud security, IAM, and NHI ownership under a single lifecycle model.

Continuous governance is now the only realistic operating model for large service-account estates. The article shows that manual review cycles lag too far behind creation rates, especially when identities grow by 5% monthly. In that environment, standing privilege and unrotated keys are not edge cases but the default state. The practitioner conclusion is to govern service accounts as a living estate, not a periodic audit population.

From our research library:

• 59% of organisations say they lack viable alternatives to standing privileged access for NHIs and AI agents, according to Delinea research.
• Read next: Guide to NHI Rotation Challenges

What this signals

Credential persistence debt: every static key that remains valid after its original use case has shifted becomes accumulated risk, not just an old secret. In estates that grow faster than manual review can keep up, governance has to move to issuance, rotation, and revocation as continuous controls, not audit events.

A service-account programme is mature when ownership, visibility, and rightsizing produce measurable change in the estate, not just cleaner reports. The practical test is whether teams can reduce standing keys and over-privileged access without waiting for a quarterly clean-up cycle.

For practitioners

• Establish named owners for every service account Assign each service account to a business or technical owner who can approve lifecycle changes, respond to exceptions, and accept accountability for access scope.
• Inventory static keys across all projects Build a complete list of keys, consumers, and linked projects so hidden credentials can be prioritised for rotation or removal.
• Automate rotation for long-lived credentials Replace manual rotation campaigns with scheduled, enforceable rotation workflows that cover keys used by integrations and platform services.
• Right-size permissions from observed usage Compare actual resource access to granted roles and strip unused privileges from service accounts that do not need broad standing access.
• Separate human JIT access from machine entitlements Keep just-in-time controls for people distinct from service-account governance so human workflows do not mask persistent non-human privilege.

Key takeaways

• This case shows that the real problem is not simply the number of service accounts, but the governance gap created when ownership and lifecycle control are missing.
• The scale of the issue was substantial, with more than 40,000 service accounts, 30,000+ static keys, and growth at 5% monthly before remediation.
• The limiting control was continuous lifecycle governance, especially ownership, rotation, and rightsizing across all projects.

Key terms

• Service Account Governance: The set of policies and operational controls used to manage non-human accounts across their full lifecycle. It covers provisioning, access scope, rotation, revocation, and review, with the goal of preventing long-lived credentials from becoming persistent paths into critical systems.
• Static Key: A reusable credential that grants a service account persistent access until it is rotated or revoked. Static keys are operationally convenient but create long-lived trust that is difficult to track, especially when third-party integrations and multiple projects depend on them.
• Right-Sizing: The process of removing unused or excessive permissions so an identity only retains access it actually uses. For machine identities, right-sizing is usually evidence-driven rather than manager-driven, because logs and runtime behaviour provide a better signal than calendar-based review alone.
• Credential Lifecycle: Credential lifecycle is the process of issuing, rotating, expiring, and revoking secrets, certificates, and tokens across their usable life. For non-human identities, lifecycle discipline is the core control that separates temporary access from persistent exposure.

What's in the full article

P0 Security's full article covers the operational detail this post intentionally leaves for the source:

• The step-by-step process used to discover owners, consumers, and accessible resources across 1,000+ GCP projects
• The automation approach used to rotate keys and manage permissions for large service-account estates
• The remediation pattern for eliminating static keys while preserving required third-party integrations
• The practical deployment detail behind achieving governance for non-human identities within weeks

👉 The full P0 Security article covers the remediation approach, automation model, and operating outcomes across 1,000+ projects.

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.