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:
- Intercept encrypted network traffic
- Steal encrypted databases or backups
- Copy protected files from compromised systems
- Collect VPN, email or cloud communications
- Archive encrypted information for future analysis
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:
- Medical and genomic records
- Government and defence information
- Intellectual property and research
- Merger and acquisition documents
- Financial and legal records
- Biometric and identity information
- Critical-infrastructure designs
- Long-term business strategies
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:
- Fraudulent digital certificates
- Forged software or firmware updates
- Impersonation of trusted users or systems
- Manipulation of signed documents
- Compromise of code-signing infrastructures
- Loss of confidence in historical signatures
Post-quantum migration must therefore address both sides of public-key cryptography:
- Key establishment and confidentiality
- Digital signatures, authenticity and integrity
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:
- The algorithm being used
- Its purpose and security function
- Key sizes and cryptographic parameters
- Certificates and certificate authorities
- Protocols and application dependencies
- Data protected by the algorithm
- System and business owners
- Vendor and product dependencies
- Expected data-protection lifetime
- Replacement and interoperability options
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:
- Confidentiality lifetime of the protected data
- Criticality of the system or service
- Exposure to external networks
- Possibility of encrypted data being collected
- Dependence on quantum-vulnerable certificates or signatures
- Complexity of the technology stack
- Availability of post-quantum support
- Vendor readiness and replacement timelines
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:
- Separating cryptographic functions from business logic
- Using policy-driven algorithm selection
- Maintaining central visibility over keys and certificates
- Supporting secure algorithm and parameter updates
- Testing interoperability before production deployment
- Designing rollback and recovery procedures
- Monitoring cryptographic usage and failures
- Avoiding undocumented or hard-coded cryptographic dependencies
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, when post-quantum updates will become available and whether upgrades require product replacement.
Post-quantum requirements should be incorporated into procurement, architecture reviews and supplier-risk assessments.
5. Build crypto-agility
Remove hard-coded algorithm dependencies and create mechanisms for controlled cryptographic replacement, testing and rollback.
6. Begin controlled pilots
Test ML-KEM, ML-DSA and SLH-DSA in non-production environments. Evaluate interoperability, key and signature sizes, certificate handling, performance, monitoring and operational impact.
Hybrid classical and post-quantum approaches may be appropriate during parts of the transition where supported by relevant standards, protocols and organisational policy.
7. Create a phased migration roadmap
Define milestones for high-risk data, internet-facing systems, PKI, VPNs, TLS, code signing, identity services, cloud platforms and long-lived devices.
8. Monitor standards and implementation guidance
Post-quantum standardisation and protocol integration are continuing. Organisations should follow NIST, CISA, relevant standards bodies and trusted technology providers rather than deploying proprietary or unreviewed “quantum-safe” solutions.
CISA, NSA and NIST have jointly advised organisations to create quantum-readiness roadmaps, prepare cryptographic inventories, assess supply-chain dependencies and begin planning their migration.
Common Mistakes Organisations Should Avoid
Post-quantum readiness can be weakened by several incorrect assumptions:
- Waiting for a confirmed quantum-computer deadline
- Treating PQC as only an encryption problem
- Ignoring certificates, signatures, code signing and PKI
- Assuming cloud or software vendors will handle the entire transition
- Migrating without first understanding cryptographic dependencies
- Deploying unstandardised algorithms without sufficient review
- Replacing algorithms without building long-term crypto-agility
- Ignoring legacy systems, embedded devices and operational technology
The objective is not to create panic or replace trusted cryptography overnight. The objective is to reduce uncertainty, identify exposure and prepare systems for an orderly transition.
The Migration Deadline Is Determined by Your Data
No one can reliably predict the exact arrival date of a cryptographically relevant quantum computer.
But organisations do not need that date to begin acting.
NIST has finalised its principal post-quantum standards. Migration guidance is developing. Cryptographic discovery and interoperability work are underway. The direction is already clear.
If sensitive data must remain protected for many years, waiting for quantum computing to become an operational threat is waiting too long.
The transition begins with four practical actions:
Inventory. Prioritise. Build crypto-agility. Migrate.Data stolen today may become readable tomorrow. Post-quantum security must therefore begin now.
– Wiseman CyberSec
