Notifications
Clear all
Topic starter
17/08/2026 4:41 pm
TL;DR: NHI governance fails when ownership, visibility, and lifecycle control are still treated as manual exceptions, according to P0 Security case study showing how an insurance provider governed more than 40,000 service accounts across 1,000+ GCP projects by removing 30,000+ static keys, automating key rotation, and right-sizing permissions at scale. The real lesson is that NHI governance fails when ownership, visibility, and lifecycle control are still treated as manual exceptions.
NHIMG editorial — based on content published by P0 Security: How a Leading Insurance Provider Secured 40,000+ Service Accounts in GCP
By the numbers:
- Without automation, the effort would have taken months and delivered only 70% risk reduction.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- Classify and quarantine static keys Separate long-lived keys from workload identities and mark them for immediate review if they cannot be rotated automatically.
- 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.
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
👉 Read P0 Security's analysis of GCP service account governance at scale →
40,000 GCP service accounts: what identity teams need to fix?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
17/08/2026 4:46 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: GCP service account governance at scale for 40,000 identities
