Building a PQC Roadmap

1. What a PQC roadmap is—and is not

A PQC roadmap is an execution instrument. It converts findings about cryptographic use, data and system lifetimes, architecture constraints, suppliers, and organizational capacity into ordered work. It names accountable owners, dependencies, decision gates, target states, funding assumptions, and review points. It should be updated as standards, implementations, validation results, vendor products, and organizational priorities change. NIST describes the transition as a broader strategy involving adoption of new algorithms, careful deprecation and controlled legacy use, and eventual removal of quantum-vulnerable algorithms; public-private engagement is expected to be important.1

The roadmap is narrower than the broader migration strategy. The strategy establishes principles, risk appetite, policy, and the desired end state; the roadmap sequences the work needed to reach that state. A readiness assessment is a prerequisite: it supplies the evidence about where public-key cryptography is used, which services depend on it, how long information must remain protected, and what technical or supplier constraints exist. The roadmap should not pretend that every application can follow one universal deadline. NIST’s transition material explicitly notes that timelines can vary by use case and application.1

2. Start with evidence and define the risk model

Begin by collecting the inputs that make sequencing defensible. Use the readiness assessment as the baseline, then record the systems, applications, protocols, libraries, cryptographic modules, certificates, keys, devices, and suppliers that use quantum-vulnerable public-key mechanisms. Distinguish key establishment from digital signatures: FIPS 203 specifies ML-KEM for key establishment, while FIPS 204 and FIPS 205 specify ML-DSA and SLH-DSA for digital signatures. The standards address different functions and therefore lead to different migration tasks, testing, and operational dependencies.245

For each dependency, capture the protection objective and lifetime. Encryption can create a “harvest now, decrypt later” concern when information must remain confidential for a long period; signatures can remain relevant after creation when their validity, provenance, or trust chain must be relied upon. The evidence’s Mosca-model discussion frames the problem using the time information must remain secure and the time required to migrate, rather than relying solely on the time until a CRQC might exist.3

• System and service owner, business criticality, and recovery owner.
• Public-key algorithm, protocol, certificate or key-management dependency, and cryptographic module.
• Confidentiality, integrity, authentication, or origin-assurance requirement.
• Required protection or signature-validation lifetime.
• Data location, retention, replication, archival, and external-party dependencies.
• Current implementation status, performance constraints, hardware dependencies, and rollback options.
• Supplier, product, protocol, and validation status, including commitments and known gaps.

Prioritization should combine impact and feasibility. A high-priority item may protect long-lived sensitive data, authenticate critical software or devices, support a large trust infrastructure, or have a long replacement cycle. A technically easy item may be a good early pilot, but ease alone should not displace high-consequence exposures. Conversely, a critical system with hardware, certification, safety, or interoperability constraints may need early architecture work even if production migration is later. The roadmap should record these trade-offs and the decision owner.63

3. Convert findings into sequenced workstreams

A useful roadmap separates parallel workstreams instead of treating “replace the algorithm” as one task. The workstreams below can share a program owner while retaining accountable technical and business owners. Sequence them by dependency: an organization cannot safely roll out a new mechanism where it has no inventory, target architecture, supplier support, test evidence, or operational recovery plan.1

The governance workstream should define a single backlog format. Each item should have a named owner, accountable decision-maker, affected users or systems, dependencies, target state, planned wave, funding estimate, acceptance measures, residual risk, and exception expiry. Include legal, procurement, architecture, operations, incident response, and business continuity participants where their decisions can block deployment. NIST emphasizes coordination among agencies, technology providers, standards organizations, and validation laboratories; a roadmap that omits these parties will understate delivery risk.1

The architecture workstream should distinguish algorithm selection from integration design. FIPS 203 provides three ML-KEM parameter sets with different security-strength and performance trade-offs. The appropriate choice depends on the application and its security requirement, not on a universal “strongest is always best” rule. For KEM applications, NIST SP 800-227 also calls for an application-appropriate security strength and appropriate protection of devices and sensitive decapsulation data.46

