Audit IAM bindings for this role on the project and any broader inherited scope, then verify every member needs to create, manage, or delete service account keys. Treat this as high risk because key creation can enable offline credential theft and long-lived access. Prioritise service accounts, groups, and dormant identities for review.
What the role actually governs in Google Cloud
The Google Cloud Service Account Key Admin Role is not a broad admin permission. It specifically governs who can create, manage, and delete service account keys, so the audit question is really about who can mint offline credentials for a service account and who can remove them. That distinction matters because key admin access can outlast an interactive session and bypass normal login controls.
Start by checking IAM bindings at the project level and then any inherited folder or organization scope that may grant the same role indirectly. In practice, the most useful review is not the role name alone, but the actual principals attached to it, including groups and any identities that no longer appear active in day-to-day operations.
Because the role affects key lifecycle, the review should also consider whether the role exists only where key creation is genuinely required. A service account that should be keyless, or one used by automated workloads that can be modernised to short-lived credentials, should not keep standing key-admin access just because the binding was added long ago.
How to trace exposure across inherited access
Audit the effective permissions, not just the visible attachment point. Google Cloud IAM inheritance can make a binding appear less important than it is, especially when a group is granted the role at a broader scope and then inherits down to multiple projects. A clean review maps the principal, the scope, and the service accounts it can affect.
Pay close attention to service accounts that are shared across applications, used by CI/CD, or tied to legacy integrations. Those are the accounts most likely to justify temporary key creation, but they are also the ones most likely to accumulate unnecessary administrators over time. NHIMG’s Google Cloud IAM and Service Accounts Guide is useful here because it covers role inheritance, service account keys, impersonation, and least privilege in the same control path.
When you find broad groups or nested group assignments, confirm whether membership still reflects current operational need. A role that was granted for onboarding, migration, or incident response often remains in place after the original reason has disappeared. That is the common failure mode in this audit: the access is technically valid, but the business justification is stale.
What good audit evidence looks like
Good evidence is a current principal-to-role mapping, a scope check showing where the binding is inherited from, and an ownership statement for every service account involved. You should be able to explain why each holder needs the ability to create or manage keys, what system uses those keys, and what compensating controls exist if a key must be issued.
For higher-value environments, verify that each key-admin principal is tied to a named operational process rather than a person who can act ad hoc. The difference is important because the role can be abused to generate new long-lived secrets without touching the interactive account itself. NHIMG’s Service Account Security Guide provides a useful lens for judging whether the account lifecycle, key rotation, and governance around those accounts are actually controlled.
If the environment uses workload identity or keyless patterns, the audit should confirm that the key-admin role is shrinking rather than expanding. Where teams still rely on exported JSON keys, the audit should identify which use cases are blocking migration and whether those exceptions are still justified. That is often where dormant access and forgotten break-glass arrangements hide.
Risk and Threat Considerations
Key-admin access is high risk because it can create credentials that are usable outside normal interactive protections, then keep them valid long after the granting user has stopped needing access. If an attacker or insider reaches this role, they may be able to generate fresh service account keys, preserve access through account changes, and move quietly through automation paths that defenders do not monitor as closely as human logins.
Failure mechanism: Overbroad or inherited key-admin bindings let a principal mint long-lived service account keys, then reuse them for offline authentication or persistence after the original account should have lost access.
Impact: Compromise can extend well beyond the original identity, because a newly created key may unlock production systems, automation pipelines, or data stores with little immediate visibility. NHIMG’s Dropbox Sign breach 2024 is a practical reminder that service-account exposure can cascade into broader secret theft and environment access.
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 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Key-admin access can create and expose long-lived service account keys. |
| NHI-05 — Overprivileged NHI | The audit checks whether principals can create keys without a real need. | |
| NHI-07 — Long-Lived Secrets | Service account keys are long-lived credentials that need lifecycle control. | |
| Recommendation — Restrict key creation and rotate any exposed service account keys immediately. Remove unnecessary key-admin bindings and enforce least privilege for service accounts. Replace static keys with short-lived credentials wherever possible. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Service account keys are authenticators whose lifecycle must be controlled. |
| AC-6 — Least Privilege | The role should exist only where key creation is operationally required. | |
| Recommendation — Inventory, rotate, and revoke service account keys under strict lifecycle control. Limit the role to the smallest set of principals that truly need key administration. | ||
Practitioner Guidance
What to prioritise: Review project, folder, and organisation scope together, then sort holders by operational necessity, not by team seniority. Group-based bindings deserve the most scrutiny because they can hide broad membership and make revocation slower than the risk justifies.
What to verify: For each holder, confirm whether they create keys as a routine function, an exception workflow, or a historical leftover. If the answer is not explicit, treat the binding as a candidate for removal or tight time-bound exemption.
Decision rule: If a principal can create keys for a production service account but cannot clearly justify that power in a documented process, reduce the binding before you start debating whether the role has ever been misused.
Practitioner takeaway: The safest audit outcome is not “who has the role,” but “who can justify key creation today and why the same system cannot move to short-lived, keyless access instead.”
Related resources from NHI Mgmt Group
- How do you audit who holds the Google Cloud Storage Admin role?
- How do you audit who holds the Google Cloud Security Admin Role?
- Google Cloud Service Account Key Admin Role (roles/iam.serviceAccountKeyAdmin)
- Google Cloud Service Account API Key Binding Admin Role (roles/iam.serviceAccountApiKeyBindingAdmin)