The organisation loses track of which keys are still valid, which systems still trust them, and whether a retired person or workflow can still reach critical repositories. That creates persistent access paths that are hard to detect and harder to prove safe. Rotation and expiry are what prevent keys from becoming dormant but active credentials.
Why This Matters for Security Teams
Unrotated or expired GitLab ssh key are not just stale credentials. They are durable trust relationships that can survive role changes, contractor offboarding, and pipeline drift long after the original owner has moved on. That is why NHI lifecycle controls matter: once a key is trusted by GitLab, downstream systems, deploy jobs, and automation often keep accepting it until someone actively revokes it. NHI Mgmt Group notes that Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs highlights how lifecycle gaps are a primary cause of persistent exposure, and the broader risk is reflected in the fact that 71% of NHIs are not rotated within recommended time frames.
For practitioners, the failure is not limited to key hygiene. It affects auditability, incident response, and privilege boundaries because GitLab SSH keys often bridge human admin access, service automation, and CI/CD execution. The OWASP Non-Human Identity Top 10 treats credential lifecycle weakness as a core exposure because dormant secrets are still live secrets when systems continue to trust them. In practice, many security teams discover the problem only after a former employee, forgotten integration, or exposed deploy key has already been used to reach a critical repository.
How It Works in Practice
GitLab SSH keys commonly fail in three ways: they are created once and never revisited, they are shared across multiple repositories or automation paths, or they are left in place after a workflow is retired. In a mature environment, the correct pattern is to treat each key as a time-bound workload credential, not a permanent identity artifact. That means assigning an owner, setting an explicit expiry, tracking where the key is accepted, and revoking it when the work it supports ends.
For GitLab operations, the practical control set usually includes key inventory, short TTLs, documented break-glass exceptions, and automated removal from users and service accounts during offboarding. Where possible, teams should prefer ephemeral or dynamically issued credentials over long-lived SSH keys, because the blast radius is smaller and the revocation path is clearer. The NHI Lifecycle Management Guide and the Guide to the Secret Sprawl Challenge both point to the same operational reality: if teams cannot answer who owns a key, where it is used, and when it expires, they cannot prove it is safe.
- Map every GitLab SSH key to a human owner or workload owner.
- Set expiry dates and rotate keys on a schedule tied to risk, not convenience.
- Remove shared keys from shared workflows and replace them with per-service identities where possible.
- Revoke keys immediately when a developer, contractor, or automation path is retired.
- Audit GitLab access logs and repository activity for use of keys past their expected lifecycle.
Current guidance suggests pairing ssh key lifecycle with secrets management and offboarding workflow rather than treating it as an isolated GitLab task. These controls tend to break down when keys are embedded in CI/CD variables or copied into deployment scripts because the revocation path becomes indirect and incomplete.
Common Variations and Edge Cases
Tighter key rotation often increases operational overhead, requiring organisations to balance access continuity against the risk of persistent compromise. That tradeoff becomes sharper in legacy GitLab estates, self-managed runners, and air-gapped environments where automation is weak and owners are unclear. In those cases, best practice is evolving toward shorter-lived credentials plus stronger inventory rather than relying on static keys with manual review.
Some teams keep long-lived SSH keys for emergency access or vendor support, but those exceptions need explicit approval, narrow scope, and compensating controls such as vaulting, monitoring, and scheduled revalidation. Another edge case is machine-to-machine deploy access in CI pipelines: if the key is tied to a pipeline rather than a person, it still needs ownership, expiry, and revocation criteria. NHI Mgmt Group’s Guide to NHI Rotation Challenges is useful here because rotation failures often stem from process friction, not policy absence.
Where organisations lack full visibility into service accounts and keys, the immediate priority is not perfect rotation. It is establishing a trustworthy inventory, then reducing exposure on the highest-privilege and least-justified keys first. That approach aligns with the broader Top 10 NHI Issues research, which shows that unmanaged lifecycle is usually the point where dormant access becomes active risk.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Covers rotation and lifecycle weakness for non-human credentials. |
| NIST CSF 2.0 | PR.AC-1 | Addresses identity proofing and access enforcement for credentials. |
| NIST CSF 2.0 | PR.AC-4 | Least privilege and access management apply directly to key use. |
Set expiry, rotate GitLab keys routinely, and revoke any key that lacks a current owner.
