When SSH credentials are not rotated or revoked, access can outlive the job, the vendor relationship, or the incident that should have ended it. That creates standing privilege, weakens audit confidence, and increases the chance that a compromised key can be reused across hosts.
Why This Matters for Security Teams
When ssh key and certificates are not rotated or revoked, the failure is not just technical hygiene. It is a lifecycle control failure that leaves access valid after the person, vendor, system, or incident that justified it has changed. That turns a temporary credential into standing privilege, which undermines least privilege, incident containment, and audit defensibility. The NHI Lifecycle Management Guide frames this as a core governance problem, not a credential housekeeping task.
Security teams often underestimate how quickly forgotten SSH access becomes a lateral movement path. A key that was issued for a maintenance window can remain valid across build hosts, admin jump boxes, or vendor support accounts long after the intended job is done. In parallel, certificate expiry and revocation gaps can break availability in ways that look like an operations issue but are actually a trust-management failure. The OWASP Non-Human Identity Top 10 treats overlong credential validity and weak lifecycle enforcement as recurring NHI risks. In practice, many security teams discover dormant SSH access only after an incident review, rather than through intentional offboarding or rotation discipline.
How It Works in Practice
For SSH, rotation means replacing key material before it becomes stale, exposed, or shared across too many hosts. Revocation means making sure a lost, stolen, terminated, or over-scoped credential can no longer authenticate. For certificates, the mechanics are stricter because trust is bound to issuing authority, validity period, and revocation status. Current guidance suggests treating both as short-lived credentials where possible, rather than long-lived assets that depend on humans to remember cleanup.
A practical control model usually includes:
- Unique keys or certificates per workload, user, or support relationship.
- Short TTLs aligned to the actual task, not an arbitrary calendar schedule.
- Automated renewal and revocation through policy-driven workflows.
- Central inventory so owners can trace where each credential is used.
- Logging for issuance, use, renewal, and invalidation events.
The operational value is simple: if an SSH credential is still valid after access should have ended, it can be reused from any environment that still trusts it. That is why machine identity work often pairs rotation with lifecycle visibility. SailPoint’s Critical Gaps in Machine Identity Management report notes that only 38% of organisations have automated certificate lifecycle management in place, while 45% report certificate expiry as a leading cause of outages. That combination shows the two-sided risk: credentials linger too long when teams fear disruption, but they also fail suddenly when no one is watching. These controls tend to break down in legacy fleets that lack a central trust service because revocation cannot be enforced consistently across every host.
Common Variations and Edge Cases
Tighter rotation often increases operational overhead, requiring organisations to balance reduced exposure against deployment complexity and outage risk. That tradeoff becomes sharper in environments with embedded devices, legacy SSH daemons, air-gapped hosts, or vendor-managed appliances where standard revocation flows are not available.
Best practice is evolving, but current guidance suggests using different treatment by credential type. Human-admin SSH access may tolerate shorter-lived certificates backed by strong approval and audit trails. Service-to-service access should move toward workload identity and ephemeral credentials, not static private keys copied into automation. Where certificate revocation checking is unreliable, many teams rely on very short validity windows and rapid re-issuance instead of assuming CRLs or OCSP will be enough. That is not a universal standard for every environment, but it is often the safer operational compromise.
Another edge case is incident response. A revoked key that still exists on disk, in a CI/CD variable, or in a backup archive may reappear later unless offboarding covers all copies, not just the active one. NHIMG’s Static vs Dynamic Secrets guidance is relevant here, as is the Guide to NHI Rotation Challenges. The real failure mode appears when a credential is revoked in policy but remains trusted in practice because some host, backup, or automation path was missed.
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 AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Addresses credential rotation and revocation failures for non-human identities. |
| NIST CSF 2.0 | PR.AA-03 | Identity proofing and credential lifecycle controls support secure access termination. |
| NIST AI RMF | Lifecycle governance and ongoing monitoring are central to managing autonomous access risk. |
Use AI RMF governance practices to ensure credential decisions are owned, monitored, and auditable.
