# Ensure User-Managed Service Account Key Was Used Within the Allowed Inactivity Period

- Source: https://support.icompaas.com/support/solutions/articles/a_1788888304679912-ensure-user-managed-service-account-key-was-used-within-the-allowed-inactivity-period
- Section: [Solutions](https://support.icompaas.com/support/solutions) › [GCP Benchmarks](https://support.icompaas.com/support/solutions/62000112667) › [GCP Knowledge Bases](https://support.icompaas.com/support/solutions/folders/62000169178)
- Last updated: 2026-09-08
- Publisher: iCompaas, Inc. (https://www.icompaas.com)

**Description**

Ensure that user-managed (external) service account keys that have not been used to authenticate within a defined inactivity period (for example, 90 days) are identified, disabled, and rotated or deleted, reducing the risk posed by dormant credentials.

**Rationale**

A user-managed service account key that is no longer used still represents a valid, standing credential that, if leaked, could be used to authenticate as the service account indefinitely. Regularly identifying keys that have not been used within an acceptable inactivity window, and disabling or removing them, reduces the number of live credentials in the environment and shrinks the attack surface presented by forgotten or orphaned keys.

**Impact**

-   Reduces the number of unused, standing credentials that could be leveraged if leaked
    
-   Limits the impact of forgotten or orphaned service account keys
    
-   Requires validation before disabling a key, to confirm it is not used by an infrequent but legitimate process (for example, a quarterly job)
    

**Default Value**

GCP does not automatically disable or delete inactive service account keys; identification and remediation of unused keys must be performed using Recommender / Activity Analyzer insights or Cloud Monitoring usage metrics and applied manually or via automation.

**Pre-Requisites**

-   The Recommender API and/or Cloud Monitoring service account usage metrics enabled for the project
    
-   IAM permissions to view service account key usage insights and manage service account keys (e.g., Service Account Key Admin)
    
-   A documented inactivity threshold (for example, 90 days) approved by the organization
    

**Test Plan**

1.  Sign in to the Google Cloud Console at [https://console.cloud.google.com](https://console.cloud.google.com/).
    
2.  Select the relevant project.
    
3.  Navigate to IAM & Admin > Service Accounts.
    
4.  Review the Recommendations / Insights tab (or Policy Analyzer / Recommender findings) for service account key insights showing keys not used within the past 90 days.
    
5.  Cross-reference flagged keys with Cloud Monitoring service account key usage metrics to confirm inactivity.
    
6.  If a key exceeds the allowed inactivity period, follow the implementation steps.
    

**Implementation Steps**

1.  Sign in to the Google Cloud Console at [https://console.cloud.google.com](https://console.cloud.google.com/).
    
2.  Select the relevant project.
    
3.  Navigate to IAM & Admin > Service Accounts and select the service account with the flagged key.
    
4.  Open the Keys tab, identify the specific key ID exceeding the inactivity threshold.
    
5.  As a precaution, disable the key first (rather than deleting immediately) and monitor for any failures from legitimate dependent systems.
    
6.  After a defined observation period with no issues reported, delete the disabled key.
    
7.  Document the key ID, service account, and disposition (disabled or deleted) for audit purposes.
    

**Backout Plan**

1.  Sign in to the Google Cloud Console at [https://console.cloud.google.com](https://console.cloud.google.com/).
    
2.  Select the relevant project.
    
3.  Navigate to IAM & Admin > Service Accounts and select the affected service account.
    
4.  Open the Keys tab and, if the key was only disabled (not deleted), select the key and choose Enable.
    
5.  If the key was deleted, generate a new key for the service account and securely distribute it to the systems that require it, since a deleted key's private material cannot be recovered.
    

**Reference**

-   [https://cloud.google.com/policy-intelligence/docs/service-account-insights](https://cloud.google.com/policy-intelligence/docs/service-account-insights)
    
-   [https://cloud.google.com/iam/docs/service-account-overview](https://cloud.google.com/iam/docs/service-account-overview)

## Related compliance guidance

- [SOC 2 compliance: a practical implementation guide for cloud-native SaaS teams](https://support.icompaas.com/compliance/soc-2-trust-services-criteria): Configuration checks like this one are the technical half of a SOC 2 / ISO 27001 programme — the guide shows where they fit, what else an auditor expects, and how to evidence them.
- [ISO/IEC 27001:2022 compliance: a practical implementation guide](https://support.icompaas.com/compliance/iso-27001-2022): ISO 27001 Annex A.8 (technological controls) is where cloud hardening evidence lands; the guide shows how to run the ISMS around it.