Yes, when the existing trust fabric supports live production systems. Keeping legacy certificate authorities in place during phased migration avoids a risky big-bang cutover, lets teams grandfather roots of trust into the new model, and reduces the chance of accidental service breakage.
Why legacy certificate authorities are often kept alive during migration
Legacy certificate authorities are usually retained only as long as they still anchor live trust paths. The migration goal is not to preserve old infrastructure forever, but to avoid breaking authentication, mutual TLS, code signing, device trust, or internal service communication before replacement trust bundles and renewal paths are proven in production.
Keeping the old CA running can also give teams time to map every dependent system, identify hard-coded trust stores, and retire certificates in a controlled order. That matters because certificate trust is often embedded in applications, appliances, and automation that are harder to replace than the CA itself.
What makes a CA safe to keep temporarily?
A legacy CA is defensible only when its scope is tightly bounded, its private keys are protected, and its issuance rules are understood. The practical test is whether the old CA is still needed for systems that cannot yet trust the new chain, while the migration plan already defines who can issue, renew, and revoke during the overlap.
For certificate lifecycle questions, the important control is not just whether a CA exists, but whether certificate inventory, expiration, renewal, and revocation are being actively managed. NHIMG’s Machine Identity, PKI and Certificate Lifecycle Guide is useful here because it frames certificates as a lifecycle problem, not a one-time migration event.
In practice, the safest overlap period is short, visible, and purpose-limited. If the old CA is still issuing broadly, or if no one can prove which workloads still depend on it, the migration has drifted from controlled coexistence into unmanaged dual trust.
How should teams retire the legacy CA without breaking trust?
The transition should follow the trust graph, not the org chart. Teams should start by discovering every certificate consumer, then migrate the highest-risk dependencies first, and only then reduce legacy issuance. Internal trust bundles, device fleets, and service-to-service clients often need a staged cutover rather than a single replacement date.
This is where the surrounding trust architecture matters. Guide to SPIFFE and SPIRE is a good conceptual complement because it shows how workload identity and trust bundles can reduce dependence on ad hoc certificate handling during the move to a new model.
External guidance also points in the same direction. CA/Browser Forum requirements reflect the broader industry emphasis on controlled issuance and revocation, while NIST SP 800-57 Key Management reinforces that cryptographic trust material should be governed through lifecycle discipline, not left in place indefinitely.
Risk and Threat Considerations
Keeping a legacy CA alive reduces cutover risk, but it also extends the period in which an older trust root can be abused, misissued, or forgotten. The biggest failure mode is not the coexistence itself, it is the assumption that coexistence is temporary when in fact the old CA becomes a permanent shadow trust path.
Failure mechanism: Stale CA infrastructure, untracked issuance authority, or long-lived certificates can preserve trust after the migration has moved on, creating unauthorized renewal, lateral movement, or persistence opportunities if the old trust path is compromised.
Impact: An attacker who reaches the old CA, or any certificate issuance workflow still bound to it, may be able to mint trusted credentials, impersonate services, or keep access alive beyond the intended migration window.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-57, NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-57 | Key management lifecycle | Certificate authorities and trust roots require controlled lifecycle handling during migration. |
| Recommendation — Apply key lifecycle governance to the old CA, including rotation, revocation, and retirement timing. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | CA migration depends on managing certificate issuance, renewal, and revocation material. |
| IA-9 — Service Identification and Authentication | Legacy CA trust often supports service-to-service authentication during phased cutover. | |
| Recommendation — Manage certificate material through defined issuance, rotation, and revocation processes. Preserve service authentication continuity while migrating trust to the new CA chain. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | CA coexistence affects who may issue and trust certificates during transition. |
| Recommendation — Restrict CA administration and issuance authority to approved migration owners. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication and Access Control | Certificate trust migration is an access-control and authentication continuity issue. |
| Recommendation — Maintain authenticated trust paths while phasing out the legacy certificate authority. | ||
Practitioner Guidance
What to verify: Before you keep the legacy CA in service, verify which production systems still chain to it, which certificates depend on it, and whether revocation, renewal, and rotation are observable end to end. If you cannot name the dependent systems, the CA is already too exposed to keep running casually.
Decision rule: Keep the legacy CA only when it is still required for live trust continuity and you can bound its issuance scope. If the old CA is no longer needed for production trust, retire it aggressively rather than leaving it available as a convenience path.
Common mistake: Treating CA migration as a documentation exercise instead of a trust-cutover exercise. The real control point is whether every consumer can validate the new trust chain before the old one is removed.
Practitioner takeaway: Temporary coexistence is reasonable, but only when the legacy CA is tightly governed, actively monitored, and tied to a dated retirement plan. If the migration does not reduce old-trust exposure over time, it is not really a migration.
Related resources from NHI Mgmt Group
- What breaks when organisations delay post-quantum migration for sovereign certificate authorities?
- How do organisations decide whether to keep Ingress support during a gateway migration?
- How should organisations replace legacy ERP access controls without creating audit gaps during migration?
- How can organisations keep marketing operations running during phone outages without weakening account security?
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 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org