What should security teams do first when migrating certificate management off a legacy PKI platform?

The first priority is to build an accurate inventory and then reroute lifecycle operations in a controlled way. Start by importing existing keys and certificates, synchronising internal and public certificate sources, and confirming how enrollment, renewal, and revocation will be handled. That gives teams a stable baseline before they replace workflows or co-exist with the legacy system.

Start with a complete certificate inventory, not a workflow cutover

The first move is to establish what exists, where it lives, who owns it, and which systems depend on it. For a legacy PKI migration, that means reconciling issued certificates, private keys, issuing CAs, renewal schedules, revocation paths, and every internal or public source of record before any platform switch is attempted.

That inventory is the control point that prevents blind spots during coexistence. Importing existing keys and certificates, then validating coverage across environments, lets teams see what is still active, what is already expired, and what must remain under the old platform until replacement processes are proven.

A useful way to think about this step is that certificate migration is really lifecycle migration. The technical success criterion is not simply that a new platform can issue certificates, but that enrollment, renewal, revocation, and discovery continue to work while authority is being transferred.

Reroute enrollment, renewal, and revocation as separate operational paths

Once inventory is in place, the next concern is how lifecycle operations will be handled during transition. Enrollment, renewal, and revocation should be treated as distinct flows because each one has different failure modes, different integration points, and different blast radius if it breaks.

Controlled rerouting usually starts with renewal, because it reveals whether the new platform can safely replace the old issuance path without forcing a broad reissue event. Revocation must also be explicitly designed, because a migration that can issue new certificates but cannot revoke old ones cleanly leaves the organisation with duplicated trust paths and uncertain response capability.

That is why coexistence is often safer than a hard cutover. The legacy PKI platform can remain as the fallback source while new workflows are validated, but only if ownership, source-of-truth logic, and rollover timing are clearly defined.

Stabilise trust boundaries before decommissioning the old PKI

The end state is not just a new tool, it is a new trust boundary. Security teams should confirm which systems trust the legacy CA chain, which applications pin certificates or intermediates, and whether any devices, services, or external partners still depend on the old hierarchy.

For public certificates, baseline issuance and revocation expectations should be aligned to the current browser ecosystem, while private PKI decisions should reflect how keys are protected, how long certificates remain valid, and whether automation is required to avoid operational drift. The migration should not create a period where both old and new trust stores are accepted without clear ownership.

That is also where certificate inventory becomes a security function, not just an administrative one. A stale certificate map can leave hidden dependencies behind after the legacy platform is retired, which is how migrations turn into outages or shadow trust relationships.

Risk and Threat Considerations

Certificate migration fails most often when teams underestimate hidden dependencies and lifecycle coupling. The main exposure is not just outage risk, it is the possibility that untracked certificates, keys, or revocation paths continue to authenticate systems after the supposed cutover.

Failure mechanism: Missing inventory or incomplete lifecycle mapping leaves old certificates in service, breaks renewal automation, or strands revocation behind the legacy platform, creating trust gaps or duplicate trust paths.

Impact: Systems can fail open, fail closed, or continue operating on unmanaged certificates, which increases outage risk, weakens incident response, and makes it harder to prove which identities are still trusted.

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, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST SP 800-57	Key Management	Certificate migration depends on key lifecycle, cryptoperiods, and controlled replacement of trust material.
Recommendation — Apply key lifecycle discipline to inventory, rotate, and retire certificate material in a controlled sequence.
CIS Controls v8	CIS-5 — Account Management	Certificate platforms require ownership, lifecycle visibility, and controlled removal of obsolete trust paths.
Recommendation — Track and remove obsolete certificate trust paths as part of asset and account lifecycle control.
NIST SP 800-53 Rev 5	IA-5 — Authenticator Management	Certificates are authenticators whose issuance, renewal, and revocation must be managed during migration.
	IA-9 — Service Identification and Authentication	Migrating PKI affects service-to-service certificates and the systems that authenticate with them.
	CM-8 — System Component Inventory	A complete certificate inventory is the prerequisite for safe PKI migration and dependency mapping.
Recommendation — Manage certificate issuance, renewal, and revocation as controlled authenticator lifecycle events. Validate service authentication dependencies before switching certificate authority sources. Build and maintain an authoritative inventory of certificates, keys, and dependent systems.

Practitioner Guidance

What to verify: Before moving any workload, verify that you can enumerate every active certificate, map each one to an owner and renewal date, and prove where revocation will be executed during the migration window. If you cannot produce that evidence, the migration is not ready for cutover decisions.

Implementation sequence: Start with discovery and reconciliation, then import and normalise existing keys and certificates, then test lifecycle routing in parallel with the legacy platform, and only then retire old issuance paths by segment or certificate class.

Practitioner takeaway: The safest first step is to make certificate lifecycle visible end to end, because migration succeeds only when teams can control issuance, renewal, and revocation before they try to replace the platform.