Treat them as parts of the same trust fabric rather than separate technical tasks. One inventory, one ownership model, and one lifecycle process reduce blind spots, align accountability, and make automation workable across hybrid infrastructure.
One lifecycle means one control plane
Certificates and SSH keys create the same practical problem: they let a non-human or administrative actor prove trust and gain access. When teams manage them in separate silos, they usually duplicate inventories, miss shared owners, and create uneven rotation rules. A single control plane makes expiry, revocation, and exception handling consistent across both.
The useful mental model is not “PKI versus SSH,” but “trust material with different formats.” That means the governance question is the same even when the implementation differs: who owns it, where is it used, how long should it live, and what must happen when it is no longer trusted?
What a shared lifecycle has to cover
A joint lifecycle needs one inventory, one owner, and one policy model that can still express different technical requirements. Certificates may need CA coordination, renewal automation, and chain validation, while SSH keys may need host-level cleanup, SSH key discovery, and removal from authorized access paths. The shared process should therefore track issuance, usage, renewal, rotation, revocation, and retirement in a way that works for both artifacts.
That is also why lifecycle governance should include environment scope and trust scope. A key or certificate that still works in one environment but not another can look “managed” while still creating exposure. If ownership, purpose, and expiration are not recorded at the same place, teams end up with partial truth rather than a real inventory.
How to make the lifecycle operational instead of theoretical
Automation works best when the lifecycle is normalized first. For certificates, that usually means automated issuance and renewal with clear policy boundaries; for SSH keys, it means discovery, assignment to a named owner or service, and timely removal when access ends. Machine identity and certificate lifecycle automation is especially useful when certificate renewal failures can create outages, while SSH hygiene benefits from the same ownership and expiry discipline.
Teams also need a common revocation and exception model. If a certificate is compromised, renewal is not the question, revocation is. If an SSH key is orphaned, the decision is not whether it is still “probably okay,” but whether it still belongs to an active identity or system. Treating both as lifecycle events lets teams respond with the same governance logic even if the technical actions differ.
Where the trust fabric breaks down
Most failures come from blind spots, not from the formats themselves. Long-lived credentials, forgotten keys on old hosts, unmanaged renewal windows, and ownership gaps turn a routine trust mechanism into a latent access path. When certificates and SSH keys are governed separately, teams often rotate one class aggressively while leaving the other to manual cleanup.
That asymmetry is exactly what attackers and incident responders exploit. A revoked certificate that is still trusted somewhere, or an SSH key that was never removed from a decommissioned system, can preserve access long after the original need has ended. Cryptographic key management guidance is relevant here because the same core control objective applies, keep trust material bounded, inventoried, and recoverable when trust changes.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST SP 800-57 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Covers lifecycle control of certificates and SSH keys as authenticators. |
| IA-2 — Identification and Authentication (Organizational Users) | Applies where SSH keys and certificates authenticate staff or admins. | |
| IA-9 — Service Identification and Authentication | Applies when certificates or SSH keys authenticate services, workloads, or automation. | |
| Recommendation — Centralize issuance, rotation, revocation, and replacement of authenticators. Bind administrative access to managed, traceable authentication records. Use managed machine authentication and retire stale service credentials promptly. | ||
| NIST SP 800-57 | Key Management Recommendations | Directly addresses key lifecycle, cryptoperiods, rotation, and secure retirement. |
| Recommendation — Set cryptoperiods, rotate on compromise, and retire keys under one policy. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity management | Supports unified ownership and accountability for trust material. |
| Recommendation — Assign clear ownership for each certificate and SSH key lifecycle. | ||
Practitioner Guidance
What to prioritise: Start by defining a single inventory schema that captures owner, purpose, system, environment, expiration, and rotation path for both certificates and SSH keys. If you cannot answer those five fields quickly, the lifecycle is not yet governable.
What to verify: Confirm that revocation, renewal, and offboarding are all tested end to end. A lifecycle is only real if the team can prove it removes access from production systems, not just if it can describe the policy.
Common mistake: Do not let “different technology” become an excuse for different accountability. The control objective is the same, trusted material must be discoverable, attributable, and removable before it becomes stale.
Practitioner takeaway: The strongest governance model is the one that treats certificates and SSH keys as the same class of expiring trust evidence, then lets the technical differences sit underneath that shared ownership and retirement process.
Related resources from NHI Mgmt Group
- How should security teams govern SSH certificates in Linux environments?
- How should security teams govern SSH keys in cloud and server environments?
- How should teams govern cryptographic keys and certificates across hybrid environments?
- How should security teams govern certificates and keys as identity assets?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 12, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org