Post-Quantum Cryptography FAQ: 25 Questions CISOs Ask Most

Post-quantum cryptography (PQC) is a family of encryption and digital signature algorithms designed to resist attacks from both classical and quantum computers. It runs as ordinary software and firmware on today's hardware, so you do not need a quantum computer to use it. Executive Order 14412 sets the U.S. federal migration policy [1].

A cryptographically relevant quantum computer (CRQC) is a quantum computer powerful enough to decrypt data protected by many common forms of cryptography and to defeat existing authentication protocols. OMB uses the term in its migration memo and states that such a machine is not yet known to exist [2].

No. OMB states that a cryptographically relevant quantum computer is not yet known to exist, although steady advances in the field may yield one in the coming decade. Resource estimates describe what a machine would need, not a demonstration, so treat the risk as future but planned for now [2].

Harvest now, decrypt later (HNDL) means a threat actor intercepts encrypted information, stores it, and decrypts it once sufficiently powerful quantum computers exist. The attacker needs no quantum computer today. Canada's Cyber Centre defines the threat and tells departments to treat exposed long-lived data as high priority [13].

OMB lists RSA, Diffie-Hellman, ECDH, ECDSA, DSA, and MQV as quantum-vulnerable. It tells agencies to treat any asymmetric algorithm not known to resist quantum attack the same way. In practice, public-key key exchange and digital signatures need replacement, and TLS, VPNs, and certificates depend on both [2]. ## The standards

Three are final, all published in August 2024: FIPS 203 (ML-KEM) for key establishment, FIPS 204 (ML-DSA) for digital signatures, and FIPS 205 (SLH-DSA), a hash-based backup signature. FN-DSA (FIPS 206) and HQC are still pending, so adopt the three finished standards now [3].

ML-KEM is the module-lattice key-encapsulation mechanism in NIST FIPS 203. It establishes a shared secret between two parties, and it replaces the key-exchange job that Diffie-Hellman and elliptic-curve key exchange perform today. It already runs on the internet inside hybrid TLS groups such as X25519MLKEM768 [3].

ML-DSA is the module-lattice digital signature standard in NIST FIPS 204. It signs certificates, code, and documents, and it is the default general-purpose choice among the finished signature standards. Its signatures run from 2,420 to 4,627 bytes depending on the parameter set, which is far larger than elliptic-curve signatures, so plan for bandwidth and storage [4].

SLH-DSA is the stateless hash-based signature standard in NIST FIPS 205. Its security rests on hash functions instead of lattices, so it works as a fallback if someone breaks a lattice assumption. The tradeoff is size: signatures run to tens of kilobytes, and signing is slower [5].

FN-DSA, based on the Falcon algorithm, produces compact signatures and is planned as FIPS 206. As of Sep. 30, 2026, NIST lists it as in development, and I found no public draft or comment period. NIST has announced no final date, so do not deploy it yet. Check NIST's project page for the current status [16].

HQC is a backup key-encapsulation mechanism that NIST selected on Mar. 11, 2025. It rests on error-correcting codes, not lattices, so it protects you if a flaw appears in ML-KEM. NIST plans a draft standard and a 2027 final, but as of Sep. 30, 2026 I found no published draft. Keep migrating to ML-KEM [6], [16].

No. NIST states that current applications can continue to use AES with 128, 192, or 256-bit keys. Grover's algorithm speeds up brute-force key search only quadratically and is hard to parallelize, and NIST says AES-128 will remain secure for decades. The migration targets public-key algorithms [7]. ## Hybrid and key exchange

Hybrid key exchange runs a classical algorithm and a post-quantum algorithm together and combines their outputs into one shared secret. The result stays secure as long as at least one component stays secure. RFC 10024 defines hybrid groups for TLS 1.3, so browsers and servers can negotiate them [8].

X25519MLKEM768 is a TLS 1.3 hybrid group that pairs classical X25519 with ML-KEM-768. RFC 10024 defines it, and the IANA registry marks it as recommended. Its client key share is 1,216 bytes and its server key share is 1,120 bytes, so handshakes grow larger than classical ones [8]. ## Inventory and agility

A cryptographic bill of materials (CBOM) is a machine-readable inventory of cryptographic assets such as algorithms, certificates, protocols, and keys. CycloneDX defines the format, and Ecma International ratified the CycloneDX specification as ECMA-424. A CBOM helps you find, track, and report vulnerable cryptography [9].

NIST defines crypto agility as the capabilities needed to replace and adapt cryptographic algorithms in protocols, applications, software, hardware, firmware, and infrastructures while preserving security and ongoing operations. In practice, you keep algorithm choices in configuration, not code, so a swap does not require a redesign [15]. ## Deadlines and mandates

Executive Order 14412 directs OMB to require agencies to move high-value assets and high-impact systems to post-quantum key establishment by Dec. 31, 2030, and to post-quantum digital signatures by Dec. 31, 2031. National Security Systems are excluded. OMB memo M-26-15 sets five phases running to full migration by 2035 [1], [2].

NSA's FAQ states that under CNSSP 15, all new National Security System acquisitions must be CNSA 2.0 compliant by Jan. 1, 2027, the earliest hard U.S. deadline, arriving at the end of 2026. Equipment that cannot support CNSA 2.0 must transition by Dec. 31, 2030. CNSA 2.0 calls for ML-KEM-1024 and does not require hybrid solutions [10].

The UK NCSC sets three milestones: define goals and complete discovery by 2028, finish the highest-priority migration by 2031, and complete migration of all systems, services, and products by 2035. It expects some rarely used technologies may need longer than 2035 [11].

The EU's coordinated roadmap, published Jun. 23, 2025, asks Member States to take first steps and set initial national roadmaps by the end of 2026, secure high-risk use cases by the end of 2030, and complete the transition for as many systems as feasible by the end of 2035. It is a recommendation, not a regulation [12].

Canada's roadmap asks federal departments to develop an initial plan in April 2026, finish migration of high-priority systems by the end of 2031, and finish all remaining systems by the end of 2035. It covers federal non-classified IT, and it defines completion as vulnerable algorithms disabled, isolated, or tunnelled [13].

In its Information Security Manual, the Australian Signals Directorate recommends ceasing use of traditional asymmetric cryptography by the end of 2030. ASD does not recommend hybrid schemes but does not prohibit them, and it says organizations should expect to move to purely post-quantum algorithms in the future [14].

Not directly, with two exceptions: federal contractors, once the FAR rule that Executive Order 14412 orders takes effect, and vendors selling to National Security Systems. The dates still set the market, because customers, auditors, and insurers will read them and ask for your plan [1]. ## Planning

The UK NCSC expects large organizations, and those that run their own IT infrastructure, to need two to three years for discovery, assessment, strategy, and initial planning, and another two to three years for early migration and plan refinement. Smaller organizations that mostly use commodity IT may find migration more straightforward, but plan for years, not months [11].

Name a migration owner, then build a cryptographic inventory, starting with an incomplete one and improving it. OMB's first phase covers strategy, planning, and discovery in 2026 to 2027. Next, rank systems by data shelf life and exposure, and ask vendors for post-quantum roadmaps [2].