Who is accountable for revoking CLI access when people leave?

What revocation accountability should look like for CLI access

CLI access should be treated like any other privileged access path, not as a temporary convenience that disappears on its own. Accountability belongs across the identity, platform, and application ownership chain, but there must be a named owner for the tool or environment, a documented revocation path, and a joiner-mover-leaver dependency so offboarding does not rely on individual memory or goodwill.

That matters because command-line access often sits closer to production systems, automation, and secrets than browser-based access does. If the owner is vague, the revocation step is easy to miss, and the account can remain valid long after employment or role changes should have removed it.

Why CLI offboarding fails when ownership is informal

CLI access tends to survive people changes when the access model is spread across teams but no one team owns the full lifecycle. Platform teams may control the shell or gateway, application teams may own the service or repo, and identity teams may own the directory or SSO layer. If those responsibilities are not explicitly connected, each group assumes another will revoke the access.

The practical failure is usually not malicious neglect. It is a process gap: accounts are deactivated in one system but not in another, tokens are left active, SSH keys are never rotated, or local credentials remain in scripts and developer tooling. The result is stale access that still works even after the person has left or changed roles.

For machine-access patterns, revocation is especially important where CLI access is backed by credentials that can be reused outside an interactive session. Guidance from the NHI Lifecycle Management Guide and the Ultimate Guide to NHIs, Lifecycle Processes for Managing NHIs both point to the same operational truth: lifecycle ownership only works when offboarding is built into the access model rather than treated as an afterthought.

What good revocation control needs to cover

A complete revocation path should cover every place the CLI can authenticate, every credential that can unlock it, and every integration that can recreate access after the user leaves. That includes directory accounts, cloud roles, API tokens, SSH keys, local config files, federated trust, and any delegated access that the CLI depends on.

The control should also distinguish between human-held CLI access and shared or automated access paths. If a developer’s terminal identity can reach production through long-lived credentials, revocation must remove both the human account and any standing credential material associated with it. The same principle is reflected in Guide to the Secret Sprawl Challenge and Guide to NHI Rotation Challenges, because stale secrets and weak rotation discipline are common reasons revocation fails in practice.

Where CLI access uses public cloud or API-backed authentication, the revocation path should be tested the same way you would test any privileged access removal. A useful standard here is NIST SP 800-57 Key Management, which reinforces that long-lived credentials and unmanaged cryptographic material create lifecycle risk. For bearer-token or client-authenticated CLI flows, RFC 6749: The OAuth 2.0 Authorization Framework and RFC 8705: OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens show why token binding and client authentication matter when access must be removed quickly and reliably.

How to assign accountability without creating gaps

Accountability works best when one function owns the revocation outcome and other functions own the contributing controls. The identity team usually owns lifecycle enforcement, the platform team owns the access path, and the application or service owner owns the business need for access. That division prevents the common failure mode where everyone is consulted but no one is responsible.

The cleanest operating rule is simple: if a person can still use the CLI to reach a system, the owner of that system must be able to explain why access still exists and how it will be removed. In larger environments, that is usually enforced through joiner-mover-leaver workflows, access review evidence, and periodic validation that the revocation path works end to end.

For practitioners who want a broader control lens, NIST SP 800-53 Rev 5 Security and Privacy Controls is useful for mapping the access lifecycle to identity, access control, and audit expectations, while CIS Controls v8 helps translate that into practical account-management and logging activities. For teams using stronger governance language, Top 10 NHI Issues is a useful reminder that ownership, rotation, and offboarding fail in the same way whether the access is human or non-human.

Risk and Threat Considerations

Unrevoked CLI access creates a durable path back into systems that often have high trust and broad reach. The risk is not only unauthorized use after departure, but also silent reuse of old credentials, lateral movement from stale access, and delayed detection because command-line activity can look normal until a compromise is already underway.

Failure mechanism: Offboarding only removes the visible account while leaving one or more credentials, tokens, keys, or delegated access paths active. If the CLI can still authenticate through another trust path, the old user or an attacker with stolen material can continue to operate.

Impact: The organisation can retain unintended administrative reach, miss privilege cleanup, and preserve a ready-made post-departure attack path into production systems, source control, or cloud control planes.

Practitioner Guidance

What to prioritise: Treat revocation as a testable control, not a policy statement. The most important check is whether leaving the company actually removes every way the CLI can authenticate, including fallback credentials and cached tokens.

What to verify: Confirm there is a named owner for each CLI-enabled system, a documented revocation step in the offboarding process, and evidence that the step is exercised. If the owner cannot prove how access is removed, the control is not operationally complete.

Common mistake: Teams often believe disabling the directory account is enough. In practice, the real exposure is the credential material and delegated trust that survives the directory event.

Practitioner takeaway: The right accountability model is the one that makes revocation boring, deterministic, and auditable, because CLI access that depends on tribal knowledge will usually outlive the person who should have lost it.

Related resources from NHI Mgmt Group

• How should security teams run access reviews for non-human identities?
• How should security teams govern non-human identities that have persistent access?
• When do NHI access reviews create more value than a one-time cleanup?
• What is the difference between reviewing human access and reviewing NHIs?