PQC Readiness Stage 3: How PQC Risk Prioritization Helps You Decide What to Migrate First

You found your cryptography. Now what? PQC risk prioritization turns your inventory of certificates, keys, and algorithms into a clear answer: where should post-quantum migration start?

Most teams reach this point with more findings than they have capacity for. You can’t migrate everything at once, and you shouldn’t try. Stage 3 of the five stages of PQC readiness is where insight becomes priorities.

If you’ve completed cryptographic discovery and planning, you already have the raw material. This post shows how to rank it, build a roadmap from the ranking, and test the plan before you scale. You can also follow along in the PQC Lab.

Where Stage 3 fits on the road to quantum resilience

Quantum readiness isn’t a single technology upgrade, but it can be viewed as a journey with five stages, the third of which sits right in the middle. The five stages are awareness and alignment, discovery and planning, risk prioritization, agility and automation, and resilience. Stage 2 connects what you discover to business risk. Stage 3 ranks systems and dependencies by that risk, and Stage 4 puts the plan in motion.

Why can’t you migrate everything at once?

Because migration is an enormous project, and your people, budget, and overall resources are finite. A ranked, risk-based sequence lets you spend that capacity where it matters most. It also gives you a plan you can defend to leadership.

The deadlines are getting specific. For example, NIST’s draft IR 8547 proposes deprecating quantum-vulnerable algorithms at 112-bit security strength, such as RSA-2048, after 2030. It would disallow all quantum-vulnerable public-key algorithms after 2035. The document is still an initial public draft, but it signals where federal guidance is heading.

National Security Systems face a firmer schedule. The NSA’s CNSA 2.0 timeline calls for exclusive use of quantum-resistant algorithms in software and firmware signing and networking equipment by 2030. Web browsers, servers, and cloud services follow by 2033. NSA’s goal is for all National Security Systems to be quantum-resistant by 2035.

Those dates sound distant until you count replacement cycles. As Encryption Consulting notes, PKI, HSM, and embedded system replacements routinely take years. Prioritization is the key, and starting with the right systems is how you stay ahead of the calendar.

Six factors that decide what migrates first

Rank each system by six factors: data sensitivity and shelf life, business criticality, external exposure, regulatory obligations, dependencies, and migration complexity. Together they weigh business risk and cryptographic risk side by side.

Data sensitivity and shelf life

Start with the data that will still matter by the time when quantum computers can break today’s encryption. In a harvest now, decrypt later attack, adversaries steal encrypted data today and store it until they can decrypt it. Once adversaries get access to the encrypted data, this cannot be recovered, and there is nothing that can be done to prevent the attack. That data can include customer information, financial details, confidential corporate information, intellectual property, health records, etc.

Not all data carries the same risk. For much of it, the sensitivity will expire before anyone could decrypt it. Trade secrets, business intelligence, emerging technology research and classified material carry the most risk. That’s especially true in industries with long research and production cycles, such as pharmaceuticals and self-driving cars. It is also true for companies that handle classified data, such as government contractors and institutions. The question to ask is simple: what data will still be sensitive in five years?

For signatures and devices, you can apply a similar thinking. Long-lived digital signatures, signing keys, and roots of trust are important. Moreover, hardware built today, such as telecom equipment, may stay in service for 20 to 30 years. Therefore, the question is not much on the data, but rather, on the infrastructure: will I be able to migrate the entire signing and public-key infrastructure within the next five years?

Business criticality

Ask what happens to revenue, operations, or customers if this system fails or loses trust. Systems that keep the business running move up the list. A failed migration on a critical system costs more, so plan those with extra care.

External exposure

Systems that face the internet, partners, or customers give attackers the easiest path to harvest traffic. Exposure also covers identity: a forged VPN certificate could grant access to back-end systems. Rank externally reachable systems above those that sit deep inside your network.

Regulatory obligations

Some systems carry deadlines you don’t set. NIST IR 8547 (still in draft) and CNSA 2.0 define the timelines above. In 2026, OMB memo M-26-15 directed US federal agencies to identify systems that can’t support PQC or hybrid cryptography and prioritize them for replacement.

Dependencies

Many migrations depend on vendors, hardware, software, and services outside your control. Mapping those dependencies shows where migration timing may not be yours to decide. Validate readiness, gaps, and lead times for critical dependencies, then reflect them in your plan.

Migration complexity

Some systems swap algorithms with a configuration change. Others need new hardware, firmware updates, or coordinated releases across teams. Complexity rarely changes how risky a system is, but it shapes when and how you can move it.

How to rank systems: a simple approach

