Service Account Key Expiration: Transition from Indefinite Lifetime to Enforced Limits

Short answer

No. Activating an organization policy that caps service account key lifetime does not automatically reject existing downloadable keys that lack an expiration date. The policy normally constrains new key creation and rotation, while existing keys remain valid until they are deleted, rotated, or separately revoked. This scope is version-sensitive, so you must confirm it in your Google Cloud Organization Policies console before assuming existing keys are safe.

Likely explanation versus confirmed behavior

Likely explanation (version-sensitive)

When an organization policy enforces a maximum key lifetime, Google Cloud typically applies the limit to newly created keys and to new key versions created during rotation. Existing keys created without an expiration date usually continue to authenticate successfully until an explicit administrative action removes them. Treat this as likely behavior, not a guarantee, because exact constraint names and retroactive enforcement vary by release.

Confirmed authentication-versus-authorization pattern

Google Cloud APIs evaluate authentication before IAM authorization. A request with an expired or invalid service account key fails authentication, while a request with a valid key but insufficient IAM roles fails authorization. In typical HTTP responses, authentication failure returns 401 Unauthorized and missing permission returns 403 Forbidden. Client libraries may retry or mask 401 responses, so inspect raw error bodies or audit logs rather than relying on the library's surface error alone.

Observable signals during a phased rollout

Signal	Expired or invalid key	Missing IAM permission
HTTP status	Typically 401 Unauthorized	Typically 403 Forbidden
Error body	References invalid credentials, token expiry, or invalid grant	Names the missing permission, such as storage.objects.get or bigquery.jobs.create
Audit logs	401 authentication events tied to the service account key	403 authorization events naming the required IAM permission

Compute Engine, Cloud Storage, and BigQuery generally follow this pattern, but exact wording can differ between long-lived service account keys and short-lived access tokens. Validate the exact client library and API method in a non-production project before drawing conclusions.

Steps for this case

1. Open the Google Cloud Console Organization Policies page and inspect the active service account key lifetime constraint. Note whether it governs existing keys or only new key creation and rotation.
2. In a non-production project, authenticate with a test service account key that has no expiration date after policy activation. Record the HTTP status and error body.
3. Compare that result with a valid key that lacks the required IAM permission on the same resource to confirm the 401-versus-403 distinction for your client library.
4. Review Cloud Audit Logs for 401 authentication failures and service account key usage during the rollout.
5. Inventory workloads still using downloadable keys. Rotate them to Workload Identity Federation or short-lived credentials before deleting any key.

Downloadable keys versus Workload Identity Federation

Workload Identity Federation exchanges an external identity for a short-lived OAuth token, so the external credential is not bound by service account key lifetime limits. The target service account still requires the appropriate IAM bindings. Downloadable keys are not purged from external systems, local files, or workloads when they expire; applications continue presenting them, which can produce runtime failures that resemble permission denials if only the HTTP status is inspected.

Missing diagnostic detail

Can you provide the exact organization policy constraint ID and whether its enforcement covers existing keys or only new keys? This determines whether existing keys require immediate rotation or a phased replacement.

Reviewer note

This draft requires current verification against your Google Cloud Organization Policies console. Do not bulk-delete or rotate downloadable keys until workload dependency is confirmed, because outages closely resemble IAM permission outages.