PQC for Government

Why government programs should start now

PQC migration is urgent even though the timing of a cryptographically relevant quantum computer is uncertain. The cited NIST initial public draft describes a “harvest now, decrypt later” threat: adversaries may obtain encrypted information today and attempt decryption once quantum computing becomes operational. That matters particularly to government because some secrets and records have long-term sensitivity. A program therefore has to align the protection period of information with the time needed to change the systems that protect it, rather than waiting for a future quantum-computing milestone.1

The program should not be framed as a narrow cryptography project. The UK National Cyber Security Centre describes migration as a mass technology change that can take years, span IT and OT, and affect investment and broader cyber-security planning. For large organizations, critical national infrastructure, industrial control systems, and bespoke IT, the work can involve multiple leadership cycles and significant preparation as well as implementation costs. Government sponsors should consequently establish durable governance, funding, decision rights, and reporting before individual migrations begin.2

Build the program and roadmap

Begin by appointing a quantum-readiness project team with authority to coordinate architecture, cyber security, privacy, procurement, IT, OT, legal or policy stakeholders as appropriate, and system owners. The CISA, NSA, and NIST fact sheet recommends a project-management team to plan and scope migration and says that IT and OT procurement experts should lead the inventory work with supply-chain vendors. Cybersecurity and privacy risk managers should help identify assets whose compromise would create greater risk.3

1. Define the program’s scope: agency systems, shared services, communications, software distribution, embedded devices, operational environments, cloud-hosted products, and externally cited services.
2. Set migration goals and decision criteria. Include data sensitivity and longevity, signature and authentication dependencies, system criticality, hardware replacement constraints, supplier readiness, and continuity requirements.
3. Create a dependency-aware roadmap. Record the target state, accountable owner, required supplier action, planned procurement, test gates, deployment wave, legacy-cryptography exception, and retirement condition for every priority service.
4. Establish a review cadence that can absorb evolving standards, implementation guidance, product validation status, and lessons from pilot deployments without losing traceability or control.

Roadmap dates should be treated as planning controls rather than a promise that every system can change at the same speed. The NIST initial public draft discusses a goal of widespread adoption by 2035 while explicitly noting that timelines vary by use case, long-term confidentiality needs, infrastructure complexity, legacy constraints, and risk profile. The NCSC guidance gives an indicative milestone of 2028 for defining migration goals, completing a full discovery exercise, and building an initial plan. These dates come from documents with different scopes and statuses: the NIST material is an initial public draft, while the NCSC guidance is current. Agencies should preserve those distinctions in governance records.12

Create an inventory that can drive decisions

An inventory is the foundation of a government migration because organizations may not know the breadth of public-key cryptography embedded in deployed products, applications, and services. It should reveal where cryptography is used, which data or functions depend on it, who supplies the component, and what must change. The CISA, NSA, and NIST fact sheet identifies network protocols, end-user systems and servers, applications and associated libraries, and systems involved in creating or validating digital signatures as relevant discovery targets.3

Inventory records should connect technical findings to operational and mission context. At minimum, capture the cryptographic algorithm or mechanism where known; protocol, application, library, hardware, firmware, or service location; data protected or signed; confidentiality or integrity lifetime; system and service owner; supplier and support status; cloud dependency; hardware replacement cycle; interface or size constraints; current fallback behavior; and evidence from discovery, configuration, or supplier responses. The inventory should also identify outside access to datasets and information that could be collected now and decrypted later.3

• Prioritize long-lived or highly sensitive data and services whose compromise would expose greater organizational risk.
• Prioritize digital-signature and code-signing paths, including software and firmware updates, because devices may be unable to update signature-verification code after manufacture.
• Identify dependencies on long-lived hardware, OT, bespoke communications, legacy systems, supply chains, service providers, and cloud-hosted products.
• Record unknowns explicitly. An unconfirmed algorithm, undocumented library, or unanswered vendor question is a risk-management item, not evidence that no dependency exists.

Prioritization should produce an ordered migration backlog, not merely a list of algorithms. A high-priority service may require a supplier-led hardware refresh, a protocol change, a new validation path, or an outage window before its cryptography can change. Conversely, a technically simple replacement can remain low priority if the protected information has a short sensitivity period and the service has low mission impact. The inventory becomes useful when it supports these explicit trade-offs and gives leaders a defensible basis for sequencing funding and procurement.32

Design a changeable target architecture

Crypto agility is the architectural capability to replace and adapt cryptographic algorithms in protocols, applications, software, hardware, firmware, and infrastructure while preserving security and ongoing operations. It is especially important for government estates with long-lived devices, distributed suppliers, and standards or implementation details that may continue to evolve. The target architecture should isolate cryptographic choices where practical, expose controlled configuration and policy points, support inventory and telemetry, and make transitions testable rather than requiring an opaque, system-wide rewrite.4

Protocol and library boundaries deserve particular attention. The cited NIST draft notes that some protocol updates may require only a new algorithm identifier, while others require more substantial changes because PQC algorithms can have larger sizes or different interfaces. Software cryptographic libraries therefore need to incorporate standardized PQC algorithms, and applications must be tested against changed key-exchange and authentication behavior. Architecture reviews should ask where message sizes, certificate handling, latency, memory, firmware space, or hardware interfaces could affect operations; the evidence establishes that such interface and size changes can occur, but does not establish a universal performance result.1

