Migration Pitfalls

What are migration pitfalls?

A migration pitfall is a planning, design, implementation, or operating failure that prevents an organization from moving cryptographic protection to post-quantum cryptography (PQC) while preserving required security and service continuity. The scope is broader than selecting a new algorithm. It includes network protocols, software cryptographic libraries, cryptographic hardware, PKI and other infrastructure components, applications, services, digital signatures, key establishment, authentication, encryption, and the associated key-management lifecycle. NIST’s November 2024 document is an initial public draft, so its migration considerations and status should be read with that limitation in mind. The later NIST CSWP 39 Update 1 is identified in the cited evidence as a final publication and describes crypto agility as the ability to replace and adapt algorithms across protocols, applications, software, hardware, firmware, and infrastructure while preserving security and ongoing operations.12

The practical scope also includes decisions about data and system lifetime. NIST guidance notes that cryptographic protection must be considered in relation to the security life of the data, algorithm limitations, transaction volume, operating environment, security function, rekeying process, and the number of nodes sharing keying material. A migration plan that treats all systems as equivalent can therefore mis-prioritize work and overlook the consequences of long-lived data or high-volume services.3

Why migration pitfalls matter

PQC migration is urgent even though the cited NIST initial public draft states that no existing cryptographically relevant quantum computers currently threaten the cited security levels. The same passage says that transition to new algorithms takes significant time, that past cryptographic migrations have taken over a decade, and that this more complex migration will likely take at least that long. The risk is therefore not limited to the date on which a future quantum computer becomes available: organizations must account for the time needed to discover dependencies, modify systems, obtain supplier updates, test, deploy, and retire vulnerable mechanisms.2

Long-term confidentiality creates a related exposure. NIST’s transition guidance uses the example of data that must remain secure for 15 years and explains that a security strength suitable for a shorter period may not be sufficient when the protection period extends beyond the relevant transition horizon. The cited evidence also identifies the “harvest now, decrypt later” concern and says that migration to quantum-resistant key-establishment schemes is expected to receive particular attention, especially in interactive protocols such as TLS and IKE. Organizations should consequently assess both the value and required confidentiality period of data, not only the current sensitivity of a connection.42

The business impact is broader than confidentiality. In industrial control systems and industrial IoT, data confidentiality may not always require the strongest protection, while data integrity can be critical because faulty sensor readings or commands can contribute to control-system failures. Internet-connected devices can also provide an entry point into control networks and then into enterprise IT zones through a DMZ. A migration that protects selected enterprise applications but neglects field devices, remote logins, firmware signing, or OT boundaries can therefore leave important integrity and access risks unresolved.5

The most common migration pitfalls

1. Starting implementation before discovery. An organization cannot prioritize effectively if it does not know where cryptography is used. The joint CISA, NSA, and NIST fact sheet recommends a cryptographic inventory that provides visibility into IT and OT use of cryptography and identifies quantum-vulnerable algorithms in network protocols, end-user systems and servers, applications, and associated libraries. The inventory should also support correlation with data criticality, outside access, and information that could be targeted now and decrypted later. Omitting embedded libraries, software and firmware update mechanisms, certificates, or supplier-managed components creates a false sense of coverage.6

2. Treating the migration as an algorithm swap. Applications may need changes for encryption, digital signatures, and key exchange. The cited NIST evidence specifically warns that organizations may need to update underlying cryptographic implementations, adjust to changed key sizes and algorithm performance, ensure compatibility with updated protocols and libraries, refactor code, conduct extensive testing, and potentially redesign user interfaces. New algorithm footprints, key sizes, block sizes, certificate structures, message formats, and processing demands can affect system behavior outside the cryptographic library itself.23

3. Ignoring interoperability and transition modes. Backward compatibility and interoperability during transition are described as crucial to maintaining trust and security across a network. Enterprise PKI migration may require a new PQC root of trust and new certificates for network entities; some devices may require physical interaction. A parallel PKI can allow staged migration, while a controlled environment might permit a one-step move. The choice depends on the environment and must account for protocols such as TLS and IKE that negotiate which certificates are used. Hybrid key establishment or dual signatures may be possible, but the cited NIST draft says each application must weigh implementation cost, performance reduction, engineering complexity, and the need for proper and independent security reviews.52

4. Assuming traditional cryptography will disappear automatically. A transition can fail if systems retain legacy support indefinitely or silently negotiate a traditional mechanism. The cited NCSC evidence recommends additional tests to establish that cryptography is performing as expected; for standardized PQC cipher suites in TLS, this includes checking that systems actually use them rather than falling back to traditional cryptography. Fallback may preserve availability while undermining the security objective, so it must be a deliberate, governed behavior rather than an unnoticed compatibility path.5

