Harvest Now, Decrypt Later: Why Post-Quantum Migration Cannot Wait Until Quantum Computers Arrive
Some cybersecurity risks become urgent only after the technology behind them becomes available. Post-quantum risk is different. Sensitive information can be stolen today, stored for years and decrypted later when sufficiently capable quantum computers become available. By that point, changing the encryption algorithm will protect future data—but it will not restore the confidentiality of information already collected. This threat is known as Harvest Now, Decrypt Later, or HNDL. For organisations handling long-life health records, identity data, financial information, government communications, intellectual property or strategic business information, the post-quantum deadline may have already started. What Is “Harvest Now, Decrypt Later”? In an HNDL attack, an adversary does not need to break encryption immediately. The attacker may: Today, strong cryptography may prevent the attacker from reading that information. However, the attacker can preserve the ciphertext until more powerful computing capabilities become available. A cryptographically relevant quantum computer could eventually threaten widely used public-key algorithms based on integer factorisation and discrete logarithms. These include RSA, Diffie-Hellman, elliptic-curve Diffie-Hellman and elliptic-curve digital signatures. NIST specifically identifies sensitive or long-lived data protected by quantum-vulnerable cryptography as being exposed to the The attack therefore begins when the encrypted information is collected—not when quantum decryption finally becomes possible. Why Long-Life Data Creates an Immediate Risk Not every piece of information has the same confidentiality period. A promotional email may lose its value within weeks. A customer password can be changed. But other information may remain sensitive for ten, twenty or even thirty years. Examples include: If this information is stolen today and must remain confidential beyond the useful life of its current encryption, the organisation already has a post-quantum exposure. This is why quantum readiness cannot be based only on predicting when a powerful quantum computer will arrive. That date remains uncertain. The more important question is: How long must the data remain confidential, and how long will the organisation need to complete its migration? If the combined data-protection period and migration time extend into the possible quantum-risk window, waiting is not a safe strategy. Quantum Risk Is Not Limited to Decryption Post-quantum discussions often focus only on encrypted data. However, public-key cryptography also protects digital trust. Digital signatures are used to verify software updates, certificates, transactions, documents, devices, users and code. If quantum-vulnerable signature algorithms are compromised, attackers may be able to forge trusted identities or malicious content. Potential consequences include: Post-quantum migration must therefore address both sides of public-key cryptography: Simply replacing an encryption library in one application will not solve the wider problem. NIST’s Post-Quantum Cryptography Standards In August 2024, NIST published its first three principal post-quantum cryptography standards. NIST now states that these algorithms can and should be put into use as organisations begin their migration. ML-KEM — FIPS 203 ML-KEM is a module-lattice-based key-encapsulation mechanism. It allows two parties to establish a shared secret over a public channel. That shared secret can then be used with symmetric cryptography to protect communications. ML-KEM is intended to address quantum risk in key-establishment scenarios such as secure communication protocols, VPNs and other encrypted connections. ML-DSA — FIPS 204 ML-DSA is a module-lattice-based digital-signature algorithm. It is designed to protect the authenticity and integrity of digital information and is expected to support many post-quantum signature deployments. SLH-DSA — FIPS 205 SLH-DSA is a stateless hash-based digital-signature algorithm. Because it is based on a different mathematical approach, it provides an alternative to ML-DSA for appropriate use cases and contributes to cryptographic diversity. These standards provide a foundation, but publishing an algorithm is not the same as completing an enterprise migration. Products, protocols, applications, certificates, hardware and vendor services must all be updated and tested. Migration Begins With a Cryptographic Inventory An organisation cannot migrate cryptography it cannot locate. Cryptographic functions may exist across applications, APIs, cloud services, certificates, VPNs, databases, identity systems, hardware security modules, embedded devices, source code and third-party platforms. Some implementations are visible and centrally managed. Others may be buried inside legacy applications, vendor products or undocumented dependencies. A useful cryptographic inventory should identify: NIST’s National Cybersecurity Center of Excellence is specifically working on cryptographic discovery tools and inventories to help organisations locate quantum-vulnerable cryptography and prioritise migration decisions. The inventory should not be treated as a one-time spreadsheet. It must become part of continuing security architecture, asset management and procurement processes. Prioritise According to Risk, Not Convenience Attempting to replace every cryptographic implementation simultaneously would create unnecessary operational risk. Migration should be prioritised according to: Systems protecting long-life sensitive information should receive early attention. Organisations should also prioritise long-lived infrastructure such as public-key infrastructure, code-signing systems, identity platforms, VPNs, TLS environments, hardware devices and operational technology. These systems may remain deployed for many years and can be difficult to replace quickly. Crypto-Agility Must Become an Architectural Requirement Post-quantum migration should not result in another generation of systems permanently tied to a single algorithm. Algorithms may be weakened, standards may evolve and implementation defects may be discovered. Organisations must be able to change cryptographic components without rebuilding entire systems or causing lengthy service interruptions. NIST defines crypto-agility as the capability to replace and adapt cryptographic algorithms across protocols, applications, software, hardware, firmware and infrastructure while preserving security and ongoing operations. Its guidance was most recently updated in June 2026. Practical crypto-agility may include: Crypto-agility is not merely a post-quantum control. It strengthens the organisation’s ability to respond to any future cryptographic vulnerability or transition. A Practical Post-Quantum Migration Roadmap Organisations do not need to replace every algorithm immediately. They do need a structured programme. 1. Establish ownership Assign responsibility for post-quantum readiness across security, architecture, infrastructure, application development, risk, compliance and procurement teams. 2. Build the cryptographic inventory Identify where RSA, Diffie-Hellman, ECC and other quantum-vulnerable public-key mechanisms are used across internal and third-party environments. 3. Classify data by protection lifetime Determine which information must remain confidential for years or decades. Prioritise data with long-term legal, strategic, financial or personal value. 4. Assess vendor readiness Ask technology providers which NIST-standardised algorithms they support,
