Who is accountable when a GitLab SSH key is left active after offboarding?

Why This Matters for Security Teams

An active GitLab ssh key after offboarding is not just a cleanup miss. It is a standing path back into code, pipelines, and secrets-bearing automation. That makes the accountable owner the team that governs GitLab identity and access, but the failure chain usually crosses HR, IAM, and engineering operations. Current guidance from the NIST Cybersecurity Framework 2.0 treats identity lifecycle control as an operational discipline, not a one-time admin task.

NHI Management Group research shows why this is high risk in practice: only 20% of organisations have formal offboarding and revocation processes for api key, and 91.6% of secrets remain valid five days after notification. That gap matters because a GitLab SSH key can keep access alive long after the person has left, especially when it is embedded in automation or shared across repos. The right question is not who clicked “disable,” but who owns revocation end to end. In practice, many security teams discover this only after a departed user still has a working path into production repositories, rather than through intentional offboarding testing.

For lifecycle context, see the NHI Lifecycle Management Guide and the Top 10 NHI Issues.

How It Works in Practice

Accountability should be assigned to the GitLab access governance owner, usually within the identity or platform function, because that team can actually enforce revocation in GitLab and connected systems. But operationally, offboarding only works when HR triggers the event, IAM updates identity status, and engineering operations removes any SSH keys, deploy keys, runner credentials, and automation references tied to the departing person. This is why a simple “terminated” flag is insufficient if the key was copied into scripts, CI variables, or a shared vault.

The practical control model is straightforward:

• Make GitLab key revocation part of the offboarding workflow, not a manual follow-up.
• Inventory all places the key may exist, including local machines, CI/CD jobs, and shared admin tooling.
• Use short-lived credentials where possible so access expires automatically instead of relying on human recall.
• Require an owner for each key, service account, or automation identity so accountability is explicit.
• Validate revocation with post-offboarding checks, not just ticket closure.

That approach aligns with the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs, which emphasizes lifecycle control, visibility, and timely removal of access. It also maps cleanly to NIST CSF identity management expectations and to the broader principle that access should be explicitly granted, reviewed, and removed. Where organisations get into trouble is when GitLab is treated as a developer tool rather than an identity-sensitive production control plane. These controls tend to break down when SSH keys are reused across multiple repos or automation jobs because revocation then requires tracing hidden dependencies before access can truly be removed.

Common Variations and Edge Cases

Tighter offboarding control often increases operational overhead, requiring organisations to balance fast revocation against developer workflow friction. That tradeoff is real, especially in teams that rely on shared service accounts, legacy deploy keys, or ad hoc access for incident response. Current guidance suggests treating those exceptions as temporary, not normal.

There is no universal standard for key ownership in every GitLab deployment, so the accountable party can vary by operating model. In smaller organisations, the platform team may own both GitLab administration and offboarding enforcement. In larger environments, ownership may split between IAM, platform engineering, and application owners, but accountability should still land on one named function for audit purposes. If an SSH key is attached to a bot, the bot’s business owner becomes part of the accountability chain because the key is now an operational identity, not a human convenience.

One common mistake is assuming that deleting the user account is enough. It is not, if the SSH key also exists in runner configurations, container images, or deployment scripts. For incident-driven evidence, the CI/CD pipeline exploitation case study shows how access paths persist when build and deployment systems are not included in identity cleanup. In short, accountability sits with the team that owns GitLab access governance, but the technical risk expands wherever that key has been replicated or automated.

Related resources from NHI Mgmt Group

• Who is accountable when a non-human identity is over-privileged or left active after offboarding?
• Who is accountable when orphaned access appears after offboarding?
• Who is accountable when access is left active after a role change or departure?
• Who is accountable when user access remains active after offboarding?