Migration Best Practices

What migration best practices mean

A migration is the controlled movement from existing cryptographic mechanisms, algorithms, keys, certificates, protocols, libraries, hardware, or services to a new approved or required state. In a security program, the objective is not merely to replace an algorithm. The program must preserve the security services that cryptography provides, maintain availability and interoperability, protect keys, and keep applications and operating processes usable during the transition. NIST SP 800-57 describes key-management guidance for developers and system administrators, while NIST SP 800-131A addresses transitions between algorithms and key lengths and the need to plan for future cryptographic changes.12

For PQC, scope should include digital signatures, key establishment, encryption, authentication, code signing, certificates, network protocols, software cryptographic libraries, cryptographic hardware, PKI, applications, cloud services, and embedded or operational technology. NIST IR 8547 IPD identifies these areas as migration considerations and notes that applications may need implementation changes, testing, library and protocol updates, and sometimes code or interface redesign.3

Why disciplined migration matters

Cryptographic migration is time-sensitive even when the triggering threat is not immediate. NIST IR 8547 IPD states that no existing cryptographically relevant quantum computer currently threatens the cited security levels, but also says that transitioning to new PQC algorithms will take significant time; past cryptographic migrations have taken over a decade, and this more complex migration will likely take at least that long. The same document presents the logic commonly associated with “harvest now, decrypt later”: an organization must account for the years its data must remain secure and the years required to complete migration when judging urgency.3

The risk is not limited to confidentiality. Digital signatures support identity, authorization, software and firmware updates, certificates, and document integrity. In OT and industrial control environments, the integrity of sensor data and commands can be critical even where confidentiality is less demanding, because faulty readings or commands can contribute to control-system failure. Remote access channels, wireless field devices, sensors, and connections between OT and IT therefore require explicit treatment.6

Migration also affects operational resilience. New algorithms can change key sizes, certificate sizes, message sizes, computation cost, memory requirements, latency, network behavior, and device compatibility. Applications and services may need updated protocols and libraries, refactored code, extensive testing, and redesigned interfaces. These effects make migration a business and engineering program with security gates, rather than a one-time configuration change.36

A practical migration workflow

A repeatable workflow gives security teams a defensible way to move from uncertainty to controlled remediation. The stages below can be adapted to the organization’s risk tolerance, regulatory environment, technology estate, and supplier constraints.4

1. Establish governance and scope. Create a project management team with authority across information technology, operational technology, procurement, architecture, application ownership, infrastructure, security, risk, and business operations. Define the migration objective, decision rights, dependencies, exception process, funding assumptions, and reporting cadence.
2. Inventory cryptography and dependencies. Use discovery activities and tools to identify algorithms and cryptographic uses in network protocols, end-user systems, servers, applications, libraries, software, firmware, PKI, devices, cloud services, and supplier products. Record where keys and certificates are created, stored, used, rotated, revoked, and trusted.
3. Assess impact and prioritize. Link every cryptographic dependency to the data, function, system, owner, exposure, operational criticality, and required security life. Give early attention to high-impact systems, ICS, long-term confidentiality or secrecy needs, externally accessible datasets, and technologies that cannot be upgraded easily.
4. Define target states and transition patterns. Decide where replacement, upgrade, compensating controls, or decommissioning is appropriate. For PKI, plan the new root of trust, certificate issuance, trust distribution, revocation, device enrollment, and staged coexistence or controlled cutover. Where justified by the applicable standards and application risk, evaluate hybrid key-establishment or dual-signature approaches rather than assuming one pattern fits every system.
5. Plan suppliers and contracts. Obtain each COTS, cloud, managed-service, and embedded-device supplier’s PQC or cryptographic-transition roadmap, expected delivery dates, configuration requirements, upgrade path, cost, support period, and limitations. Record dependencies and make unresolved supplier commitments visible as risks.
6. Build and test migration increments. Start with representative systems and progressively expand. Test functional behavior, interoperability, certificate and key handling, performance, capacity, availability, logging, monitoring, recovery, and security controls. Verify that systems use the intended new mechanisms and do not silently fall back to traditional cryptography.
7. Operate, measure, and retire. Track adoption, exceptions, unresolved inventory records, supplier readiness, test results, and failures. Retire vulnerable mechanisms only after approved criteria are met, rollback or recovery is understood, and evidence shows that required clients, services, and devices no longer depend on them.

