PQC for Government Agencies

Why PQC requires an agency-wide program

Post-quantum cryptography is cryptography intended to resist attacks from large-scale quantum computers. The risk concerns commonly used public-key systems whose security depends on integer factorization or discrete logarithms, including systems used for key establishment and digital signatures. NIST’s standardization process evaluated 82 candidate algorithms through three rounds before selecting the first four algorithms for standardization. The resulting federal standards are intended to protect sensitive U.S. government information well into the foreseeable future, including after the advent of cryptographically relevant quantum computers.34

The planning issue is not only whether a quantum computer exists today. German federal guidance notes that near-term development leaps to a cryptographically relevant quantum computer are considered rather unlikely, while also stating that information with long secrecy periods and high security requirements requires immediate action. Encrypted messages and the negotiated data can be collected now and decrypted later—a threat commonly described as “store now, decrypt later.” This makes confidentiality priorities different from many authentication decisions: signatures often need protection only until verification, although long-lived signature keys require additional caution.2

Standards and official guidance to anchor policy

Agencies should distinguish between a cryptographic standard, an implementation, and an assurance or validation requirement. FIPS 203 specifies ML-KEM, a module-lattice-based key-encapsulation mechanism, and defines three parameter sets with different security-strength and performance tradeoffs. All three parameter sets are approved in that standard to protect sensitive, nonclassified communication systems of the U.S. federal government. FIPS 204 specifies ML-DSA, a module-lattice-based digital signature standard. FIPS 205 specifies SLH-DSA, a stateless hash-based digital signature standard designed to provide resistance against attacks from a large-scale quantum computer.435

A standard algorithm is not a complete agency deployment decision. FIPS 203 explains that its implementation information is intended to support validation, while FIPS 204 and FIPS 205 state that valid digital signatures require additional assurances, including assurance of identity and private-key possession. The agency therefore needs both an algorithm and an operational assurance model covering modules, keys, certificates or other identity bindings, signing authority, and verification processes.435

The evidence also contains national and regional guidance with different scopes. The NSA’s current post-quantum resources refer readers to CNSS Policy 15, released March 4, 2025, and its FAQ for the Commercial National Security Algorithm Suite 2.0. The UK National Cyber Security Centre’s migration guidance is primarily aimed at technical decision-makers and risk owners of large organizations, operators of critical national infrastructure, and organizations with bespoke IT; it presents indicative target dates rather than a universal legal mandate. ETSI TR 103 966 V1.1.1, dated October 2024, is a technical report exploring deployment considerations for hybrid schemes and expressly does not provide guidance on whether hybrid schemes should be used.671

Readiness: establish scope before selecting products

The first substantive readiness activity is cryptographic discovery. An agency should define migration goals and perform a full discovery exercise to identify services and infrastructure that depend on cryptography. The inventory should cover public-key encryption and key establishment, digital signatures, certificates and PKI, protocols, applications, devices, embedded systems, operational technology, industrial control systems, cloud and hosted services, suppliers, and data stores. The purpose is not to produce an abstract algorithm list; it is to understand where a change could affect confidentiality, authentication, interoperability, availability, or evidentiary processes.1

Prioritization should be risk-based. The NCSC identifies priority services as those processing the most valuable or long-lived data and asks organizations to identify dependencies on long-lived hardware, supply chains and service providers, and risks from legacy systems. Agencies should add mission impact, information-classification or sensitivity requirements, exposure, replacement-cycle constraints, and dependency concentration to their internal risk assessment. The evidence supports prioritization, but it does not prescribe a universal scoring formula or a single deadline for every agency.1

Discovery should be treated as an ongoing management capability rather than a one-time spreadsheet exercise. Cryptographic dependencies may be hidden in libraries, device firmware, certificate profiles, protocol implementations, vendor-managed services, backup systems, and long-lived archives. The agency should assign owners to inventory records, record algorithm and protocol dependencies, capture key and certificate lifetimes where known, document data-retention and secrecy periods, and record the evidence and uncertainty supporting each priority decision.1

Build and execute a migration roadmap

The NCSC’s indicative timeline identifies 2028 activities that include defining migration goals, carrying out a full discovery exercise, and building an initial plan. The guidance emphasizes that organizations differ in cryptographic maturity and that the weight of activities may vary across sectors. Agencies should therefore use the dates as planning signals and investment anchors, while aligning them with applicable national policy, mission obligations, accreditation requirements, contract terms, and system life cycles.1

For each priority system, the migration plan should include research into available technology options, procurement, commissioning, testing, data backup and migration, and rollout. It should also identify acceptable outage duration, a rollback plan, and dependencies on suppliers. Operational technology and extensive physical infrastructure need particular attention because infrequent replacement cycles can make a rapid replacement impractical. Except for very simple systems, a staged migration with repeated deployment and testing cycles is more consistent with the evidence than a single “big bang” uplift.1

The migration sequence should reflect the maturity of the surrounding ecosystem. NCSC guidance states that confidentiality-protecting services are expected to be available sooner, while certificate-based PKI and Internet-of-Things and industrial-control-system protocols may follow more slowly. Agencies should use this distinction when setting program increments and dependencies, without assuming that a service is ready merely because an algorithm standard exists.34

