For years, quantum risk lived in the future tense. The message to security teams was “quantum is coming someday,” and someday never landed on a calendar. That has changed. Post-quantum readiness is no longer a strategy slide about a distant threat. It is a set of dated obligations, and for software and IT vendors those dates now arrive from two directions at once.
Three milestones make this concrete. On September 21, 2026, the FIPS 140-2 validation regime sunsets. On January 1, 2027, the National Security Agency expects new National Security System (NSS) acquisitions to be CNSA 2.0-compliant by default. Finally, on June 22, 2026, Executive Order 14412 set December 31, 2030 for post-quantum key establishment and December 31, 2031 for post-quantum signatures on federal high-value and high-impact systems, and directed a FAR rule requiring covered contractors to comply with PQC-incorporating FIPS by December 31, 2030. If you build, sign, or ship software, both of those dates land on your roadmap. The question is no longer whether to move, but whether you start before the deadlines force the pace.
The two timelines every software vendor is now on
Post-quantum migration is often described as one transition. In practice, software vendors are pulled onto two tracks with different owners, different algorithms, and different deadlines. One is civilian and broad. The other is national security and aggressive. Understanding both is the first step toward a defensible plan.
The civilian track: NIST IR 8547 and the finalized standards
The civilian track runs through NIST. In August 2024, NIST finalized its first post-quantum standards: FIPS 203 (ML-KEM) for key establishment, FIPS 204 (ML-DSA) for general-purpose signatures, and FIPS 205 (SLH-DSA) for hash-based signatures. These are production-ready algorithms, not research proposals.
The dates come from a companion document. NIST IR 8547, “Transition to Post-Quantum Cryptography Standards,” sets the retirement schedule for today’s public-key algorithms. Under that plan, RSA, ECDSA, EdDSA, and finite-field and elliptic-curve Diffie-Hellman at the 112-bit security level are deprecated after 2030, with disallowance in 2035. That schedule applies broadly across federal systems and the vendors who serve them. EO 14412 and OMB Memorandum M-26-15 now carry the operative civilian dates. M-26-15 sets a five-phase migration schedule running from 2026 to 2035 and requires agency migration plans.
The national security track: CNSA 2.0
The national security track is steeper. The NSA’s Commercial National Security Algorithm Suite 2.0 (CNSA 2.0), issued in Version 2.1 in December 2024, sets category-by-category deadlines for NSS. Its most important date for suppliers is January 1, 2027, when new NSS acquisitions are expected to be CNSA 2.0-compliant by default. CNSSP 15 sets the January 1, 2027 acquisition requirement. Equipment and services that cannot support CNSA 2.0 must be phased out by December 31, 2030, and CNSA 2.0 algorithms are mandated by December 31, 2031
CNSA 2.0 is also narrower in what it approves. It permits ML-KEM and ML-DSA, but SLH-DSA is not approved for any use in National Security Systems. CNSSP 15 was updated to incorporate CNSA 2.0, NIAP validates products against published Protection Profiles, and CSfC solutions are registered against NSA Capability Packages. If you sell to federal agencies or the defense industrial base, this track sets your near-term bar.
The most concrete near-term job: your signing pipeline
For software vendors, the signing requirement is the most concrete near-term obligation. Firmware and software signatures have long lifetimes, they are hard to re-issue in the field, and they are exactly what an attacker would want to forge. That makes them the first practical place post-quantum readiness gets real.
Signing also needs new algorithm support, not simply larger keys. CNSA 2.0 specifies stateful hash-based schemes, LMS or XMSS as defined in NIST SP 800-208, for software and firmware signing. Those are distinct from general-purpose ML-DSA and carry their own state-management requirements. A signing pipeline built only around larger RSA or ECDSA keys does not satisfy this obligation. It needs the right quantum-safe algorithms, implemented correctly.
The CMVP bottleneck: two bars, one queue
There is a logistics problem underneath the algorithm problem. Post-quantum validation does not arrive on an empty runway. It collides with the ordinary move from FIPS 140-2 to FIPS 140-3, so a single crowded validation queue now has to clear two bars at the same time.
The timing math is unforgiving. FIPS 140-3 validations have averaged roughly 18 months, and the queue has grown since, so 18 to 30 months is a realistic planning range. As of August 2026, PQC modules sit in the CMVP queue, with several vendors targeting certificates from late 2026 onward.
The FIPS 140-2 sunset adds pressure. On September 21, 2026, remaining active FIPS 140-2 certificates move to the CMVP Historical list. Existing deployments may continue operating, but federal agencies should not include historical modules in new procurements. A single submission often needs to clear both bars, which is why getting into the queue early matters more than it looks.
Harvest now, decrypt later: why waiting is already a decision
The strongest argument for acting now has nothing to do with the arrival date of a working quantum computer. It is the harvest-now-decrypt-later problem. An adversary can capture encrypted traffic today and store it, then decrypt it once a cryptographically relevant quantum computer exists.
That reframes the deadline around data sensitivity, not hardware. If your product protects information that must stay confidential for more than 10 to 15 years, that data can be considered to be already exposed. Waiting is not a neutral position. It is a decision to accept that exposure, and it is one your customers will increasingly ask you to justify.
What a governed migration actually requires
A governed migration comes down to four capabilities a software vendor has to stand up. Answering each readiness question requires an operational control, not a one-time project. Here is what each one demands.
Build a complete cryptographic inventory
You cannot migrate what you cannot see. A complete inventory discovers every certificate, key, algorithm, and library across your products, build pipelines, and cloud environments. Critically, it has to include inherited open-source dependencies, because cryptography you did not write is still cryptography you ship.
Classify quantum-vulnerable assets by sensitivity and lifespan
Not every asset carries the same urgency. Once discovered, quantum-vulnerable assets should be classified against the NIST IR 8547 deprecation schedule and against how long their data or trust must last. That classification turns a flat list into a prioritized migration order.
Make certificates and keys agile at fleet scale
Migration is not a single cutover. You need the ability to rotate, reissue, and re-key at scale, plus the ability to issue PQC-capable and hybrid certificates for a staged transition. Cryptographic agility is what lets you move without breaking production, and then move again when standards evolve.
Assess supplier and dependency posture
Your exposure is not limited to your own code. Assessing the PQC posture of suppliers and dependencies matters because inherited cryptography becomes your exposure the moment you embed it. A vendor that ignores its supply chain inherits every weakness in it.
How Keyfactor can help
These four capabilities map directly to the Keyfactor platform, so the readiness questions above become operational controls rather than open risks.
- Cryptographic inventory and vulnerability assessment. Keyfactor AgileSec discovers cryptographic assets across products, build pipelines, and cloud infrastructure, then supports quantum-vulnerability assessment so you can prioritize.
- PQC-capable and hybrid certificate issuance. EJBCA issues certificates using NIST-standardized PQC algorithms, including hybrid certificates that support a staged migration.
- Crypto agility at fleet scale. Keyfactor Command automates certificate and key lifecycle orchestration, so rotation and re-keying scale without manual per-endpoint work.
- Quantum-safe signing. Keyfactor SignServer and Keyfactor Signum support software and firmware signing, including the LMS and XMSS schemes CNSA 2.0 requires.
Together these products form Keyfactor’s Trust Control Plane: one system of record that observes, analyzes, provisions, orchestrates, and governs cryptographic assets. Instead of chasing certificates across disconnected tools, security teams manage trust as a single, continuous operation. That is what tracking FIPS 140-3 validation of PQC algorithms, and everything else on these timelines, actually requires.
Post-quantum readiness is a program, not a project
The two deadlines are fixed, but the work behind them does not end when a date passes. Standards will evolve, algorithms will be added and retired, and your cryptographic footprint will keep changing. Post-quantum readiness is an operating capability you run continuously, not a milestone you check off.
The practical move is to start now on the two things that take the longest. Build your cryptographic inventory so you know what you are migrating, and get your modules into the validation queue early so the CMVP bottleneck does not set your ship date. The vendors who act ahead of the deadlines will treat them as routine. The ones who wait will meet them as emergencies.
Ready to see where you stand? Request a Demo to map your cryptographic inventory and your path to quantum-safe.
Got post-quantum readiness questions? We’ve got answers.
What is post-quantum readiness for a software vendor?
It is the ongoing ability to discover, classify, and migrate cryptography to quantum-safe standards. For vendors, it centers on signing pipelines, certificate issuance, and validated modules. It is an operating capability, not a one-time upgrade.
When are the key post-quantum deadlines?
Two dates matter most. FIPS 140-2 validations move to the CMVP Historical list on September 21, 2026, and new NSS acquisitions are expected to be CNSA 2.0-compliant by default from January 1, 2027. NIST IR 8547, still an initial public draft, proposes deprecation after 2030 and disallowance after 2035. EO 14412 sets December 31, 2030 for key establishment and December 31, 2031 for digital signatures on federal high-value and high-impact systems.
Which post-quantum algorithms did NIST finalize?
NIST finalized three standards in August 2024: FIPS 203 (ML-KEM) for key establishment, FIPS 204 (ML-DSA) for signatures, and FIPS 205 (SLH-DSA) for hash-based signatures. Of those three, CNSA 2.0 includes ML-KEM and ML-DSA. It also approves LMS and XMSS from SP 800-208 for firmware and software signing, and does not approve SLH-DSA for any use in NSS.
Why is software signing the first priority?
Signatures have long lifetimes and are hard to re-issue once deployed. CNSA 2.0 approves ML-DSA-87 as well as LMS and XMSS for firmware and software signing. Larger RSA or ECDSA keys satisfy none of these. That makes signing the most concrete near-term obligation.
What is the CMVP bottleneck?
Post-quantum validation overlaps with the ordinary FIPS 140-3 transition, creating one crowded queue. Validations have averaged roughly 18 months, so 18 to 30 months is a realistic planning range. Submitting early is the main way to protect your timeline.
What does harvest-now-decrypt-later mean for my product?
Attackers can capture encrypted data today and decrypt it once quantum computers mature. If your product protects data that must stay confidential beyond 10 to 15 years, that data is already exposed. Waiting to migrate is effectively accepting that risk.
How do I start a post-quantum migration?
Begin with a complete cryptographic inventory across products, pipelines, and dependencies. Classify assets by sensitivity and lifespan against the NIST IR 8547 schedule, then build agility to rotate and reissue at scale. Assess your suppliers, since inherited cryptography becomes your exposure.
How does Keyfactor support post-quantum readiness?
Keyfactor AgileSec handles discovery and quantum-vulnerability assessment, EJBCA issues PQC and hybrid certificates, and Keyfactor Command automates lifecycle at scale. SignServer and Signum support quantum-safe signing, all unified in the Trust Control Plane.
