User-Managed Service Account Keys

What User-Managed Service Account Keys Are

User-managed service account keys are privately controlled key material for a service account, usually created by a person rather than issued and rotated by the platform. They are a direct authentication mechanism, which makes their lifecycle and exposure materially important.

They differ from platform-managed or keyless approaches because the organisation, not the cloud provider, is responsible for creation, storage, rotation, revocation, and retirement. That ownership model can be convenient for automation, but it also creates a standing credential that may outlive the workload, script, or person that introduced it.

Why These Keys Are Dangerous

The core security issue is not the service account itself, but the long-lived secret that proves possession of that account. If the key file is copied, logged, checked into source control, or exfiltrated from an endpoint, an attacker can often authenticate as the service account without needing the original host.

That makes exposure especially serious in cloud environments, where a single key may unlock APIs, storage, deployment systems, or administrative workflows. NHIMG’s Cloud Workload Identity Guide explains why keyless patterns reduce this risk by replacing static credentials with short-lived or federated authentication.

These keys are also attractive because they are reusable across environments and can remain valid long after the original deployment context has changed. The practical danger is persistence: once stolen, the key can continue to work until someone notices, revokes it, and removes every place that depended on it.

How Organisations Assess Exposure

Exposure assessment starts with inventory, because many teams do not know where user-managed service account keys exist or which applications still depend on them. A complete inventory should include code repositories, CI/CD variables, secret stores, developer laptops, build systems, and any cloud project where key creation is still allowed.

From there, security teams should identify where the keys are used, whether they are attached to production workloads, and whether any are externally reachable through automation, partner integrations, or internet-facing services. For Google Cloud environments, the vendor’s guidance on service account keys and the broader Google Cloud security posture are the authoritative places to confirm policy options and platform behaviour, including Google Cloud Service Account Keys Security Guide and Google Cloud Security Guide.

Exposure review should also distinguish between keys that are truly in use and keys that are merely still present. Stale keys are common, and they are often the easiest to eliminate because removing them does not break an active dependency.

Safer Patterns and Remediation

The preferred remediation is to move consumers away from user-managed keys and toward federation, impersonation, or other short-lived authentication methods. When a key is no longer required, revoke it, delete it, and prevent new key creation where possible so the same pattern does not reappear.

When immediate removal is not possible, compensating controls matter. Restrict where the key can be stored, reduce the service account’s privileges, monitor for abnormal use, and treat the key as a high-value secret with tight ownership and incident handling. NHIMG’s How to inventory Google Cloud service account keys and replace them with federation is a useful operational path for replacing static keys with workload identity federation.

Key retirement should be deliberate rather than symbolic. Teams need to validate that every application, job, and integration has been re-bound to a safer identity mechanism before the key is removed.

Detection and Recovery After Suspected Exposure

Detection focuses on both key misuse and the system changes that follow compromise. Unusual geographies, unexpected API calls, non-routine privilege use, and access from systems that should never hold the key are all warning signs, especially when the service account was intended only for a narrow workload.

If a key may have been exposed, recovery should assume direct credential abuse rather than waiting for proof. Revoke the key, rotate any downstream secrets the account could reach, review audit logs for actions performed under that identity, and check whether the attacker created new credentials, altered permissions, or established persistence through automation.

NHIMG’s Google Cloud Service Account Keys Security Guide is particularly relevant here because it connects key inventory, telemetry, and safe retirement into one response path, while Ultimate Guide to NHIs provides the wider governance context for lifecycle, ownership, and secret hygiene.

Risk and Threat Considerations

Long-lived user-managed keys create a durable attack path because they can be copied once and used repeatedly without the original user or workload being present. That makes them a frequent target for secret theft, repository leaks, endpoint compromise, and post-breach persistence.

Failure mechanism: An exposed key bypasses normal interactive controls, so an attacker can authenticate as the service account, inherit its permissions, and continue operating until the key is revoked and the account’s downstream access is reviewed.

Impact: Compromise can lead to API abuse, data access, deployment tampering, lateral movement into connected systems, and stealthy persistence if the key is not discovered quickly.

Practitioner Guidance

Why practitioners should care: Treat user-managed service account keys as an exception, not a default pattern. The operational convenience of a static key is often outweighed by the recovery burden once it is exposed or forgotten.

Governance implication: Ownership should be explicit, with a named team responsible for issuance approval, inventory, monitoring, and retirement. If no one owns the key lifecycle, the key will usually outlive the business need that justified it.

Practitioner takeaway: The safest posture is to minimise static keys, prefer short-lived or federated authentication, and make every remaining key visible, justified, and revocable.

Related resources from NHI Mgmt Group

• Guide: Windows Services and Service Account Security Guide
• How do you avoid user-managed service account keys in Google Cloud?
• What breaks when service-account keys are not treated as lifecycle-managed credentials?
• What is the difference between service account risk and user account risk in AD?
• What is the difference between an AI agent and a managed service account?