User-managed service account keys should be rotated every 90 days or sooner

A user-managed service account key is a long-lived credential: it is a file that works from anywhere until someone deletes it. Keys get copied into repositories, build servers and laptops, and nobody notices when one leaks. Regular rotation limits how long a stolen key stays useful and forces teams to find every place a key is used.

Google recommends avoiding service account keys where possible and rotating the ones you must keep. See Best practices for managing service account keys and Service account credentials on the Google Cloud documentation site.

In the Google Cloud console open IAM & Admin, then Service accounts, select an account and open the Keys tab. The Created column shows each key's age; keys of type User-managed are the ones in scope.

From a terminal, this read-only command lists the user-managed keys of one service account with their creation time. Run it against a test project first.

gcloud iam service-accounts keys list \
  --iam-account=SA_NAME@PROJECT_ID.iam.gserviceaccount.com \
  --managed-by=user \
  --format="table(name.basename(), validAfterTime, validBeforeTime)"

Any key whose validAfterTime is more than 90 days in the past needs rotation. To cover a whole project, loop over gcloud iam service-accounts list --format="value(email)".

Best option: stop using keys. Workloads running on Google Cloud can use an attached service account, and external workloads can use workload identity federation. Then delete the old key.

If a key must stay, rotate it in this order so nothing breaks: create a new key, deploy it to the application or pipeline that uses the old one, confirm the application works, then delete the old key.

gcloud iam service-accounts keys create new-key.json \
  --iam-account=SA_NAME@PROJECT_ID.iam.gserviceaccount.com

# after the new key is deployed and verified:
gcloud iam service-accounts keys delete OLD_KEY_ID \
  --iam-account=SA_NAME@PROJECT_ID.iam.gserviceaccount.com

In the console the same steps are Keys, Add key, Create new key, and later the delete icon on the old key. Store the new key in a secret manager, never in a repository. ConfigCobra only reads your configuration; it never creates or deletes keys for you.

Anything that authenticates with the old key stops working the moment you delete it. That can be a deployment pipeline, a scheduled job, a third-party integration or an on-premises script. Find the users of a key before deleting it, for example from the key's last-used information in the service account insights, and keep the old key until the new one is confirmed.

Developers and platform owners have to put a rotation reminder in their calendar or, better, move to keyless access so there is nothing left to rotate. End users of the affected applications see no change when the switch is done in the right order.