Post-quantum cryptography (PQC) is the next generation of encryption algorithms designed to withstand attacks from quantum computers. This guide covers the NIST standards, the Harvest Now Decrypt Later threat, compliance timelines, and a practical migration framework for enterprise security teams.
Post-quantum cryptography (PQC) is a set of cryptographic algorithms specifically designed to be secure against attacks from both classical computers and quantum computers. These algorithms replace the public-key cryptography systems — RSA, Elliptic Curve Cryptography (ECC), Diffie-Hellman, and DSA — that protect virtually all digital communication today but will be broken by sufficiently powerful quantum computers.
Unlike classical cryptography, which relies on the difficulty of factoring large integers (RSA) or computing discrete logarithms on elliptic curves (ECC), post-quantum algorithms are based on mathematical problems that quantum computers cannot solve efficiently. These include:
The National Institute of Standards and Technology (NIST) published the first three post-quantum cryptography standards in August 2024 after an eight-year evaluation process that began in 2016. These standards — ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205) — are now the baseline for quantum-safe enterprise security.
Post-quantum cryptography is not quantum cryptography. PQC algorithms run on classical hardware — your existing servers, laptops, and network devices. They do not require quantum computers to operate. The term “post-quantum” refers to the threat model they defend against, not the technology they use.
The security of modern public-key cryptography rests on two mathematical problems: integer factorization (RSA) and the elliptic curve discrete logarithm problem (ECC). Both are computationally intractable for classical computers at key sizes used today. RSA-2048 would require approximately 2112 operations to break on a classical machine — well beyond feasibility.
In 1994, mathematician Peter Shor published a quantum algorithm that solves both problems in polynomial time. Shor's algorithm means that a sufficiently large, fault-tolerant quantum computer could factor RSA-2048 or solve the ECDLP for P-256 in hours rather than billions of years. This is not a theoretical curiosity — it is an engineering timeline.
The implications are comprehensive. RSA secures TLS/SSL connections, email encryption (S/MIME, PGP), VPN tunnels, code signing, and certificate authorities. ECC protects TLS 1.3 key exchanges (X25519, P-256), cryptocurrency wallets (secp256k1), mobile authentication, and IoT device identity. Diffie-Hellman underpins key agreement in IPsec, SSH, and legacy TLS. All of these become vulnerable to a single quantum capability.
Symmetric algorithms like AES are less affected. Grover's algorithm provides a quadratic speedup against brute-force search, effectively halving the security level: AES-256 drops to 128-bit equivalent quantum security, which remains secure. AES-128, however, would offer only 64-bit quantum security and should be phased out for long-lived data.
The critical question is not whether quantum computers will break current encryption, but when — and whether your sensitive data will still be sensitive on that day. For most enterprises handling financial records, healthcare data, government communications, or intellectual property, the answer is yes.
NIST's Post-Quantum Cryptography Standardization Project, launched in 2016, evaluated 82 submissions across four rounds. In August 2024, NIST published the first three final standards. A fourth standard (FN-DSA / FIPS 206) is expected in 2025.
Formerly: CRYSTALS-Kyber | Basis: Module Learning With Errors (MLWE)
ML-KEM is a lattice-based key encapsulation mechanism that replaces RSA key transport and ECDH key agreement. It generates shared secrets for symmetric encryption — the same function that X25519 performs in a TLS 1.3 handshake today.
Three security levels are defined: ML-KEM-512 (NIST Level 1, roughly equivalent to AES-128), ML-KEM-768 (Level 3, equivalent to AES-192), and ML-KEM-1024 (Level 5, equivalent to AES-256). ML-KEM-768 is the recommended default for most enterprise applications, balancing security and performance.
Formerly: CRYSTALS-Dilithium | Basis: Module LWE / Module SIS
ML-DSA is a lattice-based digital signature algorithm that replaces RSA signatures, ECDSA, and EdDSA. It provides authentication, integrity verification, code signing, and non-repudiation — every function currently served by classical signature schemes.
Three security levels: ML-DSA-44 (NIST Level 2), ML-DSA-65 (Level 3), and ML-DSA-87 (Level 5). ML-DSA-65 is the recommended default for enterprise use, offering strong security with reasonable signature sizes of 3,309 bytes.
Formerly: SPHINCS+ | Basis: Stateless hash-based construction
SLH-DSA is a conservative signature scheme that relies only on the security of hash functions — it does not depend on lattice assumptions. This makes it a critical fallback if a weakness is discovered in lattice-based cryptography.
SLH-DSA is significantly slower than ML-DSA and produces larger signatures (7,856 to 29,792 bytes depending on parameter set). It is recommended for root CA certificates, firmware signing, long-lived document signatures, and any use case where algorithmic diversity provides defense in depth.
Formerly: FALCON | Basis: NTRU lattices
FN-DSA produces significantly smaller signatures than ML-DSA (666 bytes at Level 1), making it attractive for bandwidth-constrained environments like IoT and embedded systems. However, its signing process requires careful constant-time implementation to avoid side-channel attacks. NIST is expected to publish FIPS 206 in late 2025.
The most immediate quantum threat is not a future quantum computer breaking encryption in real time — it is the systematic collection of encrypted data happening today. This attack model, known as Harvest Now, Decrypt Later (HNDL), is the primary driver for urgent PQC adoption.
The HNDL equation is straightforward: if an adversary intercepts encrypted data today and stores it, they can decrypt it once a cryptographically relevant quantum computer (CRQC) becomes available. The attack is invisible to the victim. There is no intrusion detection alert, no compromised server, no data breach notification — the interception looks identical to normal network traffic because the data is encrypted in transit.
The calculus for adversaries is compelling: storage is cheap ($5/TB/month), quantum computing capability is inevitable, and the value of decrypted government communications, trade secrets, financial records, and healthcare data can be immense. Intelligence agencies, nation-state actors, and advanced persistent threat groups are widely believed to be conducting HNDL operations at scale.
The HNDL risk window is calculated as: data sensitivity lifetime minus time until CRQC availability. If a financial record must remain confidential for 15 years and a CRQC arrives in 10 years, the data is already inside the HNDL window. For most enterprises handling regulated data, the window opened years ago.
This is why NIST, NSA, and CISA are not waiting for quantum computers to arrive before mandating migration. The threat from HNDL is present tense, not future tense. Learn more about HNDL risk scoring.
Post-quantum migration is governed by an accelerating series of regulatory and industry deadlines. Organizations that plan around a single date will miss the cascading requirements that begin years earlier.
NIST publishes FIPS 203, 204, 205
Final PQC standards released. Organizations can begin production implementation of ML-KEM, ML-DSA, and SLH-DSA immediately.
NIST IR 8547 — Transition to PQC Standards
NIST formally declares RSA, ECDSA, ECDH, and classical Diffie-Hellman as "not recommended" for new systems and establishes a deprecation timeline.
FN-DSA (FIPS 206) and HQC standardization
Additional PQC standards expand the algorithm toolkit. HQC provides a non-lattice backup KEM.
Google quantum-safe deadline
Google has committed to deprecating classical-only cryptography across its infrastructure by 2029, creating supply-chain pressure for every organization that integrates with Google services.
CNSA 2.0 deprecation (NSA)
NSA requires quantum-safe algorithms for all National Security Systems. RSA, ECDSA, and ECDH deprecated for government use. Federal contractors must comply.
NIST deprecation and prohibition
NIST plans to deprecate RSA and ECC by 2030 and prohibit their use entirely by 2035 for all federal information systems.
CNSA 2.0 prohibition (NSA)
Classical-only cryptography prohibited in National Security Systems. All systems must use NIST-approved PQC algorithms exclusively.
Given that enterprise PQC migrations take 3-8 years (source: NIST PQC transition guidance), organizations that have not begun planning are already behind the CNSA 2.0 curve. The compliance window is not 2030 — it is now minus the migration duration.
Before selecting algorithms or planning migration phases, every organization needs to answer three foundational questions:
Most enterprises cannot answer this question accurately. Cryptographic dependencies hide in TLS configurations, certificate chains, VPN tunnels, database encryption, API authentication, embedded firmware, and third-party SaaS integrations. A QScout cryptographic assessment maps every instance of RSA, ECC, DH, and DSA across your external attack surface in 7 days.
Data with a sensitivity lifetime exceeding the estimated CRQC timeline is already inside the HNDL threat window. Financial records (7-10 years), healthcare data (lifetime), government classified information (25-75 years), and trade secrets (indefinite) all qualify. Use the quantum risk calculator to model your specific exposure.
Enterprise PQC migration is not a patch — it is a multi-year infrastructure transformation. Factor in procurement cycles, change management, testing requirements, vendor dependencies, and staffing constraints. If your realistic migration timeline exceeds the gap between today and your compliance deadline, you need to begin immediately.
Successful PQC migration follows a structured five-phase approach. Each phase builds on the previous one. Skipping phases — particularly discovery and risk assessment — is the most common cause of migration failure. For a detailed walkthrough, see the PQC Migration Playbook.
Catalog every cryptographic algorithm, key, certificate, and protocol across your enterprise. Build a Cryptographic Bill of Materials (CBOM) that covers TLS configurations, certificate authorities, key management systems, HSMs, embedded firmware, cloud services, and third-party integrations. Automated tools like QScout reduce discovery time from months to days and catch shadow cryptography that manual audits miss.
Evaluate the quantum vulnerability of each cryptographic asset. Calculate HNDL exposure windows based on data sensitivity and retention requirements. Prioritize systems by business criticality, regulatory exposure, and migration complexity. The output is a ranked migration backlog with clear sequencing.
Select NIST-approved algorithms for each use case. Design a crypto-agility framework that enables algorithm rotation without application changes. Plan hybrid deployment strategy (classical + PQC in parallel). Define testing and validation criteria. QSolve migration advisory provides CISO-led architecture planning with standards-mapped algorithm selection.
Deploy hybrid classical + PQC configurations (e.g., X25519 + ML-KEM-768 for TLS key exchange). Run parallel validation to confirm interoperability. Test for performance impact, compatibility with existing systems, and correct algorithm negotiation. Use QStrike forward-threat demonstration to validate that your PQC implementation actually resists quantum attack validation.
Deprecate classical-only cryptographic paths. Transition to PQC-only where hybrid is no longer required. Establish continuous cryptographic monitoring for drift detection, compliance validation, and algorithm lifecycle management. PQC migration is not a one-time project — it is the beginning of continuous cryptographic lifecycle management.
PQC migration requirements vary by industry based on regulatory frameworks, data sensitivity, and compliance timelines. Each vertical faces unique challenges.
PCI DSS quantum readiness, SWIFT migration, trading system cryptography, and financial data HNDL exposure across banking, insurance, and capital markets.
CNSA 2.0 compliance, NSM-10 requirements, FedRAMP PQC considerations, and classified network migration for federal agencies and defense contractors.
HIPAA quantum readiness, ePHI encryption migration, medical device cryptography, and patient data with lifetime confidentiality requirements.
Multi-cloud PQC deployment, SaaS vendor assessment, supply chain cryptographic risk, and enterprise PKI migration for Fortune 1000 organizations.
Post-quantum cryptography (PQC) is a family of cryptographic algorithms designed to resist attacks from both classical computers and quantum computers. Unlike RSA or ECC, which rely on integer factorization or discrete logarithm problems that quantum computers can solve efficiently using Shor's algorithm, PQC algorithms are based on mathematical problems — such as structured lattices, hash functions, and error-correcting codes — that remain computationally hard even for quantum computers. NIST standardized the first three PQC algorithms in August 2024: ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205).
Estimates for a cryptographically relevant quantum computer (CRQC) capable of breaking RSA-2048 or ECC P-256 range from 2029 to 2040, depending on hardware progress. However, the more immediate threat is Harvest Now, Decrypt Later (HNDL): adversaries are already intercepting and storing encrypted data today for future decryption once quantum computers become capable. If your data has a sensitivity lifetime exceeding 5-10 years, the threat window has already opened.
NIST published three post-quantum cryptography standards in August 2024: ML-KEM (FIPS 203, formerly CRYSTALS-Kyber) for key encapsulation and key exchange, ML-DSA (FIPS 204, formerly CRYSTALS-Dilithium) for digital signatures, and SLH-DSA (FIPS 205, formerly SPHINCS+) for stateless hash-based signatures. A fourth standard, FN-DSA (FIPS 206, formerly FALCON), is expected in 2025. These standards replace quantum-vulnerable algorithms like RSA and ECDSA.
Harvest Now, Decrypt Later (HNDL) is a threat model where adversaries intercept and archive encrypted communications today with the intent of decrypting them once a sufficiently powerful quantum computer becomes available. Nation-state actors, intelligence agencies, and advanced persistent threat groups are believed to be actively harvesting encrypted data. This makes PQC migration urgent even before quantum computers can break encryption in real time.
Enterprise PQC migration typically takes 3-8 years (source: NIST PQC transition guidance) depending on organizational size and complexity. The process includes cryptographic inventory and discovery (2-6 months), risk assessment and prioritization (1-3 months), architecture planning and crypto-agility design (3-6 months), hybrid deployment and testing (6-18 months), and full migration with continuous monitoring (12-36 months). Organizations that have not started planning by 2026 risk missing the CNSA 2.0 compliance deadline of 2030.
Yes, AES-256 is considered quantum safe. Grover's algorithm reduces the effective security of symmetric encryption by half, meaning AES-256 provides approximately 128-bit security against quantum attacks — still far beyond practical brute-force capability. AES-128 would offer only 64-bit quantum security and is not recommended for long-term use. The quantum threat primarily affects asymmetric algorithms: RSA, ECC, Diffie-Hellman, and DSA.
ML-KEM (FIPS 203) and ML-DSA (FIPS 204) serve different cryptographic functions. ML-KEM is a key encapsulation mechanism used for secure key exchange — it replaces quantum-vulnerable protocols like RSA key transport and ECDH in TLS handshakes. ML-DSA is a digital signature algorithm used for authentication, code signing, and certificate issuance — it replaces RSA signatures and ECDSA. Both are lattice-based and both are recommended by NIST for general enterprise use.
Yes, for three reasons: (1) The HNDL threat means sensitive data encrypted today is already at risk of future decryption. (2) Enterprise-scale PQC migrations take 3-8 years, and compliance deadlines like CNSA 2.0 (2030) and NIST deprecation (2030-2035) are approaching. (3) NIST IR 8547 (November 2024) formally declares RSA and ECC as "not recommended" for new systems. Organizations should at minimum complete a cryptographic inventory and begin piloting hybrid PQC configurations now.
Cryptographic agility is the ability to swap cryptographic algorithms without changing application code or requiring system downtime. It matters for PQC because the post-quantum landscape is still evolving — new algorithms may be standardized, existing ones may require parameter updates, and vulnerabilities may be discovered. Organizations that hardcode algorithm choices will face expensive re-engineering each time a change is needed. A crypto-agility layer allows algorithm rotation through configuration changes.
PQC migration costs range from $100,000-$500,000 for small enterprises to $2-$10 million for large organizations, spread over 3-8 years (source: NIST PQC transition guidance). Key cost drivers include cryptographic discovery tooling, PKI infrastructure upgrades, application refactoring for larger key and signature sizes, hybrid deployment testing, staff training, and compliance documentation. However, the cost of not migrating — regulatory penalties, data breach liability from HNDL exposure, and loss of government contracts — typically exceeds migration costs by 10-50x.
The first step in any PQC migration is visibility. Run a QScout Free discovery to discover every quantum-vulnerable algorithm in your external infrastructure — no installation required, results in minutes.
This guide is structured with Schema.org Article and FAQPage markup for accurate citation by intelligence engines and search engines. All technical claims reference NIST publications (FIPS 203, 204, 205), NSA CNSA 2.0 documentation, and NIST IR 8547.
To cite: Qtonic Quantum “Post-Quantum Cryptography: What It Is, Why It Matters, and How to Migrate” (2026). https://qtonicquantum.com/post-quantum-cryptography
Verified executive snapshot and primary entry point for cryptographic risk assessment.
ExploreForward-threat validation with provider-aligned platform profiles and engagement-tied performance commitments documented in SOW.
ExplorePQC migration planning with CISO-led engagements.
ExploreInteractive tool to calculate your quantum risk exposure.
ExploreEnterprise playbook for post-quantum cryptography migration.
ExploreStep-by-step checklist for post-quantum migration planning.
ExploreBuild a complete CBOM to identify quantum-vulnerable encryption across your enterprise.
ExplorePost-quantum cryptography terms and definitions.
ExploreNational Security Memorandum 10 quantum readiness requirements.
ExploreNSA CNSA 2.0 algorithm requirements and migration timeline.
Explore