The NIST post-quantum deadline is here: why is only 13 percent of enterprises in production?
NIST's 2026 migration milestone has passed, yet only 13 percent of organisations have moved post-quantum cryptography into production and 60 percent have not meaningfully started.
Only 13 percent of organisations have moved post-quantum cryptography (PQC) into production, and 60 percent have not meaningfully started, even as NIST's 2026 migration milestone passes. The reason is simple to state and hard to fix: quantum-safe is not a software update. It is a full discovery, re-architecture and re-certification of every system that signs, encrypts or authenticates, and most estates do not even have a complete map of where their cryptography lives.
The clock is now concrete. On 21 September 2026, FIPS 140-2 certificates move to the Historical list, which means validated modules stop being freely usable for new federal procurement. On 1 January 2027, CNSA 2.0 becomes mandatory for new US National Security Systems. These are not aspirational dates. They change what a compliant product is allowed to contain.
Why is only 13 percent of enterprises in production?
Because migrating to PQC touches almost everything and can be automated almost nowhere. Classical public-key cryptography (RSA, ECC) is embedded in TLS, code signing, VPNs, hardware security modules, PKI, firmware, identity tokens, database encryption and thousands of vendor products an organisation does not control. Each of those has its own upgrade path, its own testing burden and its own certification story.
The first task is discovery, and it is the one most organisations underestimate. You cannot migrate cryptography you cannot see. A large estate typically has cryptographic dependencies buried in legacy applications, third-party libraries, embedded devices and protocols that were configured years ago by people who have since left. Building a cryptographic bill of materials (CBOM) across that surface is months of work before a single algorithm is swapped.
Then there is the certification lag. New FIPS 204 (ML-DSA) and FIPS 203 (ML-KEM) implementations have to be built, integrated, tested and validated. Hardware refresh cycles, vendor roadmaps and change-control windows in regulated sectors all stretch the timeline further. That is why 60 percent have not meaningfully started: the honest ones have looked at the scope and realised it is a multi-year programme, not a quarter.
What does quantum-safe actually require?
It requires four things in order, and skipping any of them is how migrations stall.
- Inventory. A complete CBOM: every algorithm, key length, certificate and protocol, and which systems depend on them.
- Prioritisation. Rank by exposure. "Harvest now, decrypt later" means any long-lived confidential data crossing a network today is already at risk, so it goes first.
- Migration. Replace or wrap classical primitives with NIST-standardised PQC (ML-KEM for key establishment, ML-DSA for signatures), usually in hybrid mode so classical and post-quantum run together during transition.
- Validation. Re-certify. FIPS 204 and FIPS 203 conformance, interoperability testing and audit evidence that the new cryptography is actually in force, not just installed.
Quantum-safe is a property of the whole estate, not of one product. No single vendor can hand you immunity, and any that claims to is selling a slogan.
What is the "harvest now, decrypt later" threat?
It is the reason the deadline matters before large quantum computers exist. An adversary can capture encrypted traffic today and store it, then decrypt it once a cryptographically relevant quantum computer arrives. Data with a long confidentiality lifetime is therefore already exposed even though the decryption event is years away. Defence records, health data, financial positions and state secrets all fall into that category. This is why the migration cannot wait for the threat to be live. The window to protect a ten-year secret closed ten years before the machine exists.
What do the September 2026 and January 2027 dates mean in practice?
The 21 September 2026 move of FIPS 140-2 to Historical does not switch off existing systems overnight, but it narrows what qualifies for new federal use and signals that validated-module expectations are shifting to the FIPS 140-3 and PQC baseline. The 1 January 2027 CNSA 2.0 mandate is sharper: new US National Security Systems must use the CNSA 2.0 suite, which is post-quantum. For any vendor selling into US government or defence, a product that cannot sign and exchange keys with approved PQC algorithms is, from that date, not compliant for new deployments.
Where does Mickai fit, and where does it not?
Mickai ships with post-quantum signing on by default. Every consequential action inside the system is sealed into an audit ledger using ML-DSA-65 under FIPS 204. That means the AI layer's attestations, the record of what the system did and who authorised it, are quantum-safe from day one rather than bolted on after a breach or a deadline. For a regulated buyer, that removes one item from the migration backlog: the integrity of the AI's own audit trail is not a future project.
Here is the honest limit. Post-quantum signing on Mickai's ledger covers Mickai's attestations. It does not migrate your TLS termination, your existing PKI, your HSMs, your database-at-rest encryption or the hundred other places classical cryptography sits in your estate. Mickai makes the AI layer quantum-safe. It does not make the buyer quantum-safe. We are an ally to the team running that programme, not a substitute for it, and we would rather say so than let a procurement team believe one product closed a gap that spans their whole architecture.
What Mickai does about the deadline is narrow and real. We build post-quantum into the audit foundation so that when your assessors ask whether the AI system's records will survive a quantum adversary, the answer is already yes. The rest of the estate is your programme, and the sooner the inventory starts, the smaller the eventual scramble.
“Only 13 percent of organisations have PQC in production and 60 percent have not meaningfully started, even as NIST's 2026 milestone passes.”
Frequently asked questions
Has the NIST post-quantum deadline actually passed?
NIST's 2026 migration milestone has passed, and it is followed by hard dates: 21 September 2026 moves FIPS 140-2 certificates to the Historical list, and 1 January 2027 makes CNSA 2.0 mandatory for new US National Security Systems. Despite this, only 13 percent of organisations have PQC in production and 60 percent have not meaningfully started.
Why is post-quantum migration so slow?
Because it is not a patch. Classical cryptography is embedded in TLS, PKI, HSMs, code signing, firmware, identity tokens and thousands of third-party products. Each needs discovery, re-architecture, testing and re-certification. Most organisations do not even have a complete inventory of where their cryptography lives, which is the first and most underestimated task.
What is harvest now, decrypt later?
It is the practice of capturing encrypted data today and storing it to decrypt once a cryptographically relevant quantum computer exists. Any data with a long confidentiality lifetime is already at risk, which is why migration cannot wait for quantum computers to arrive. Long-lived defence, health and financial data should be prioritised first.
What algorithms count as quantum-safe under NIST?
The NIST-standardised set includes ML-KEM (FIPS 203) for key establishment and ML-DSA (FIPS 204) for digital signatures. Migrations typically run these in hybrid mode alongside classical algorithms during transition, then validate conformance and interoperability before relying on them.
Does Mickai make my organisation quantum-safe?
No, and we will not claim it. Mickai ships post-quantum signing (ML-DSA-65 under FIPS 204) on by default for its audit ledger, so the AI layer's attestations are quantum-safe from day one. That covers Mickai's records, not your TLS, PKI, HSMs or database encryption. Quantum-safe is a property of your whole estate, and that programme is yours to run.
What should an organisation do first?
Build a cryptographic bill of materials: a complete inventory of every algorithm, key, certificate and protocol and the systems that depend on them. Then prioritise by exposure, migrate to NIST PQC in hybrid mode, and re-certify. You cannot migrate cryptography you cannot see, so discovery comes before anything else.