The supplier workstream should obtain more than a marketing statement that a product is “quantum ready.” Request supported algorithms, protocol versions, migration interfaces, certificate and key-management behavior, hardware requirements, performance data, upgrade and replacement paths, validation status, support dates, and the supplier’s handling of vulnerabilities or algorithm changes. The roadmap should mark unverified claims as assumptions or risks until evidence is received.67

4. Use decision gates, target architectures, and hybrid policy

Decision gates prevent a program from moving from planning to production on optimism alone. A practical sequence is: approve scope and risk criteria; accept the inventory baseline; approve target architecture; approve supplier and implementation readiness; authorize a pilot; authorize each rollout wave; and close or extend the legacy exception. At every gate, record evidence, unresolved risks, the accountable decision, and conditions for reversal. The gates should be based on observable facts, not a predicted CRQC arrival date.3

1. Inventory gate: coverage, ownership, algorithm mapping, data and signature lifetimes, and confidence levels are documented.
2. Architecture gate: the selected NIST-standardized function, parameter choice, interfaces, key management, certificate behavior, and operational controls are approved.
3. Supplier gate: required product support, implementation evidence, validation path, and contractual commitments are recorded.
4. Pilot gate: representative workloads, interoperability partners, performance limits, failure modes, observability, and rollback are tested.
5. Wave gate: acceptance measures pass, operational teams are trained, dependencies are ready, and residual risk is accepted by the right owner.
6. Retirement gate: legacy use is removed or formally time-bounded, with evidence that dependent clients and recovery procedures have been addressed.

A target architecture should make cryptographic replacement a bounded change rather than a redesign of every application. Isolate algorithm choices behind stable interfaces where practical, centralize policy and inventory data, separate key-establishment and signature use cases, and define how certificates, trust stores, signing services, devices, and archives are updated. Crypto agility is relevant because the capability to replace and adapt algorithms in protocols, applications, software, hardware, and firmware reduces the cost and disruption of later changes.7

Do not treat hybrid as automatically safer or as a final architecture. Document the exact composition, negotiation behavior, failure handling, key-management model, downgrade protections, certificate implications, interoperability population, and exit criteria. Where a hybrid or dual-signature approach is selected, the application owner should explicitly accept implementation cost, performance reduction, engineering complexity, and the need for independent security review.81

5. Design pilots that produce rollout evidence

Choose pilots for representativeness, not only convenience. A pilot should exercise at least one high-value dependency, one difficult interoperability boundary, and one operationally realistic recovery scenario. Test normal operation, invalid inputs, key and certificate rotation, service restart, backup and restore, client incompatibility, degraded performance, monitoring, incident response, and rollback. Record the exact implementation, parameter set, protocol behavior, build, configuration, and test environment so that results are reproducible.6

Validation is necessary but limited. NIST SP 800-227 states that validation testing commonly checks input-output behavior on a small number of often randomly sampled inputs; it does not guarantee correct functioning on all inputs. The same evidence emphasizes that implementations must correctly implement the mathematical functionality of the target KEM, while implementation quality has a major effect on real-world usability and security. Treat laboratory or conformance evidence as one control in a larger assurance case, not as proof that the whole application is secure.6

Pilot acceptance measures should include functional correctness, interoperability, latency and throughput against agreed limits, memory and bandwidth impact, key and certificate lifecycle behavior, observability, supportability, and security review findings. For signatures, test verification and validation workflows, identity and private-key possession assurances, trust-chain changes, and the effect of larger signatures or keys where applicable. For KEMs, test encapsulation and decapsulation failures, protection of decapsulation keys, parameter selection, and secure destruction or handling of cryptographic data.6

Define rollback before deployment. Rollback may mean restoring a prior software version, reverting a protocol preference, disabling a feature flag, switching to an approved transitional mode, replacing a certificate chain, or isolating a service. It must not silently reintroduce an unapproved quantum-vulnerable mechanism. Set a rollback trigger, maximum exposure period, owner, communications path, data-handling rule, and follow-up decision. If rollback is impossible because of one-way key or device changes, the wave needs a stronger approval gate and a tested containment plan.1

6. Plan near-, medium-, and longer-term outcomes without universal deadlines