Inventory first, then prioritize by consequence

A cryptographic inventory is the foundation for rational sequencing. The joint CISA, NSA, and NIST fact sheet recommends identifying the organization’s reliance on quantum-vulnerable cryptography and connecting that inventory to the criticality of the protected data or function. Inventory records should cover both IT and OT and should include supply-chain technologies. Discovery should look beyond obvious encryption settings: signatures, certificate validation, software and firmware signing, network protocols, application libraries, key stores, authentication systems, and embedded devices can all determine whether a migration is complete.4

Prioritization should combine technical exposure with consequence. A useful order is: systems whose compromise would have high operational or safety impact; systems exposed to external access; data whose confidentiality must persist for many years; systems supporting identity, code signing, certificate trust, or security updates; and assets that are difficult, slow, or impossible to upgrade. The joint fact sheet specifically calls for priority attention to high-impact systems, ICS, and long-term confidentiality or secrecy needs. NIST SP 800-57 also indicates that key-management decisions depend on factors such as the security life of data, transaction volume, security function, operating environment, rekeying method, and number of nodes.42

Architecture and implementation considerations

Design the target architecture around replaceability. Keep cryptographic choices visible and centrally governed where practical; avoid scattering algorithm assumptions through application code, certificate profiles, protocol negotiation, hardware dependencies, and operational procedures. NIST’s crypto-agility material describes the goal as adapting algorithms across protocols, applications, software, hardware, firmware, and infrastructure while preserving security and operations. The design should therefore include controlled configuration, documented dependencies, upgradeable interfaces, tested protocol negotiation, and a way to distinguish approved transition states from accidental fallback.5

Backward compatibility and interoperability are essential during transition. NIST IR 8547 IPD emphasizes maintaining compatibility and interoperability to preserve trust and security across the network. A staged approach may require traditional and new mechanisms to coexist temporarily. For enterprise PKI, the NCSC describes a possible parallel PQC PKI with a new root of trust and new certificates, operating alongside the traditional PKI during a staged migration; some controlled environments may instead support a direct cutover. The appropriate model depends on protocol capability, device support, operational risk, and the ability to issue and distribute trust material.6

Hybrid key establishment or dual signatures may be considered where the application can bear the implementation cost, performance reduction, engineering complexity, and independent security-review requirements. NIST IR 8547 IPD states that the decision is application-specific and that its discussion does not make hybrid operation universally necessary. Treat such designs as risk decisions requiring explicit interoperability, failure-mode, and assurance testing.3

Key management remains part of migration, not a separate afterthought. Select appropriate algorithms, key lengths, cryptographic policies, modules, storage, access controls, rekeying methods, certificate lifetimes, and destruction procedures. NIST SP 800-57 notes that cryptoperiods may vary with the application and environment; its suggested periods are not automatic substitutes for an organization’s risk analysis. NIST SP 800-131A further distinguishes approval states such as acceptable, deprecated, and disallowed, and explains that status can depend on algorithm, key length, parameters, and manner of use.21

Testing, assurance, and measures

A migration is not complete because a new option is installed. Test whether the production path actually negotiates or uses the intended mechanism, whether clients and services interoperate, and whether security controls remain effective. The NCSC recommends additional testing to confirm that standardized PQC cipher suites are being used rather than systems falling back to traditional cryptography. Testing should include negative cases, unsupported clients, certificate and trust failures, rollback, key compromise response, logging, monitoring, performance, capacity, and recovery.6