A lightweight scoring model works for most teams. Rate each system low, medium, or high against each factor, then combine the scores into migration waves. The goal is a defensible sequence for action that you can explain to leadership.

Here’s one practical method:

1. Score each factor as one (low), two (medium), or three (high).
2. Count data sensitivity and external exposure twice, since they drive harvest now, decrypt later risk.
3. Add business criticality and regulatory obligations at normal weight to get a risk score.
4. Use dependencies and migration complexity to adjust timing.
5. Assign each system to Wave 1, Wave 2, or Later.

High-risk systems with manageable complexity go into Wave 1. High-risk systems blocked by a vendor or hardware cycle still rank high. Start the dependency work now and schedule the migration for Wave 2. Each vertical can be assigned different weight depending on your environment.

Example: applying the ranking method

The table below uses a hypothetical collection of systems to show how the method works. Your own ratings will depend on your environment.

System	Data sensitivity and shelf life	External exposure	Business criticality	Regulatory obligations	Dependencies and complexity	Wave
Customer-facing TLS gateway	Élevé	Élevé	Élevé	Élevé	Faible	Wave 1
Code signing for device firmware	Élevé	Moyen	Élevé	Élevé	Moyen	Wave 1
Partner VPN	Moyen	Élevé	Moyen	Moyen	High (vendor roadmap)	Wave 2
Long-term data archive	Élevé	Faible	Moyen	Élevé	Moyen	Wave 2
Internal HR app	Moyen	Faible	Faible	Moyen	Faible	Later

Notice the partner VPN. Its exposure is high, but a vendor dependency sets its timeline. The dependency work starts in Wave 1, and the migration lands in Wave 2.

Want to practice before you score your own environment? The PQC Lab offers short, guided walkthroughs that show how to surface and assess cryptographic vulnerabilities.

What PQC risk prioritization maturity looks like

Maturity runs from no defined criteria to priorities that adapt as conditions change. Here’s how the five levels compare:

1. Not yet defined: You haven’t decided how priorities will be set. A shared set of risk criteria creates a starting point.
2. Defining criteria: You’re building criteria, including data longevity and harvest now, decrypt later exposure, and naming systems that need early attention.
3. Ranked priorities: You’ve ranked priority systems by data sensitivity and longevity, business criticality, exposure, regulatory obligations, and migration complexity.
4. Phased roadmap: A roadmap based on the ranking assigns owners and target dates, and you track delivery.
5. Continuous review: You review priorities on a defined cadence as business needs, threats, standards, regulations, and dependencies change.

Not sure which level describes you? See where your organization lands.

Turn priorities into a managed plan

A ranking only helps once it drives work. Each wave must have an owner, a target date, and tracked delivery for every priority system. Set a review cadence, where owners report progress, exceptions and roadblocks on a defined schedule. This will help you see slippage early and address accordingly.

Governance is what makes this progress sustainable and consistent. Use it to track progress and manage exceptions when a system can’t move on schedule. It also helps you catch regression, such as a quantum-vulnerable algorithm returning to a migrated system.

Test the assumptions behind your plan

Your ranking rests on assumptions, so test them before you scale. Pick a focused use case from Wave 1 and run it in a controlled environment.

Look at four things: interoperability, performance, operational impact, and fallback behavior. Controlled testing shows where those constraints may change your plan. A system you ranked first might need to wait, while another proves easier than expected.

You’ll know you’ve completed Stage 3 when you’ve tested priority use cases and defined the first migration wave. From there, you’re putting the plan into motion. To start hands-on, test drive quantum resilient certificates, code signing, and lifecycle management in your own sandbox, with no complex setup.

How Keyfactor can help with PQC prioritization

Keyfactor PQC experts can help you connect your assessment result to your environment. They can answer questions about discovery, prioritization, testing, and migration, so your ranking reflects how your systems actually work.

The PQC Lab adds short, guided walkthroughs and a sandbox you can spin up in minutes. When you’re ready, explore PQC Lab.

For deeper reading on Stage 3, start with these resources:

• Guide du responsable de la sécurité des systèmes d'information sur les risques cryptographiques
• Au-delà du CBOM : renforcer la sécurité cryptographique
• Comprendre la gestion de la posture cryptographique et la visibilité des actifs

Turn insight into priorities

Stage 3 is where your inventory starts working for you. Rank systems by the six factors, build a phased roadmap with owners and dates, and test your assumptions before you scale.

Ready to check your progress? Start the assessment or talk with a PQC expert about your environment. Next, follow the full road to quantum resilience, including our Stage 4 deep dive on agility and automation.