A post-quantum cryptography migration begins with knowing where your systems use public-key cryptography and how those dependencies can change. The practical work includes software updates, protocol compatibility, certificates, supplier support and a rollout that preserves the service.
Start with an inventory and a clear owner. Then prioritize the uses that matter most and test a contained change. This roadmap explains how to turn a broad security concern into application and infrastructure work that a team can assess.
Understand the standards and their different jobs
NIST published its first three principal post-quantum standards in August 2024. Its PQC project overview identifies ML-KEM for key establishment and ML-DSA and SLH-DSA for digital signatures. These mechanisms serve different purposes; choosing one does not replace every cryptographic function in an application.
The migration addresses the future threat to vulnerable public-key algorithms from sufficiently capable quantum computers. That threat does not provide a reliable date for an individual organization’s cutover. Use the current standards, relevant transition guidance and your system’s risk to plan the work.
Also distinguish an algorithm standard from a supported product integration. Your protocol, library, hardware and counterparties must work together. A product advertising PQC support still needs to match the use case you intend to migrate.
Plan your post-quantum cryptography migration inventory
Identify where cryptography protects communication, identity, software updates and stored information. Include services you operate and important supplier-managed dependencies. Then record enough detail to locate the owner and the change path.
- The system, service and operational owner.
- The cryptographic purpose, protocol and algorithm where known.
- The library, appliance or supplier that implements it.
- The counterparties that must remain compatible.
- The data’s protection lifetime and the system’s replacement constraints.
Keep private keys and credentials out of this inventory. Store references to their approved management systems instead. Also mark unknowns explicitly so a blank field cannot be mistaken for an absence of cryptography.
The NCCoE migration project separates cryptographic discovery from interoperability testing. Its discovery work supports understanding where cryptography is used and prioritizing migration. Use that distinction to organize the work before choosing a replacement configuration.
Prioritize protection lifetime and migration difficulty
Consider how long information must remain confidential and how long the system will stay in service. Also assess how difficult it is to update the cryptographic dependency. Long-lived devices and external integrations can need more coordination than two services your team controls.
For example, a hypothetical organization might have a public website, a partner API and signed device updates. Each has a different owner, compatibility boundary and release process. Do not put them into one undifferentiated “enable PQC” task.
Next, identify supplier dependencies and applicable transition requirements. Ask which product release, protocol profile and validation evidence support your intended use. Record the answer and its date so the roadmap does not rely on an informal promise.
Build crypto agility into the change path
Crypto agility is the ability to replace or adapt cryptographic mechanisms while preserving security and operations. NIST’s updated crypto-agility white paper discusses the operational mechanisms and tradeoffs involved. Treat agility as a maintained capability rather than a one-time toggle.
Locate cryptographic choices in supported libraries and configuration with clear ownership. Also version the configuration and document how to inspect what a running service actually negotiated or used. This makes future changes easier to verify.
Use maintained implementations and supported protocol integrations. If a supplier offers a hybrid mechanism, establish exactly what it combines and which peers support it. Avoid inventing a combination of algorithms in application code.
Finally, separate the ability to roll back a release from permission to reintroduce an unacceptable security state. Define the recovery options with the responsible security and operations owners before rollout.
Test a post-quantum cryptography migration in context
Choose a pilot with controlled peers and a clear rollback or recovery route. For example, a staging API between two services you operate can make the compatibility boundary easier to inspect. The pilot should use the actual library and protocol versions proposed for deployment.
Test successful negotiation, authentication and the application’s normal work. Then exercise unsupported peers and failure paths. A successful connection alone does not establish certificate validation, authorization or correct application behavior.
- Confirm the mechanism actually selected by the peers.
- Verify that identity and certificate checks still enforce the intended trust.
- Measure handshake size, latency and resource use on representative paths.
- Test gateways, proxies and other middleboxes in that path.
- Check unsupported-peer behavior and any permitted fallback explicitly.
Also test the operational tools. Monitoring, certificate renewal, backups and incident procedures must remain usable. A cryptographic change that works only in a laboratory leaves the migration incomplete.
Roll out by dependency and observe the result
Create a staged release plan with the affected systems, owners, prerequisites and acceptance evidence. Begin with the controlled pilot, then expand to the next compatible group. Keep the release record tied to exact product and configuration versions.
Watch connection failures, negotiation outcomes, application errors and resource use. Also retain a way to distinguish an expected rejection from a new compatibility defect. That distinction helps the team respond without silently weakening the intended policy.
Update the inventory after each accepted change. Record what is migrated, what still depends on a supplier and what remains uncertain. Finally, schedule review of guidance and product support so the plan stays current.
Make post-quantum cryptography migration repeatable
The useful first result is an inventory-backed plan and a pilot whose behavior you can explain. Keep discovery, prioritization, compatibility and operational acceptance connected. Then expand from verified evidence rather than a blanket product label.
For application dependency updates and integration work, explore Yasa’s development support. A specific service and its dependencies provide a practical starting point.
Map the application changes ahead
Tell Yasa which application needs updating, which systems it connects to and what compatibility must remain intact. We can discuss the implementation scope and a focused next step.