Code signing and secure-update architecture should be treated as a distinct workstream. Code signing verifies the author and helps detect tampering, while installed devices need to verify signatures. If a manufactured device cannot readily update its verification code, the agency may face a long dependency on the original signing design. Inventory the signing authorities, build and release systems, update formats, verification implementations, trust anchors, device populations, and recovery processes before selecting a migration wave.1

Make procurement evidence-based

Procurement is a control point for reducing future lock-in. Engage commercial off-the-shelf vendors, custom suppliers, cloud service providers, and manufacturers early. The CISA, NSA, and NIST fact sheet says a roadmap should state when and how each COTS vendor plans to deliver updates or upgrades that enable PQC, as well as expected migration cost. For cloud-hosted products, agencies should ask providers for their quantum-readiness roadmap and later determine how PQC will be enabled through configuration changes or application updates.3

• Require a supplier statement of cryptographic dependencies, including algorithms, protocols, libraries, signing paths, embedded components, and externally managed services.
• Request a dated product roadmap for PQC support, upgrade or replacement prerequisites, supported configurations, validation status, migration costs, and customer responsibilities.
• Require test access or representative environments, documented rollback and recovery procedures, support for inventory and usage measurement, and notice of cryptographic or interface changes.
• Evaluate the supplier’s treatment of long-lived hardware, firmware, secure boot, certificate and key management, service continuity, and supply-chain dependencies.
• Separate standards status from product availability. The evidence notes that draft implementation specifics were incomplete when the joint fact sheet was published, so procurement records should preserve what is committed, what is tested, and what remains prospective.

Contracts should turn roadmap promises into reviewable deliverables: discovery data, supported configurations, test results, defect remediation, upgrade windows, end-of-support dates, and escalation paths. Agencies should avoid accepting a general statement that a product is “quantum-ready” without defining the algorithms, interfaces, deployment model, validation evidence, operational limitations, and dependencies covered by that statement. Vendor readiness is necessary but does not remove the agency’s responsibility to understand how the product is used in its own architecture.32

Roll out in controlled waves

For each priority system, the migration plan should cover available technology options, procurement, commissioning, testing, backup and data migration, deployment, business continuity, and rollback. The NCSC evidence specifically identifies these activities and emphasizes outage tolerance and rollback, with additional constraints for OT and extensive physical infrastructure. Except for the simplest systems, a staged uplift is more appropriate than assuming a single “big bang” replacement.2

1. Prepare a representative test environment and baseline current security, performance, interoperability, and service behavior.
2. Enable the intended PQC configuration or transition mode in a controlled scope; verify that certificates, keys, protocols, applications, devices, and suppliers interact as designed.
3. Test negative cases: unsupported clients, malformed inputs, signature failures, expired or rotated credentials, unavailable dependencies, capacity limits, and attempted fallback to legacy cryptography.
4. Run operational exercises for backup, recovery, rollback, incident response, help-desk handling, maintenance windows, and supplier escalation.
5. Deploy by service or population wave, with explicit exit criteria, monitoring, accountable approval, and a recorded exception for any retained traditional algorithm.

Testing must verify actual cryptographic behavior, not just successful service availability. The NCSC evidence warns that systems may fall back to traditional cryptography and recommends checking that standardized PQC cipher suites, when available, are actually in use. An assurance process should therefore measure adoption and exceptions, identify clients that are not using PQC, determine whether remedial action is needed, and establish when traditional-algorithm support can be disabled. These measurements should be tied to the inventory so the program can distinguish completed migration from unobserved or untested use.2

Operational adoption also requires training and ownership. System owners need to understand their migration state, residual dependencies, approved exceptions, and rollback responsibilities. Procurement and supplier managers need a repeatable process for updating roadmaps and challenging unsupported claims. Security and privacy risk managers need evidence that prioritization reflects data exposure and mission impact. A migration is complete only when the changed configuration is supported in operations, monitored, recoverable, and represented accurately in the inventory.32

Handle standards, validation, and uncertainty carefully

The source set records that NIST standardized ML-KEM in FIPS 203, ML-DSA in FIPS 204, and SLH-DSA in FIPS 205 in 2024, while LMS and XMSS have more limited uses under NIST SP 800-208. It also reports that vendors were achieving validated testing of PQC implementations through NIST’s cryptographic algorithm validation program and anticipated FIPS 140-3 validated modules during 2025. Agencies should preserve the distinction between an algorithm standard, an implementation validation, a product feature, and a deployed configuration; one does not automatically prove the others.2

The NIST IR 8547 material cited here is explicitly an initial public draft dated November 2024. It discusses future revisions to SP 800-131A with more detailed transition guidance and schedules. Procurement and architecture decisions should therefore record the document status and the assumptions used, monitor applicable final guidance, and provide a controlled way to revise configurations. The final choice for a system should be based on the applicable approved standards, validation requirements, risk decision, and tested implementation—not on a draft passage treated as a binding schedule.1

Conclusion

Government PQC adoption is a program of managed change across cryptography, technology, procurement, suppliers, operations, and mission risk. The practical starting point is a governed inventory that exposes dependencies and data criticality. From there, agencies can sequence high-value and long-lived systems, require credible supplier roadmaps, design for crypto agility, test real behavior including fallback, and deploy with continuity and rollback controls. Because the cited evidence includes both final guidance and an initial public draft, every roadmap should preserve source status and remain adaptable while keeping immediate work—discovery, prioritization, procurement, and testing—on schedule.2341