GCP service account governance at scale for 40,000 identities

At a glance

What this is: This case study shows how a large insurer reduced GCP service account sprawl by combining inventory, automated remediation, and permission right-sizing across a very large cloud estate.

Why it matters: It matters because unmanaged service accounts create persistent identity risk across NHI, cloud, and IAM programmes, and manual governance does not scale across thousands of projects.

By the numbers:

• The estate was growing at 5% monthly before governance was automated.
• Without automation, the effort would have taken months and delivered only 70% risk reduction.

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

Context

Non-human identity governance in cloud environments breaks down when service accounts are created faster than ownership, visibility, and permission review can keep up. In this case, the primary problem was not GCP itself but the operational model around 40,000+ service accounts, 30,000+ static keys, and thousands of projects with no consistent lifecycle control.

The important identity lesson is familiar to IAM and PAM teams: if a service account has no owner, no clear usage signal, and no rotation discipline, it behaves like standing privilege with a long credential half-life. That is why cloud identity programmes need governance and remediation, not inventory alone.

Key questions

Q: How should teams govern GCP service account access at scale?

A: They should govern service accounts as lifecycle-managed NHIs, not as isolated cloud objects. That means assigning ownership, discovering every account across projects, scoring actual use, and removing permissions that exceed the workload's current need. Scale comes from automation and central policy, not from periodic manual review.

Q: Why do unowned service accounts create more security risk?

A: Unowned service accounts create more risk because no one is responsible for reviewing their permissions, rotating their credentials, or removing them when they are no longer needed. That makes privilege creep more likely and makes it harder for analysts to respond quickly when unusual activity appears.

Q: What breaks when static keys are used for cloud integrations?

A: Static keys break lifecycle control because they are easy to copy into tools, scripts, and third-party platforms, then difficult to trace later. If rotation or revocation happens without full dependency mapping, teams either miss exposures or disrupt critical integrations, which is why unmanaged keys become governance debt.

Q: How should security teams implement least privilege for non-human identities?

A: Start by inventorying every machine identity, then map each one to a specific owner, purpose, and resource set. Remove broad roles, replace long-lived secrets with short-lived credentials, and automate review and retirement. Least privilege only works when identity lifecycle, access scope, and monitoring are managed together.

Technical breakdown

Why service account sprawl becomes an identity governance problem

Service accounts are non-human identities, but they often accumulate faster than governance processes can assign owners, classify risk, and review access. In cloud estates, every integration, workload, and monitoring tool can create another credential path, and static keys turn those paths into durable attack surfaces. The technical failure is not merely scale. It is the absence of a reliable relationship between identity, purpose, and lifecycle state across projects and consumers.

Practical implication: build an authoritative inventory that links each service account to an owner, workload, and access purpose before granting new credentials.

Why static keys break cloud identity lifecycle control

Static credentials create a persistence layer that outlives the workload or integration that needed them. When a third-party platform requires a key to read logs or call APIs, that secret can become embedded in multiple systems and remain valid long after the original operational need changes. Rotation helps only if the organisation can identify where the key is stored, how it is consumed, and which dependencies will break when it changes. Without that visibility, the key becomes operational debt.

Practical implication: treat every static key as a lifecycle object with discovery, rotation, and revocation steps that are tracked centrally.

How permission right-sizing works across thousands of cloud projects

Permission right-sizing is the process of comparing what an identity can access with what it actually needs. In a multi-project GCP environment, that requires aggregating usage, exposed resources, and privilege boundaries across all connected projects rather than reviewing each account in isolation. The technical challenge is not only over-privilege but distribution: one weak identity can touch many resources, and one manual review model cannot keep pace with continuous change.

Practical implication: automate entitlement analysis across all cloud projects and remove broad roles before they become the default operating model.

Threat narrative

Attacker objective: The attacker objective is to exploit durable service account access to move through cloud resources with minimal detection and maximal reach.

1. Entry occurs through service account proliferation and static key creation across cloud projects and third-party integrations.
2. Escalation follows when over-privileged identities retain broad access without ownership, rotation, or central review.
3. Impact is persistent exposure across the cloud estate, where unused or excessive credentials expand the blast radius of compromise.

Breaches seen in the wild

• Coupang Signing Key Breach — Unrevoked signing key credentials expose 33.7 million records after employee offboarding failure at Coupang.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Service account ownership debt is the hidden failure mode in cloud identity programmes. A large inventory is not the same as governance if no one can be held responsible for each identity's purpose, usage, and retirement. The insurer's problem was not just scale, but the accumulation of identities that could not be confidently attributed to a business need. Practitioners should treat ownership assignment as a control, not an administrative detail.

Static key persistence is a lifecycle failure, not just a secrets issue. Once a service account key is stored in multiple tools, integrations, and scripts, it becomes difficult to locate, rotate, or revoke with confidence. That persistence creates a trust gap between the credential's current state and the organisation's understanding of its exposure. The practical conclusion is that key inventory and key lifecycle management must be governed together.

