Who should be accountable for SSH access when employees leave or change roles?

Why This Matters for Security Teams

SSH access is often treated as a server administration problem, but the real accountability sits in identity lifecycle governance. When someone leaves or changes roles, the question is not who can log into a host manually, but who owns the process that removes standing access everywhere it was issued. That means HR-triggered offboarding, manager approval for role changes, and access revocation across bastions, jump hosts, configuration tools, and embedded keys.

NHI Management Group research shows why this matters: the Ultimate Guide to NHIs reports that only 20% of organisations have formal processes for offboarding and revoking API keys, and 91.6% of secrets remain valid five days after notification. The same lifecycle weakness applies to ssh key when ownership is unclear. If accountability is left with individual system administrators, revocation becomes inconsistent and stale access survives normal business change. In practice, many security teams encounter SSH drift only after an employee has already departed or a role transition has already widened access.

How It Works in Practice

Accountability should be assigned to the identity and access process owner, with operational execution delegated to platform, Linux, or cloud infrastructure teams. That split matters because SSH access is usually provisioned in more than one place: user accounts, authorized_keys files, PAM or bastion controls, CMDB records, and sometimes automation pipelines. The owner of the lifecycle must ensure every path is covered, while admins carry out the technical removal.

Current guidance from the OWASP Non-Human Identity Top 10 and NHI Management Group research supports a lifecycle approach: access should be tied to identity events, not ad hoc cleanup. A strong process usually includes:

• Offboarding and role-change triggers from HR or IAM into a ticketed revocation workflow.
• Central inventory of where SSH keys and privileged accounts exist, including shared hosts and automation accounts.
• Automatic key rotation or deletion when access is no longer required.
• Validation that the former employee’s access is gone from jump boxes, scripts, CI/CD runners, and any delegated admin tools.

For implementation detail on governance and lifecycle controls, the Ultimate Guide to NHIs — Key Challenges and Risks is a useful reference point. The operational goal is simple: the identity system should decide when access ends, and the host layer should only enforce that decision. These controls tend to break down in hybrid estates where SSH keys are embedded in scripts or handed off informally between teams because there is no authoritative inventory to revoke against.

Common Variations and Edge Cases

Tighter SSH governance often increases operational overhead, requiring organisations to balance revocation speed against the friction of legitimate admin work. That tradeoff is especially visible in environments with break-glass access, contractor support, or shared operational accounts. There is no universal standard for this yet, but best practice is evolving toward named accountability, short-lived access, and strong logging rather than permanent shared keys.

One common exception is emergency access. In those cases, the process should still be owned by identity governance, with time-bound approval, session recording, and automatic expiry. Another edge case is service automation that uses SSH for legacy workflows. Those keys should be treated as secrets, not human entitlements, and managed through rotation and scope restriction. The broader point aligns with the OWASP Non-Human Identity Top 10 and NHI Management Group’s lifecycle guidance: access removal has to be provable, not assumed. Where organisations lack an authoritative asset and identity map, revocation will always be incomplete because no one can confirm all the places SSH access was granted.

Related resources from NHI Mgmt Group

• How should security teams handle NHIs when employees leave or change roles?
• How should federal teams manage identity access when employees change roles or locations?
• What is the difference between rotating a secret and revoking access?
• What is the difference between access review and offboarding verification?