Topic starter
17/08/2026 4:41 pm
TL;DR: P0 Security describes how an insurance provider governed more than 40,000 GCP service accounts across 1,000+ projects by removing 30,000+ static keys, automating key rotation, and right-sizing permissions. The core lesson is that NHI governance breaks when ownership, visibility, and lifecycle control are still handled as manual exceptions.
Editorial analysis by NHI Mgmt Group, based on content published by P0 Security: “How a Leading Insurance Provider Secured 40,000+ Service Accounts in GCP”.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: 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.
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
👉 Read P0 Security's analysis of GCP service account governance at scale →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
17/08/2026 4:46 pm
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.
A few things that frame the scale:
- 59% of organisations say they lack viable alternatives to standing privileged access for NHIs and AI agents, according to Delinea research.
A question worth separating out:
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.
👉 Read our full editorial: GCP service account governance at scale for 40,000 identities