Switching to ephemeral certificates does not automatically invalidate existing SSH keys. If those keys remain configured, they can still authenticate and may be used outside the new control path. That means organisations can believe they have modernized access while unmanaged keys continue to grant entry. The practical failure is partial migration, where the old attack surface survives behind the new model.
What actually breaks in a partial SSH certificate migration
Ephemeral SSH certificates improve control only when they become the effective path for access, not just an additional path. If old keys remain present in authorized_keys, legacy config management, jump host rules, or automation logic, you have two parallel trust models. That split creates inconsistent authentication behavior, makes access reviews misleading, and leaves unmanaged credentials capable of authenticating long after the intended migration point.
The practical failure is not that certificates stop working. It is that the old keys still work too, so the organisation’s control plane no longer matches its actual access plane. Users, admins, and automation can keep using the fallback path, and security teams may mistakenly treat the environment as short-lived and tightly governed when it is still carrying long-lived credential exposure.
Why old SSH keys are the real residual attack surface
An ephemeral certificate model is designed to reduce standing access, shrink blast radius, and force reauthentication through a controlled issuance path. Old keys break that intent because they preserve independent authentication material outside the new lifecycle. If an attacker steals an old private key, or a forgotten public key remains trusted on a server, the new certificate layer does not neutralize that access.
That matters most in environments with shared admin access, automation, or heterogeneous servers. A partial cutover can hide stale trust relationships across home directories, imaging templates, deployment tooling, and exceptions made during migration. The result is a control that looks modern on paper but still depends on the same weak assumptions that certificates were meant to replace.
- Legacy keys can bypass the intended certificate issuance workflow.
- Access reviews can undercount real entry points if they only inspect certificate policy.
- Rotation and revocation lose value when unmanaged keys remain accepted by servers.
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 CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | Old SSH keys are retained secrets that keep authenticating after migration. |
| NHI-04 — Lifecycle and Offboarding | The issue is an incomplete access transition where old credentials are never retired. | |
| Recommendation — Remove legacy SSH keys from trust stores and enforce short-lived credential handling. Retire legacy keys during cutover and verify offboarding of every prior access path. | ||
| NIST CSF 2.0 | PR.AA-01 — Identity and Access Management | Authentication paths must reflect the intended access model after the switch to certificates. |
| Recommendation — Align server authentication rules with the new certificate-based access model. | ||
| CIS Controls v8 | 6.1 — Establish and Maintain a Risk-Based Access Control Process | Partial migration leaves unauthorized legacy access paths in place. |
| Recommendation — Remove residual key-based access as part of access control enforcement. | ||
Practitioner Guidance
What to verify: Confirm that old keys are removed from all server-side trust locations, not only from the identity system that issues certificates. Check for keys in authorized_keys, baked images, configuration management templates, CI or automation jobs, and emergency break-glass paths.
Decision rule: If a private key or public key pair can still authenticate to production, treat the migration as incomplete until that path is removed or tightly time-bound. Do not declare success from certificate issuance alone; success is only real when the legacy path no longer grants access.
Common mistake: Teams often rotate the new control and forget to retire the old one. That creates a dual-authority state where the environment appears modernized while the original standing access surface remains live.
Practitioner takeaway: The security gain from ephemeral SSH certificates comes from elimination of durable trust, not from adding a second login method. If the old keys remain accepted, the organisation has not reduced access risk, it has only added a newer layer on top of the old one.
Related resources from NHI Mgmt Group
- What breaks when organisations leave old Group Policy Preferences password policies in place after patching?
- Why do ephemeral credentials still leave risk in machine access models?
- Should organisations use SSH certificates instead of long-lived keys?
- What breaks when SSH keys and certificates are not rotated or revoked?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