5. Underestimating legacy, embedded, and OT constraints. Industrial IoT and OT devices may be resource-constrained, non-upgradeable, difficult to service, embedded in larger products, unsuitable for replacement, dependent on proprietary protocols, or based on protocols that are not yet PQC-compatible. Physical infrastructure changes require significant planning and should, where possible, coincide with maintenance and improvement windows. Remote Internet logins into ICS IT zones and wireless field devices also require attention. Where direct migration is not immediately possible, the organization must identify the risk to the affected data or functions and determine whether a migration or a security upgrade is needed.5

6. Leaving suppliers and cloud providers out of the plan. Custom-built older systems are likely to require substantial effort to become quantum-resistant. For commercial off-the-shelf products, the joint fact sheet says vendor engagement on a PQC roadmap is critical. The roadmap should identify when and how each supplier plans to deliver updates or upgrades and the expected migration cost. For cloud-hosted products, organizations should ask providers about their quantum-readiness roadmap and later clarify how PQC will be enabled through configuration changes or application updates. A procurement process that records only present-day algorithm support is not enough for a transition that spans product lifetimes.6

7. Treating key management as an afterthought. Algorithm replacement changes the material that keys, certificates, metadata, and applications must handle. NIST describes metadata as crucial to applications and application protocols because it helps applications select the appropriate key for a service, even though metadata is not itself part of the cryptographic algorithm. The key-management lifecycle includes preoperational and operational phases, among others, and migration planning must preserve appropriate controls as keys move through their states. Existing recommendations also say that longer or shorter cryptoperiods may be warranted depending on the application and environment; a cryptoperiod should therefore be reassessed rather than copied uncritically into a new design.3

8. Deploying without evaluation, testing, or training. NIST key-management guidance identifies preimplementation evaluation, testing before deployment, training for new or changed tasks, and careful system implementation and transition as migration considerations. Strong cryptography can still be poorly implemented. Teams should test functional behavior, performance, certificate and key handling, failure modes, interoperability, recovery, and security controls in the target environment. They should also train the personnel responsible for new key-management procedures; otherwise improvements may be experienced as avoidable operational friction and used incorrectly.1

9. Measuring activity instead of outcome. Counting upgraded products does not demonstrate that a migration objective has been achieved. The cited NCSC evidence recommends metrics such as the number of software clients using PQC and the ability to identify those that are not. Such measures help determine progress, remedial action, and when support for traditional algorithms can be turned off. Measurements should be tied to the inventory, criticality, approved transition states, exceptions, and evidence from testing rather than to deployment volume alone.1

A practical workflow for avoiding the pitfalls

A defensible workflow begins with governance. Establish a project-management team with IT, OT, procurement, security architecture, application ownership, infrastructure, key management, risk, and supplier-management representation. The joint CISA, NSA, and NIST evidence recommends establishing a quantum-readiness roadmap and beginning proactive discovery while standards and implementation details are still developing. The roadmap should state scope, decision rights, dependencies, priorities, supplier assumptions, transition states, testing requirements, exceptions, and the evidence needed to close each work item.2

1. Discover and inventory cryptographic use across IT, OT, network protocols, applications, libraries, hardware, firmware, PKI, certificates, software-update paths, cloud services, and supplier products.
2. Classify assets by business impact, data security life, confidentiality and integrity requirements, exposure, replaceability, and dependence on remote access or shared infrastructure.
3. Map dependencies and identify where key sizes, signatures, certificates, protocol messages, performance, storage, interfaces, or cryptoperiods may change.
4. Obtain supplier and cloud-provider roadmaps, record update and upgrade assumptions, and identify custom-built or embedded components that require engineering or compensating treatment.
5. Define a staged target architecture, including interoperability and any parallel or hybrid transition mode that is justified by the application’s cost, performance, complexity, and assurance needs.
6. Test in representative environments, verify negotiated algorithms and fallback behavior, train operators, and use independent security review where the risk or complexity warrants it.
7. Deploy in controlled increments, monitor the agreed measures, remediate exceptions, and retire traditional support only when the organization can demonstrate that dependencies and residual risks are understood.

Prioritization should be risk-based. The joint fact sheet specifically calls for priority to high-impact systems, ICSs, and systems with long-term confidentiality or secrecy needs. NIST’s initial public draft says application areas can have different risks, security needs, and adoption challenges, so a single enterprise-wide cutover date or identical control set may be inappropriate. The roadmap should instead define why each population is sequenced, what temporary exposure is accepted, and what condition permits progression or retirement of legacy mechanisms.4

Crypto agility is the architectural response to repeated migration difficulty: capabilities should allow cryptographic algorithms to be replaced and adapted across protocols, applications, software, hardware, firmware, and infrastructure while preserving security and ongoing operations. In practice, this means making algorithm and parameter choices governable, keeping dependencies visible, avoiding unnecessary hard-coding, and designing transition controls that can be tested and changed without redesigning every application. The cited CSWP 39 Update 1 is final according to the source record; its evidence describes an in-depth survey of approaches, challenges, tradeoffs, operational mechanisms, and areas requiring further consideration. It should therefore inform design decisions, while implementation remains context-dependent.21

