Who is accountable for revoking unused machine identities?

Why This Matters for Security Teams

Unused machine identities are not a housekeeping issue. They are active trust paths that can still authenticate, call APIs, and reach production systems long after the original service has changed. The right owner is the person who can confirm business need, which is why lifecycle ownership matters more than ticket routing. NHIs often outnumber human identities by 25x to 50x in modern enterprises, and only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs.

That visibility gap is why revocation gets delayed or delegated to the wrong team. Security can enforce control, but it usually cannot confirm whether an API key, workload certificate, or service account is still tied to a live workload. The operational decision belongs with the application owner, platform owner, or service owner, while security provides policy, evidence, and escalation. This aligns with the intent of the OWASP Non-Human Identity Top 10 and with lifecycle guidance in NHI Lifecycle Management Guide.

In practice, many security teams encounter stale identities only after a breach, an audit finding, or a failed incident review, rather than through intentional ownership checks.

How It Works in Practice

Effective revocation starts with a simple rule: every non-human identity must have a named lifecycle owner, a known purpose, and a defined expiry or review interval. For service accounts, that means an application or service owner confirms whether the identity is still required. For platform-managed workloads, the platform owner confirms whether the identity is still in use across clusters, pipelines, or deployment targets. Security operations should not be the default business owner of an identity they cannot validate.

In mature programmes, revocation is tied to decommissioning, migration, and access review workflows. When a workload is retired, its credentials should be disabled, secrets invalidated, certificates revoked, and any dependent automation checked for breakage. The practical mechanics are usually a mix of inventory, attestation, and timed controls: inventory to find the identity, attestation to confirm need, and revocation to remove access quickly. That approach is consistent with the lifecycle emphasis in the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and with broader guidance in the Top 10 NHI Issues.

• Assign ownership at creation, not during cleanup.
• Use short-lived secrets and rotation so unused identities expire faster.
• Track service accounts, API keys, and certificates separately, because revocation methods differ.
• Require application or platform owners to sign off before disabling identities in production.

For controls and patterns, teams often pair OWASP guidance with operational models such as zero trust. If identity state is uncertain, the safer move is to suspend access first and restore only after confirmed business need. These controls tend to break down in sprawling CI/CD estates with shared service accounts and embedded secrets because no single owner can prove which pipeline still depends on the credential.

Common Variations and Edge Cases

Tighter revocation control often increases operational overhead, requiring organisations to balance faster cleanup against release velocity and platform stability. That tradeoff becomes more visible in shared infrastructure, where a single identity may support multiple applications, environments, or automation jobs. In those cases, current guidance suggests treating the shared identity as a risk exception, not as an excuse to avoid ownership.

There is no universal standard for this yet, but good practice is to define who approves revocation, who validates downstream impact, and who owns rollback if an identity was removed too early. In regulated or high-availability environments, teams may stage revocation through JIT replacement credentials or temporary overrides while dependency mapping is completed. The key is still accountability: someone close to the workload must answer whether the identity is live.

One common failure mode is secret sprawl. If credentials are duplicated across code, config files, and CI/CD tools, the “unused” identity may still be active in one forgotten path. The Guide to the Secret Sprawl Challenge and Guide to NHI Rotation Challenges show why revocation must be paired with discovery and rotation, not handled as a one-time cleanup. In many organisations, the identity is only discovered as “unused” after a leaked secret or failed audit exposes that nobody truly owned it.

Related resources from NHI Mgmt Group

• Who should be accountable for machine identity assets that have no clear owner?
• Why do machine identities complicate identity posture management?
• How should security teams govern machine identities when certificate lifetimes keep shrinking?
• Who should own cryptographic trust when machine identities span multiple teams?