Use outcome horizons rather than arbitrary calendar promises. “Near term” means establishing decision quality and reducing uncertainty: an owned inventory, ranked backlog, approved governance, target-architecture principles, supplier evidence requests, and pilots selected. “Medium term” means converting validated designs into repeatable delivery: supported products, operational procedures, trained teams, completed priority waves, measurable performance baselines, and time-bounded exceptions. “Longer term” means completing dependent replacements, removing quantum-vulnerable use where authorized, improving agility, and sustaining review as standards and threats evolve. The exact dates should come from each organization’s risk, procurement, engineering, and system-lifecycle constraints.1

A rollout wave should group systems with a manageable dependency boundary, not merely systems owned by one department. Establish entry criteria, change windows, communications, support coverage, telemetry, and a wave owner. Start with a pilot-informed population, then expand only after measuring results. Prioritize systems whose data or trust relationships create the greatest exposure, while using lower-risk systems to validate reusable patterns. Hardware-bound environments may require earlier procurement and design activity because replacement of processors, secure elements, smart cards, readers, or cryptographic coprocessors can lengthen migration.3

Fund the roadmap as a portfolio. Separate discovery, architecture, supplier remediation, application change, hardware replacement, testing, certification or validation support, operations, and decommissioning costs. Show the consequence of deferring each item, the assumption behind the estimate, and the funding owner. Review capacity as well as money: cryptography expertise, application engineering, test environments, procurement, service windows, and vendor support can all become critical-path dependencies.71

Set a recurring review cadence appropriate to the organization’s change rate, with an expedited review when a defined trigger occurs. Triggers can include a standards change, a material cryptanalytic or implementation finding, a supplier withdrawal, failed validation, a new interoperability constraint, an unacceptable pilot result, or a change in the required confidentiality or signature lifetime. Preserve versioned decisions and evidence so that the program can explain why a system was prioritized, deferred, placed in hybrid mode, or granted an exception.71

7. Measure progress and residual risk

Metrics should show both delivery and risk reduction. Avoid reporting only the number of systems migrated, because a large low-risk count can obscure a small number of critical unresolved dependencies. Use a balanced dashboard with inventory coverage, ownership coverage, priority exposure, architecture decisions, supplier commitments, validated implementations, pilot pass rates, rollout completion, exception age, rollback readiness, and legacy cryptographic use. Each metric needs a definition, data owner, reporting period, and target or trigger.71

• Inventory coverage: the proportion of in-scope systems and cryptographic dependencies mapped with an identified owner.
• Risk coverage: the proportion of high-priority confidentiality and signature-lifetime exposures with an approved treatment.
• Architecture readiness: the proportion of priority services with approved target designs and documented dependencies.
• Implementation assurance: the proportion with specified validation, security-review, and operational-test evidence.
• Supplier readiness: the proportion with confirmed support, upgrade paths, and unresolved contractual or product risks tracked.
• Wave quality: pilot and rollout pass rates, incidents, rollback events, performance variance, and open defects.
• Legacy reduction: quantum-vulnerable uses removed, constrained, or placed under an approved exception with an expiry or review condition.
• Agility: time and effort required to change a test algorithm or protocol configuration in a controlled environment.

Interpret metrics in context. A decrease in legacy use is not sufficient if the remaining uses protect the most valuable data or trust anchors. A high pilot pass rate is not sufficient if pilots omit difficult clients, hardware, or recovery operations. A validated module is not sufficient if the application misuses the KEM, fails to protect decapsulation keys, or cannot rotate credentials. The review forum should therefore examine evidence, exceptions, dependencies, and residual risk together.6

Conclusion

A strong PQC roadmap is a living, evidence-based delivery plan. It starts with an owned inventory and lifetime-aware risk ranking, separates key establishment from signatures, selects target architectures and supplier commitments, and uses gates to control pilots and rollout waves. It treats validation as important but not conclusive, makes rollback and legacy exceptions explicit, and measures remaining exposure as well as completed work. By using standards status, implementation evidence, lifecycle constraints, and defined risk triggers instead of a guessed CRQC date, organizations can begin practical migration while retaining the flexibility to respond to new information. claim-011237