Securing your Google Cloud Platform environment requires constant vigilance, especially when it comes to authentication. A forgotten JSON key can give an attacker the same access as a live workload without needing an open firewall or a stolen administrator password.
A disciplined service account key audit finds these lingering credentials before they become a security incident. In 2026, the target state is clear: retain service account identities where workloads need them, but remove long-lived, downloadable service account keys. By migrating away from traditional service account keys, you significantly reduce the risk of lateral movement and unauthorized access.
Use this checklist to inventory your assets, rank exposure, replace risky authentication methods, and keep necessary exceptions under control.
Key Takeaways
- A service account is an identity and access management principal, while a key is a specific credential that authenticates as that principal.
- Conduct an audit of user-managed service account keys first, as these credentials can be downloaded and transferred outside of the Google Cloud environment.
- Prioritize remediation for keys that are exposed, unowned, hold excessive privileges, or belong to legacy production systems.
- Adopt modern alternatives such as attached service accounts, Workload Identity Federation, and service account impersonation to replace the need for long-lived JSON keys.
- Implement an organization policy to block the creation of new keys, then establish monitoring for the few approved exceptions that remain.
Separate Service Account Identities From Their Keys
A Google Cloud service account functions as a distinct identity assigned with specific IAM roles. This identity can authenticate workloads across the Google Cloud Platform without a downloadable credential when it is attached directly to services like Compute Engine, Cloud Run, App Engine, or GKE.
In contrast, service account credentials often manifest as user-managed keys. A user-managed key is a cryptographic private key, typically delivered as a JSON file, that allows external software to authenticate as the service account from almost any location. Whoever holds this private key can utilize its associated permissions until the key is disabled, deleted, or expires.
Google-managed keys also exist to facilitate platform operations, but teams cannot download or rotate these keys. Your audit should focus specifically on user-managed keys and the IAM roles attached to their service accounts.
Deleting a user-managed key does not delete the service account identity. Workloads can continue through a keyless authentication method after migration.
This distinction helps teams avoid a common mistake. It is easy to delete a risky key and inadvertently remove the service account itself, which breaks production services. Instead, first replace the credential path, validate that the workload functions correctly, and then focus on cleaning up unused service accounts later in the process.
A broader enterprise GCP security guide also frames service account keys as security debt. That is the correct operating assumption for every key without a documented technical exception.
Build a Complete Inventory of User-Managed Keys
Start your assessment at the organization level within your Google Cloud Platform environment. A project by project review often misses retired sandboxes, acquired projects, and non-production environments that still maintain production access.
For each service account, record the project, owner, workload, environment, IAM roles, key IDs, creation time, expiry time, status, principal email, and last known use. The purpose of a key matters as much as its age. A 20-day-old key copied to a developer laptop can pose more risk than a 100-day-old key locked to a narrow legacy appliance.
The following gcloud cli command lists user-managed keys for one service account:
gcloud iam service-accounts keys list --iam-account=SERVICE_ACCOUNT_EMAIL --managed-by=user --format="table(name,validAfterTime,validBeforeTime,disabled)"
Run this command against every service account in every project, then consolidate the results in a controlled inventory. Cloud Asset Inventory can help establish organization-wide coverage, while Cloud Logging and audit logs can support deep investigations into key creation, deletion, and usage patterns.
Check Admin Activity logs for events such as google.iam.admin.v1.CreateServiceAccountKey and google.iam.admin.v1.DeleteServiceAccountKey. Additionally, review data access logs for sensitive interaction history, service account impersonation events, IAM policy changes, and the Service Account Credentials API’s GenerateAccessToken activity. Because logs do not always prove that a particular key is currently inactive, combine these insights with application owner confirmation and deployment records.
For each key, answer these questions:
- Which application, job, device, or pipeline still needs it?
- Does the service account have a named technical owner and business owner?
- Can the workload use an attached identity or federated token instead?
- Does the account hold production access, broad roles, or cross-project permissions?
- Has the key appeared in a repository, build log, ticket, chat message, or endpoint backup?
Scan source repositories, container build contexts, artifact stores, and developer file shares for Google credential patterns to mitigate the risk of credential leakage. Private repositories are not a safe place for key files. A public leak demands immediate revocation, but an internal leak still creates an uncontrolled copy problem that must be remediated.
Rank Findings by Exposure and Privilege
A service account key audit should produce a prioritized work queue rather than a flat list of credentials. To do this effectively, rank each finding by key exposure, service account privilege, workload criticality, and ownership. By adhering to the principle of least privilege, you can better categorize which service account keys pose the most significant threat to your infrastructure.
| Risk level | Typical finding | Required action |
|---|---|---|
| Critical | Publicly exposed key, or a production key tied to Owner, Editor, or broad admin access | Disable or delete immediately, investigate use, and replace authentication |
| High | Active external CI/CD key, unmanaged developer key, unknown owner, or key older than policy | Migrate to keyless authentication on an urgent schedule |
| Medium | Restricted legacy key with a confirmed owner and limited role | Set expiry, reduce permissions, and create a dated migration plan |
| Low | Disabled key with no observed use and no dependency | Delete after the observation period |
The highest-risk combination is a long-lived credential paired with broad permissions. When assessing service account keys, be particularly wary of privilege escalation, which can occur if an attacker uses a compromised key to gain administrative control over the project. Review service accounts with roles such as Owner, Editor, Service Account Token Creator, Service Account User, and privileged custom roles before assessing the key itself. A narrow key can still be dangerous when its service account can access sensitive projects or impersonate other accounts.
For suspected inactive keys, disable them first using the gcloud cli:
gcloud iam service-accounts keys disable KEY_ID --iam-account=SERVICE_ACCOUNT_EMAIL
Monitor the workload for a week, including monthly jobs and disaster recovery processes. If the owner confirms there is no dependency, delete the key:
gcloud iam service-accounts keys delete KEY_ID --iam-account=SERVICE_ACCOUNT_EMAIL
If a key is exposed, skip the observation period. Delete it immediately, investigate Cloud Logging records, review the service account’s IAM bindings, and check dependent systems for unauthorized changes.
Replace JSON Keys With Keyless Authentication
Each key should have a replacement design before teams create another credential. The right pattern depends on where the workload runs.
For Compute Engine, Cloud Run, and App Engine, attach a dedicated service account to the runtime. Application default credentials can automatically obtain short-lived credentials from the platform metadata service. The workload receives authentication at runtime without needing a static JSON file.
For GKE, use Workload Identity Federation for GKE. Map a Kubernetes service account to a dedicated Google Cloud service account at the workload level. Avoid relying on node service account credentials, because every pod on the node may gain access beyond its needs.
External workloads need Workload Identity Federation. AWS, Azure, GitHub Actions, GitLab CI/CD, and on-premises systems can exchange trusted OIDC or SAML assertions via OAuth 2.0 for short-lived credentials. The external identity should only impersonate the exact service account required by that specific pipeline or application.
Service account impersonation also suits controlled deployment paths. Grant roles/iam.serviceAccountTokenCreator only to the narrowly defined principal that needs it. Then, monitor token generation and IAM binding changes as carefully as you monitor key creation.
For local development, developers should use their own user credentials and Application Default Credentials, such as gcloud auth application-default login, rather than downloading production service account keys. Separate development and production permissions so a workstation token cannot reach sensitive workloads.
A 2026 GCP security checklist is useful context for pairing this work with access reviews, logging, and broader cloud controls. Keyless authentication removes a credential class, but the principle of least privilege still determines the impact of a compromised identity.
Put Guardrails Around the Remaining Exceptions
Some legacy software and specialized appliances may still require a key. Treat these as time-bound exceptions rather than permanent architecture.
As of July 2026, organizations created on or after May 3, 2024, generally have organization policy constraints enforced by default through Google Cloud secure-by-default controls. Older organizations should explicitly enforce the iam.disableServiceAccountKeyCreation constraint at the organization or folder level after approved exceptions are in place. This effectively prevents users from being able to create service account key assets that are not strictly necessary.
A current gcloud example is:
gcloud resource-manager org-policies enable-enforce iam.disableServiceAccountKeyCreation --organization=ORGANIZATION_ID
Confirm the command syntax and inherited policy behavior against current Google Cloud documentation before production rollout, because gcloud and Organization Policy behavior can change. Use narrow folder-level exceptions where required, and document an owner, expiry date, migration ticket, and compensating controls for each one. Regularly monitor the Google Cloud console to audit for recent key usage and creation history to ensure compliance.
Set iam.serviceAccountKeyExpiryHours to cap the lifespan of any permitted user-managed key. A 90-day key rotation limit is a practical baseline, while high-privilege credentials should have shorter lifetimes.
Do not treat Secret Manager as a permanent solution for a JSON key. It can restrict storage access, but the underlying credential remains long-lived and exportable. If a temporary key must exist, prevent copies in repositories, email, chat, shared drives, and build artifacts.
Finally, review exceptions and service account ownership at least quarterly. The assigned service account key admin should lead these reviews. Pair the audit with administrator phishing-resistant authentication and utilize Cloud Monitoring for ongoing oversight, as recommended in this GCP security best-practices overview. Identity security fails when attackers can compromise either the human administrator or the workload credential.
Frequently Asked Questions
What is the primary risk associated with user-managed service account keys?
User-managed service account keys are cryptographic files that can be downloaded and used from any location outside of Google Cloud. Because they are static and often long-lived, they pose a significant risk of unauthorized access if they are leaked, shared, or improperly stored.
How can I transition away from using JSON key files?
To move away from JSON keys, you should adopt keyless authentication methods such as Workload Identity Federation for external workloads or attaching service accounts directly to Google Cloud services like Compute Engine and GKE. These methods provide short-lived, automated credentials that eliminate the need to manually manage and rotate private key files.
Can I safely delete a service account key without breaking my application?
Before deleting any key, you must verify that the workload has successfully migrated to an alternative authentication method or confirm that the key is no longer in use by checking audit logs and monitoring metrics. It is recommended to disable the key first to observe if any services fail, allowing for a quick rollback if a hidden dependency is discovered.
Conclusion
A successful service account key audit treats downloadable keys as exceptions that must justify their existence. Inventory every user-managed key, remove exposed credentials immediately, and assign each remaining key a clear owner and a strict expiration date.
The ultimate goal is to transition toward keyless workload authentication, which is backed by narrow IAM roles and continuous monitoring. By eliminating the reliance on static service account keys, you remove one of the most common Google Cloud credential vulnerabilities. Implementing this strategic shift ensures your infrastructure remains secure and resilient as you move away from the risks associated with traditional key management.