Use measures that describe both progress and residual risk. Useful measures include the proportion of identified assets with an accountable owner; inventory coverage; the number and criticality of unresolved quantum-vulnerable dependencies; the percentage of software clients using the intended new mechanism; the number of clients still using traditional algorithms; supplier roadmap coverage; completed and failed migration tests; systems with approved exceptions; and the count of legacy dependencies approved for retirement. The NCSC specifically identifies quantifying software clients using PQC and identifying those that are not as a way to gauge progress, trigger remedial action, and determine when traditional algorithm support can be turned off.6

Assurance should be independent enough to challenge optimistic migration reports. Require evidence from configuration, traffic or protocol observation where appropriate, certificate and key records, test results, change records, and operational monitoring. Preserve uncertainty explicitly: a product roadmap is not the same as delivered capability, a draft standard is not the same as final implementation guidance, and an inventory record marked “unknown” is not proof that an asset is safe.643

Risks, limitations, and supplier dependencies

Legacy and embedded technology can dominate the schedule. Industrial IoT devices may be resource-constrained, unupgradeable, difficult to service, embedded in larger products, dependent on proprietary protocols, or not yet PQC-compatible. Internet-connected devices can also create an entry point into control networks and onward into enterprise IT through a DMZ. For these assets, the program may need compensating security upgrades, isolation, replacement planning, or a carefully bounded exception rather than an immediate algorithm change.643

Custom-built systems, especially older ones, may require substantial engineering. The joint fact sheet recommends identifying the risk to data or functions and then either migrating the technology or developing security upgrades that mitigate continued use. For COTS products and cloud-hosted products, the organization cannot assume that an installed version will become quantum-ready automatically; vendor and cloud-provider engagement must establish how and when updates, upgrades, configuration changes, or application modifications will be delivered.463

Standards and implementation maturity create another limitation. The CISA, NSA, and NIST fact sheet encourages preparation and testing while noting that final implementation specifics for draft PQC standards were incomplete in the cited guidance. NIST IR 8547 IPD is explicitly an initial public draft dated November 2024, so teams should preserve version awareness and revalidate plans against applicable final standards, product support, and sector guidance. Do not treat a draft’s example, a supplier promise, or a laboratory result as a production approval without the required review.463

Practical next steps for enterprise security teams

1. Appoint a cross-functional migration owner and project team, including IT, OT, procurement, application, PKI, infrastructure, security, risk, and business representatives.
2. Approve an inventory schema covering cryptographic use, algorithm and key details, certificates, keys, protocols, software, hardware, firmware, data or function, owner, supplier, criticality, exposure, security life, upgrade path, and evidence status.
3. Run discovery across representative networks, applications, servers, endpoints, PKI, cloud services, devices, code-signing systems, and supplier products; label unknowns as unresolved rather than safe.
4. Rank the inventory using impact, exposure, confidentiality duration, integrity needs, trust dependencies, upgrade difficulty, and supplier readiness.
5. Select pilot systems that provide meaningful interoperability and operational lessons without placing the highest-consequence production functions at unnecessary risk.
6. Define target transition patterns, including staged coexistence, certificate and trust migration, hybrid approaches where justified, compensating controls, rollback, and retirement criteria.
7. Require vendors and cloud providers to document roadmap, release, configuration, performance, certification or assurance implications, cost, and support boundaries.
8. Establish test and measurement gates, including confirmation that intended mechanisms are active and that fallback is controlled and visible.
9. Review the roadmap at each relevant standards, product, architecture, or threat change; keep dates, document versions, assumptions, exceptions, and evidence current.

Conclusion

Migration best practices combine governance, discovery, risk-based sequencing, crypto-agile architecture, supplier management, staged implementation, and evidence-based assurance. For PQC migration, the long lead time makes preparation practical even before every implementation detail is settled. An enterprise that knows where cryptography is used, why each use matters, how it can be changed, which suppliers control the path, and what evidence proves adoption can prioritize intelligently and reduce the chance that a future transition becomes an emergency.3456