Agencies should normally seek trusted libraries, certified implementations, and supplier-provided protocol support rather than asking ordinary application teams or suppliers to create their own PQC implementations. The NCSC specifically cautions that most organizations and suppliers should not produce their own implementations. Procurement and assurance teams should instead verify the implementation’s provenance, conformance, validation status where required, secure update process, support lifecycle, and suitability for the agency’s protocols and operating environment.34

Acquisition constraints and assurance questions

PQC acquisition is constrained by more than algorithm choice. ETSI identifies security, interoperability, bandwidth, computation, latency, energy, protocol complexity, implementation complexity, algorithm selection, key management, migration, and forward compatibility as deployment considerations for hybrid schemes. An agency’s request for proposal or technical baseline should therefore require suppliers to explain performance and message-size effects, supported protocols, key and certificate handling, migration paths, downgrade resistance, configuration controls, logging, testing evidence, and the conditions under which traditional algorithms can be disabled.4

Validation and accreditation can materially affect architecture. ETSI reports that FIPS 140-3 validation for cryptographic modules requires approved public-key algorithms and notes that NIST has indicated a PQC key-establishment or signature algorithm can be included when used with an approved traditional algorithm in a FIPS-compliant hybrid mode. This passage describes a cited interoperability and accreditation consideration; it should not be generalized into a blanket approval for every hybrid design. Agencies must confirm the current requirement with the relevant authority and validation program.4

FIPS 203 also notes that certain cryptographic devices and technical data are subject to U.S. federal export controls, and that exports of modules implementing the standard and related technical data must comply with applicable laws and regulations and may require licensing. Agencies procuring internationally cited equipment, software, modules, or technical support should make export-control responsibilities explicit in acquisition planning and supplier contracts.4

Procurement should preserve agency control over future change. Require a documented cryptographic inventory, algorithm and protocol identifiers, supported parameter sets, key-management procedures, test artifacts, vulnerability response, migration milestones, end-of-support dates, and a method for replacing suites without redesigning the entire service. These requirements implement the evidence-supported principle of cryptographic agility: the ability to support alternative suites and define when traditional public-key cryptography will no longer be accepted.4

Hybrid migration and cryptographic agility

Traditional public-key cryptography and PQC will likely coexist for a period because PQC can introduce compatibility-breaking changes to encryption and because protocols, devices, and accreditation regimes may not change simultaneously. NCSC guidance recommends seeking solutions that offer cryptographic agility and identifying criteria for ending support for traditional algorithms. An agency reaches the relevant security state when it no longer has sole dependence on traditional public-key cryptography; that statement does not mean every legacy algorithm should be removed immediately or that every hybrid construction is appropriate.2

Hybrid designs can address particular constraints, including interoperability, protocol limitations, and accreditation. ETSI’s report examines reasons for hybrid key establishment and digital signatures, security and efficiency tradeoffs, algorithm and parameter combinations, and circumstances in which hybrid schemes may eventually be deprecated in favor of purely post-quantum algorithms. It does not recommend using or avoiding hybrids. The agency must therefore document the threat model, security composition, protocol behavior, performance impact, validation position, and exit criteria for any hybrid deployment.7

Operational details matter. ETSI gives an example in which a post-quantum or hybrid key-encapsulation mechanism produces a ciphertext dependent on the client public key, so a server cannot necessarily reuse a cached public key in the same way as a traditional exchange. It also warns that reusing the same random seed for ciphertexts associated with different client public keys can reveal enough information for a passive adversary to recover session keys. Implementations and supplier designs must therefore be reviewed for correct randomness, key reuse, state handling, and protocol-specific behavior.2

Governance, testing, and evidence of readiness

Agency governance should give PQC a named executive sponsor, an accountable risk owner, technical architecture authority, procurement lead, privacy and legal participants where relevant, and system owners for each priority service. The program should maintain decisions about prioritization, accepted residual risk, standards and profiles, validation, supplier dependencies, exception expiry, and retirement of traditional mechanisms. This structure is especially important because the migration will be iterative and supplier road maps may change.2

Testing should proceed in controlled increments: laboratory interoperability testing, performance and capacity testing, certificate and key-lifecycle testing, integration testing, pilot deployment, operational monitoring, and rollback rehearsal. Test plans should include large keys or signatures where applicable, bandwidth and latency constraints, device memory and energy limits, failure recovery, backup restoration, archival verification, and mixed traditional/PQC operation. The evidence identifies these categories as deployment considerations and explicitly calls for testing and business-continuity planning, but it does not supply universal thresholds.2

Readiness evidence should be auditable. A mature agency can show the scope and quality of its cryptographic inventory, rationale for prioritized services, approved standards or profiles, implementation and validation evidence, supplier commitments, test results, continuity and rollback records, exception approvals, and criteria for removing traditional-only dependencies. The agency should also revisit the plan as standards, protocols, certification conditions, and supplier capabilities evolve. No evidence passage supports claiming that a particular agency is fully quantum-safe solely because it has purchased a PQC-capable product.435

Conclusion

For government agencies, PQC readiness is a governed migration program linking information risk, cryptographic discovery, standards, procurement, engineering, accreditation, and continuity. Start with long-lived and high-value confidentiality, establish an authoritative inventory, prioritize systems and suppliers, and create a staged roadmap with testing and rollback. Use final standards such as FIPS 203, FIPS 204, and FIPS 205 where applicable, but separately verify implementation validation and operational assurances. Preserve cryptographic agility, treat hybrid operation as a documented design choice rather than a universal answer, and define when traditional public-key dependence can end.1435