How to use the cited evidence and standards

The evidence set contains complementary guidance rather than one universal migration prescription. NIST SP 800-131A Rev. 2 provides transition guidance for cryptographic algorithms and key lengths and defines approval terms such as acceptable, deprecated, and disallowed. It also explains that approval status can depend on key length, domain parameters, and the mode or manner of use. NIST SP 800-57 Part 1 Rev. 5 supplies general key-management guidance, including lifecycle, metadata, cryptoperiod, and implementation considerations. NIST IR 8547 IPD addresses the transition to PQC standards but is explicitly an initial public draft dated November 2024, so organizations should preserve that status when using it in governance records.3

The joint CISA, NSA, and NIST fact sheet provides practical readiness direction: create an inventory, establish a roadmap, prioritize high-impact and long-lived data, engage vendors, and treat migration as IT/OT modernization. The NCSC material adds operational and sector-specific considerations, including testing for fallback, measuring client adoption, PKI coexistence, and difficult industrial IoT constraints. These sources support a layered approach: use formal algorithm and key-management guidance for control decisions, readiness guidance for program organization and prioritization, and environment-specific testing for implementation assurance.65

Implementation considerations for enterprise teams

Application teams should identify every use of cryptography rather than limiting the review to transport encryption. The cited NIST evidence includes encryption, digital signatures, and key exchange, while the broader inventory evidence includes signatures used for software and firmware updates. Review certificate parsing and validation, identity binding, message-size assumptions, storage, memory, CPU use, latency, logging, backup and recovery, and interfaces between application components. The purpose is not to assume that every PQC mechanism has the same operational effect, but to expose the places where a cryptographic change can alter system behavior.23

PKI teams should plan root-of-trust creation, certificate issuance, renewal, revocation, validation, enrollment, device reachability, and the handling of entities that require physical intervention. Network teams should identify protocol versions, cipher-suite negotiation, IKE or TLS dependencies, and any compatibility paths. Key-management teams should map key states and metadata, review cryptoperiods and rekeying, and ensure that new key material can be selected by applications and protocols. OT teams should separately assess integrity, remote access, wireless field devices, DMZ boundaries, safety constraints, maintenance windows, and recovery procedures.53

Procurement and architecture teams should record whether a component is custom-built, commercial off-the-shelf, cloud-hosted, embedded, or supplier-controlled. For each dependency, capture the vendor’s stated roadmap, expected update or upgrade mechanism, configuration changes, estimated cost, testing responsibility, and support period. Where a vendor has not cited enough information, that is a tracked migration risk, not evidence that the product is ready. The cited joint fact sheet notes that final implementation specifics for the algorithms were incomplete in the context of its recommendation that vendors prepare to support PQC after NIST finalizes standards.6

Assurance should be continuous. Test that the intended algorithm is negotiated and used, that legacy fallback is controlled, that signatures and certificates validate correctly, that service-level behavior remains acceptable, and that operators can recover from failed or partial transitions. Record test scope, environment, results, defects, exceptions, compensating measures, and approval. Repeat testing after material changes to libraries, firmware, certificates, protocols, cloud configurations, or supplier products.5

Risks, limitations, and next steps

No migration plan can remove all uncertainty. The cited evidence includes an initial public draft, standards and guidance with different publication statuses, evolving technical standards, supplier dependencies, and devices that may not be upgradeable. The existence of algorithm standards is an important building block, but the NCSC evidence says that guidance on specific patterns and configurations will continue to evolve. Teams should preserve document versions and dates in decisions, revisit assumptions as standards and products mature, and avoid claiming that an inventory or pilot proves enterprise-wide readiness.2

• Name an accountable migration owner and establish a cross-functional IT/OT and procurement team.
• Create the first cryptographic inventory and link each discovered use to asset owner, data or function criticality, exposure, and supplier.
• Identify long-term confidentiality, high-impact, ICS, remote-access, firmware-signing, and difficult-to-replace populations for early assessment.
• Request PQC roadmaps and implementation details from critical vendors and cloud providers; record unanswered questions as risks.
• Select representative pilots that exercise PKI, key establishment, signatures, application libraries, legacy interoperability, and fallback behavior.
• Define measurable exit criteria, including the ability to identify non-adopting clients and the conditions for retiring traditional support.
• Review the roadmap against current source versions and update it when standards, vendor implementations, or operational constraints change.

Conclusion

Migration pitfalls arise when PQC transition is treated as a narrow cryptographic replacement instead of a long-lived, risk-based change to applications, protocols, infrastructure, key management, suppliers, IT, and OT. The most reliable starting point is a maintained inventory tied to business impact and data lifetime. From there, organizations can sequence high-risk work, plan PKI and interoperability, engage suppliers, test actual negotiated behavior, train operators, measure adoption, and design for crypto agility. Because the cited evidence includes evolving standards and an initial public draft, plans should retain uncertainty and be revised as implementation guidance and product support mature.126