Check service account key age and rotation status against security best practices.
Last verified: May 2026
Output will appear here...The checker reads the validAfterTime field from each key's metadata (typically pasted from gcloud iam service-accounts keys list output) and computes age relative to today. It flags keys exceeding your configured threshold (default 90 days), highlights service accounts with multiple active keys as rotation hygiene issues, and surfaces system-managed keys (which Google rotates automatically) so they don't trigger false alarms. All processing is local — no key material or metadata leaves your browser.
GCP service account keys are long-lived credentials that do not expire automatically and are a common source of security incidents when lost, leaked, or forgotten. Google recommends rotating keys every 90 days and migrating to keyless authentication (Workload Identity Federation) whenever possible. This tool checks the age of your service account keys, flags keys that exceed your rotation threshold, identifies keys that have never been rotated, and provides actionable recommendations for improving your key management posture — all entirely in your browser without transmitting any key material.
Your annual SOC 2 audit is in 6 weeks and the auditor has asked for evidence that service account keys are rotated within 90 days. You export key metadata from every project using gcloud iam service-accounts keys list and paste the combined output into the checker. It identifies 23 keys older than 90 days across 8 projects, including 4 keys older than 2 years that nobody owns. You file tickets to rotate or eliminate each, and present the before/after report to the auditor as evidence of an active rotation program.
A service account with multiple active keys is almost always a sign of failed rotation — someone created the new key but forgot to delete the old one. Audit for this pattern monthly: it doubles your attack surface for no operational benefit.
Set the iam.disableServiceAccountKeyCreation org policy on production folders to prevent any new user-managed keys from being created. Combined with iam.disableServiceAccountKeyUpload, this forces teams to migrate to Workload Identity Federation rather than creating yet more long-lived secrets.
Before deleting an old key, disable it for at least 24 hours and watch the audit logs. If something still tries to use the disabled key, you'll see the auth failure in Cloud Audit Logs and can identify the workload. Deleting first means hunting down which service broke without a paper trail.
Google recommends a 90-day rotation period for user-managed service account keys. You can enforce this organization-wide using the iam.serviceAccountKeyExpiryHours organization policy constraint, which automatically disables keys after the specified duration. However, the strongest recommendation is to eliminate user-managed keys entirely by using Workload Identity Federation for external workloads and attached service accounts for workloads running on GCP.
Check Cloud Audit Logs for the service account's activity — look for API calls from unexpected IP addresses, regions, or at unusual times. GCP's Security Command Center can detect anomalous service account behavior. If you suspect compromise, disable the key immediately via gcloud iam service-accounts keys disable, create a new key for legitimate workloads, then delete the compromised key. Also review what resources the service account has access to and audit those resources for unauthorized changes.
Was this tool helpful?
Disclaimer: This tool runs entirely in your browser. No data is sent to our servers. Always verify outputs before using them in production. AWS, Azure, and GCP are trademarks of their respective owners.