How should security teams handle legacy certificate data that will not be migrated?

Treat it as a separate retention and export problem, not as part of the technical cutover. If old orders, inactive certificates, or historical records matter for audit or support, export them before the legacy platform is decommissioned. Teams should not assume the replacement portal will automatically preserve non-active records.

What “not migrated” means in a certificate program

When legacy certificate data will not move into the new platform, the issue is not just technical conversion. The team needs to decide which records remain part of the operational certificate lifecycle and which records are preserved only for retention, audit, or support. That distinction matters because inactive or historical certificate data can still be evidence, even when it no longer drives live trust decisions.

In practice, the certificate set usually splits into active objects, such as certificates still serving traffic, and inactive objects, such as old orders, expired certificates, revoked certificates, and issuance history. If the new portal only carries the active estate, the old platform becomes a source system for archived records rather than a continuation of the live management plane.

That separation is especially important for recordkeeping tied to certificate lifecycle and key management. Machine Identity, PKI and Certificate Lifecycle Guide is useful context because certificate data is not just metadata, it often captures issuance state, renewal timing, expiry history, and trust-chain decisions that teams may need later.

How to preserve the records you will still need

Security teams should treat unmigrated certificate data as an export and retention workstream, with a defined owner and a clear cutoff date. The practical question is which records must be preserved in a usable form, which can be summarized, and which can be securely disposed of once retention obligations are met. That decision should happen before decommissioning, not after the legacy system is already gone.

At minimum, teams should identify whether the export needs to support audit evidence, incident investigation, renewal troubleshooting, vendor support, or historical change review. Old orders and historical certificate records often matter because they show when a certificate was issued, replaced, revoked, or allowed to expire. If those facts cannot be reconstructed elsewhere, the legacy platform is the only safe place to capture them before shutdown.

CA/Browser Forum is relevant here because certificate issuance and revocation expectations do not disappear when a portal is retired. The archive does not need to remain operational, but the organization still needs a defensible record trail for what was issued, when it was revoked, and how the transition was handled.

Why migration gaps create operational and audit risk

The main risk is assuming the replacement portal will preserve everything that existed in the old one. In many migrations, only the current certificate inventory is brought across, while old orders, expired certificates, and historical support records are left behind. If that happens without a planned export, the team loses visibility into prior trust decisions and may be unable to answer routine audit or incident questions later.

NIST SP 800-57 Key Management helps frame the lifecycle issue: records tied to cryptographic material have value beyond the active cryptographic object itself, because history, rotation, and retirement all affect how teams explain and govern the system. When the old platform is removed too early, the organization can lose proof of what existed and why a control decision was made.

Failure mechanism: The legacy system is decommissioned before a complete export is taken, or the export omits non-active records that later prove important for audit, support, or incident reconstruction.

Impact: Teams lose historical evidence, create gaps in retention and support, and may be unable to verify prior issuance, revocation, or expiry activity when questions arise.

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 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-57	Key Management	Certificate history and lifecycle decisions are part of key lifecycle governance.
Recommendation — Preserve lifecycle records that explain issuance, rotation, revocation, and retirement decisions.
ISO/IEC 27001:2022	A.5.33 — Protection of Records	Legacy certificate data may need retention as auditable records before decommissioning.
Recommendation — Classify certificate history as records and retain exports under formal retention rules.
CIS Controls v8	CIS-3 — Data Protection	Historical certificate exports must be protected and retained outside the retired platform.
Recommendation — Secure exported certificate records and verify recoverability after migration.

Practitioner Guidance

What to prioritise: Separate active migration from historical preservation. Export old orders, inactive certificates, revocation history, and any record set needed to explain issuance or support decisions before cutover, then confirm where the archive will live and who owns it.

What to verify: Check that the exported data is readable outside the legacy portal, includes enough context to identify each certificate event, and is retained for the period your audit, legal, or operational policy requires. If the only copy depends on the soon-to-be-retired platform, the export is not yet done.

Practitioner takeaway: Treat certificate history as evidence, not just leftover data, because once the legacy platform is gone you may lose the only reliable record of how the certificate estate was issued and governed.