Post-Quantum Readiness for IT & Software

Overview

Every framework in this guide points in the same direction: know what cryptography you have, prove you control it, and be ready to change it. Post-quantum cryptography is where that direction gets a deadline, and for the IT and software industry, that deadline is arriving from two directions at once.

NIST finalized FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) in August 2024. NIST IR 8547 builds on that finalization to set the civilian timeline: RSA, ECDSA, ECDH, and DSA are deprecated for new use starting in 2030 and disallowed from 2035. Running alongside it, the NSA’s CNSA 2.0 (Version 2.1, December 2024) sets a more aggressive, category-specific timeline for National Security Systems: software and firmware signing is expected to support and prefer CNSA 2.0 algorithms now, with exclusive use targeted by 2030, and from January 1, 2027, new NSS acquisitions are expected to be CNSA 2.0-compliant by default.

For software vendors, the signing requirement is the most concrete near-term obligation: CNSA 2.0 specifies the stateful hash-based schemes LMS or XMSS, standardized in NIST SP 800-208, for software and firmware signing, a different algorithm family from the general-purpose ML-DSA used elsewhere in the suite. That means a code-signing pipeline built only for today’s RSA or ECDSA signing keys needs new algorithm support, not just new key sizes.

Why it matters

CNSA 2.0 and NIST IR 8547 are landing on top of an already-tight CMVP validation queue. FIPS 203, 204, and 205 were finalized in August 2024, and the typical timeline from algorithm standardization to CMVP-validated modules runs 18 to 24 months, meaning the earliest validated post-quantum modules only began arriving in early-to-mid 2026 for vendors that started immediately. Organizations that need a FIPS 140-3 validated module supporting ML-KEM and ML-DSA are entering a validation queue that is simultaneously absorbing the ordinary FIPS 140-3 transition traffic created by the September 21, 2026 FIPS 140-2 sunset covered earlier in this guide.

The practical effect is that a single validation submission increasingly has to clear both bars, standard FIPS 140-3 conformance and post-quantum algorithm support, at once, and vendors treating them as separate projects are working against the same limited lab capacity twice. Major operating system, browser, and cloud vendors are already integrating FIPS 203/204/205 into their cryptographic libraries, which will raise customer and procurement expectations for every vendor further down the supply chain.

Harvest-now-decrypt-later is the underlying economic driver: data encrypted today with today’s algorithms can be captured now and decrypted once quantum capability arrives, so any software protecting data with a confidentiality requirement beyond 10 to 15 years is already exposed to a deadline set by the sensitivity of the data, not the arrival date of a quantum computer.

How this maps to cryptography 

Post-Quantum Readiness addresses cryptography through several interlocking control areas. The key areas with direct cryptographic implications are:

Readiness questions

PQC migration reviews, whether initiated by a federal customer, a certification body, or an internal risk function, focus on whether the organization knows its exposure and has a governed plan. Key areas assessors will probe:

• Cryptographic inventory completeness: Can the organization enumerate every certificate, key, algorithm, and cryptographic library in use across its products, build systems, and cloud infrastructure, including inherited open-source dependencies?
• Quantum vulnerability classification: Has the inventory been assessed against the NIST IR 8547 deprecation schedule, with quantum-vulnerable assets identified and ranked by data sensitivity and deployment lifespan?
• Signing algorithm readiness: Does the software or firmware signing pipeline support the stateful hash-based schemes (LMS, XMSS) CNSA 2.0 specifies, distinct from general-purpose PQC signature algorithms?
• Migration plan and ownership: Is there a named owner, a documented migration plan, and a timeline aligned to CNSA 2.0’s category deadlines and NIST IR 8547’s 2030/2035 dates?
• CMVP validation pipeline status: For any product requiring a FIPS 140-3 validated module with post-quantum algorithm support, is the organization already in the CMVP queue, given 18-to-24-month validation timelines?
• Supplier and dependency PQC posture: Are upstream library, cloud, and component suppliers being assessed for their own PQC migration plans, given that inherited cryptography becomes the vendor’s exposure?

TAKE THIS TO MANAGEMENT

The post-quantum transition now has dates attached from two directions at once. NIST IR 8547 deprecates today’s core algorithms by 2030, and the NSA’s CNSA 2.0 requires new National Security System acquisitions to be compliant by January 1, 2027, with software and firmware signing expected to support the required algorithms now. Our products and the systems that sign and trust them will still be relying on today’s cryptography well past those dates unless we act on our own schedule.

The practical first step is the same one every framework in this guide asks for: a complete cryptographic inventory, including exactly which signing algorithm our build pipeline uses. The CMVP validation queue for post-quantum modules is already absorbing the traffic from the ordinary FIPS 140-2 sunset, so getting in line early is not just prudent, it may be the only way to avoid a multi-year wait when our federal and enterprise customers start asking for proof.