Continuous remediation is the only realistic control model at cloud scale. Manual reviews across 1,000+ projects cannot keep pace with service account creation, usage drift, and privilege creep. This is where NHI governance converges with cloud security posture management and IGA discipline. Practitioners should stop treating periodic reviews as sufficient evidence of control in fast-moving cloud estates.

Least privilege for NHIs is an operating state, not a one-time configuration. The article shows that access can be right-sized, but only if the organisation can keep re-evaluating actual usage as projects, integrations, and consumers change. In cloud identity programmes, privilege boundaries erode as soon as the environment starts moving faster than the review cycle. The implication is that governance must be continuous, not episodic.

From our research:

• Only 19.6% of security professionals express strong confidence in their organisation's ability to securely manage non-human workload identities, according to The 2024 Non-Human Identity Security Report.
• 88.5% of organisations say their non-human IAM practices lag behind or are merely on par with human identity and access management efforts.
• That gap is why the NHI Lifecycle Management Guide and the Guide to the Secret Sprawl Challenge remain essential references for programme design.

What this signals

Service account governance will keep shifting from periodic cleanup to continuous control. Once an estate reaches tens of thousands of identities, the programme risk is not only privilege creep but the inability to prove who owns what at any moment. The teams that win this transition will pair lifecycle governance with cloud telemetry and automated remediation rather than relying on review cycles alone.

Identity blast radius is now a cloud design variable. When one service account can reach many projects, the shape of the entitlement graph matters as much as the credential itself. Practitioners should expect more interest in scoped workload identity patterns, centralised ownership models, and tighter dependency mapping across integrations.

With 88.5% of organisations saying their non-human IAM lags human IAM, the governance gap is structural, not incidental. The next phase of programme maturity will be judged by whether teams can reduce manual exception handling and prove continuous state, not whether they can produce another inventory export.

For practitioners

• Inventory every service account with ownership attached Create a single authoritative register that links each service account to an owner, workload, consumer, and business purpose across all projects. Do not allow newly created accounts to remain anonymous beyond initial provisioning, because anonymous identities cannot be governed or retired safely.
• Classify and quarantine static keys Separate long-lived keys from workload identities and mark them for immediate review if they cannot be rotated automatically. Prioritise keys used by third-party integrations, monitoring tools, and cross-project access paths because those credentials usually carry the largest blast radius.
• Automate entitlement right-sizing across projects Use continuous analysis to compare granted permissions with actual usage, then remove roles that are broader than the workload requires. Apply the same review logic across all GCP projects instead of allowing each team to make isolated privilege decisions.
• Build lifecycle controls around rotation and revocation Treat rotation as part of an end-to-end lifecycle that includes discovery, dependency mapping, replacement, and revocation validation. If a key cannot be rotated without breaking hidden integrations, the dependency graph is incomplete and the control is not real.
• Pair cloud visibility with remediation workflows Use inventory and risk scoring to drive actual change, not just reporting. A governance programme should be able to bulk-remediate unused identities, remove over-provisioned access, and confirm that the remaining entitlements still match operational need.

Key takeaways

• This case shows that service account sprawl becomes a governance failure when ownership, visibility, and lifecycle control do not scale with cloud growth.
• The evidence is operational, not theoretical: 40,000+ service accounts, 30,000+ static keys, and 1,000+ projects created a control problem that manual processes could not sustain.
• The practical fix is continuous NHI governance, where discovery, rotation, right-sizing, and revocation are managed as one programme rather than separate tasks.

Key terms

• Service-account sprawl: Service-account sprawl is the accumulation of shared or long-lived machine identities that are created for convenience and then reused across teams or workflows. It increases governance friction because the account no longer maps cleanly to one operator, one purpose, or one lifecycle event.
• Static Key Persistence: The tendency for long-lived credentials to survive well beyond the workload or integration that originally needed them. In practice, this creates hidden exposure because keys are copied into tools and scripts and then forgotten, rotated late, or never revoked.
• Permission Right-Sizing: The process of reducing an identity's access to only what it actually uses. For non-human identities, this depends on usage telemetry, dependency mapping, and continuous review because permissions drift as workloads and integrations change.
• Identity Ownership: Identity ownership is the assignment of a responsible human for each identity's purpose, access, review, and retirement. For non-human identities, ownership must be explicit because the creator is not always the right person to approve ongoing access. Without ownership, review and revocation become inconsistent and slow.

What's in the full article

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

• How the insurance provider structured GCP project onboarding and service account discovery at scale
• The automation pattern used to rotate keys and manage permissions across 1,000+ projects
• The deployment workflow that allowed governance to begin within hours rather than months
• The before-and-after impact on static keys, over-privilege, and ongoing identity governance

👉 The full P0 Security article covers the inventory, automation, and remediation steps behind the result.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.