The quantum risk that matters today is not a future quantum computer breaking your encryption. It is an adversary who is, right now, collecting copies of your encrypted data to decrypt later — once the hardware matures. You will not see this attack in any log file. There is no alert to fire, no anomaly to detect. Your data leaves your environment legitimately, encrypted, and sits in someone's storage waiting for the decryption capability to arrive. The collection phase of that attack is already underway.
This is harvest-now, decrypt-later (HNDL). It is not a theoretical threat. It is an operational collection strategy that nation-state adversaries have been executing for several years. The 2024 CISA advisory on post-quantum cryptography named it explicitly. The NSA's Commercial National Security Algorithm Suite 2.0 mandated transition timelines. NIST finalised the first post-quantum cryptographic standards in August 2024. The window for comfortable planning is already closed for certain categories of data.
Who Should Actually Be Worried Right Now
Let me be direct about threat modelling, because HNDL is not uniformly urgent across every company in existence. The urgency is a function of your data's sensitivity horizon — how long the data you encrypt today needs to remain confidential.
The honest calculus: if your adversaries are nation-state actors or well-resourced criminal organisations, if your data remains sensitive for more than 5–7 years, and if you operate in healthcare, defence, financial services, government, critical infrastructure, or advanced manufacturing — you are already in scope. Your encrypted data is, with meaningful probability, already being collected.
If you are a Series A consumer startup with 18 months of runway and no state-level threat actors interested in your user preferences, post-quantum migration is a medium-term planning item, not an emergency. Do not let this become security theatre for audiences where it genuinely does not apply.
The sectors where I push clients hard on this now:
| Sector | Reason for Urgency | Primary Risk |
|---|---|---|
| Reinsurance / financial services | Long-lived contracts, regulatory data, systemic importance — state interest is real | Confidential terms, counterparty data, reserve models |
| Healthcare / life sciences | Clinical trial data, genomic records, IP pipelines span decades | R&D IP, patient records, trial protocols |
| Critical infrastructure / energy | Nation-state targeting well-documented; data operational relevance spans 15+ years | SCADA configurations, grid topology, operational parameters |
| Defence industrial base | Explicit NSA CNSA 2.0 mandates; quantum-readiness is contractual | Classified adjacent information, supply chain data |
| Legal / M&A advisory | Sensitive at the moment of creation; disclosed transactions especially | Deal terms, due diligence materials, counsel communications |
The Three Algorithms That Actually Matter
NIST's finalisation of post-quantum standards in August 2024 ended the "which algorithm" debate for most purposes. The three standards you need to understand:
ML-KEM (FIPS 203) — formerly CRYSTALS-Kyber. This is your post-quantum key encapsulation mechanism — the replacement for RSA and ECDH in key exchange. If you are thinking about TLS, VPNs, and secure communication, this is the primary algorithm you will deploy. It is lattice-based, computationally efficient, and has been through years of NIST evaluation.
ML-DSA (FIPS 204) — formerly CRYSTALS-Dilithium. This is your post-quantum digital signature algorithm. Code signing, certificate issuance, firmware integrity, document signing — wherever RSA or ECDSA signatures appear in your architecture, ML-DSA is the migration target.
SLH-DSA (FIPS 205) — formerly SPHINCS+. Hash-based signatures. Slower and larger than ML-DSA, but based on different mathematical assumptions. Relevant as a backup for contexts where you cannot afford to bet on a single algorithmic family.
Hybrid mode is not a compromise — it is the correct deployment strategy
Most cryptography engineers and standards bodies recommend hybrid mode during the migration window: simultaneously using classical and post-quantum algorithms, so that security holds even if one family has an undiscovered weakness. A hybrid TLS handshake using X25519 + ML-KEM provides classical security against today's adversaries and post-quantum security against future decryption of traffic collected now. This is not belt-and-suspenders timidity. It is the professionally correct deployment posture.
What a Cryptographic Inventory Actually Looks Like
The prerequisite for any migration is understanding what you are migrating. Most organisations have no clear picture of their cryptographic posture — they know they "use TLS" and "use RSA" but cannot tell you where, in what version, with what key lengths, for what purpose, or with what rotation policy.
A cryptographic inventory covers:
Transport layer: Every TLS termination point, its configured cipher suites, and its certificate chain. Identify every place where RSA or ECDH key exchange is occurring. This includes external-facing APIs, internal service-to-service communication, VPN endpoints, and email transmission.
Data at rest: Every encrypted storage layer — database encryption keys, filesystem encryption, backup encryption, object storage server-side encryption. What algorithm, what key management system, what key rotation policy?
Identity and authentication: Certificate authorities (internal and external), code signing infrastructure, token signing keys for identity providers, client certificate issuance. These are the digital signature surfaces.
Embedded and long-lived systems: This is the one most organisations miss. IoT devices, embedded systems, HSMs, firmware signing, BIOS/UEFI secure boot chains. Some of these run for 10–15 years without replacement. If you are signing firmware today with RSA-2048, the devices receiving that firmware will be verifying signatures for a decade — potentially into the quantum computing window.
| Cryptographic Surface | Classical Algorithm Typical Today | PQC Target | Migration Complexity |
|---|---|---|---|
| TLS handshake (key exchange) | ECDH / RSA key exchange | ML-KEM (hybrid with X25519) | Medium — library and config updates |
| TLS certificates (signatures) | RSA-2048 / ECDSA P-256 | ML-DSA (or wait for CA ecosystem) | Medium-High — CA chain dependency |
| Code and firmware signing | RSA-2048 / ECDSA | ML-DSA or SLH-DSA | High — update verification infrastructure |
| Data encryption keys (KEK) | RSA wrapping | ML-KEM | Medium — key management layer |
| Long-term data encryption | AES-256 (symmetric — already PQC-safe) | No change required | Low |
| SSH / VPN | ECDH / RSA | ML-KEM, hybrid | Low-Medium — update clients and servers |
Note the AES-256 entry. Symmetric encryption with sufficiently long keys is already considered quantum-resistant under current analysis — Grover's algorithm halves the effective key length, so AES-256 provides approximately AES-128 equivalent security against a quantum adversary. This is still considered adequate. Your symmetric encryption is not the problem. Your asymmetric encryption is.
The Migration Programme Structure
A cryptographic migration is a multi-year infrastructure programme. Organisations that try to do it as a security project — owned by the CISO, staffed with security engineers — consistently underestimate the engineering scope. This requires infrastructure engineers, platform teams, application teams, and vendor management.
Map every cryptographic surface. Prioritise by sensitivity horizon and threat actor relevance. You cannot migrate everything simultaneously — the inventory tells you where to start. Simultaneously, commission an explicit threat model: are you actually a HNDL target today? If yes, which data? The answers drive the migration sequence.
Before you migrate anything, assess whether your current systems are cryptographically agile — i.e., whether algorithm changes can be made by configuration update or whether they require code changes across dozens of services. Systems built with hard-coded algorithm choices are the ones that will consume most of your migration budget. Document the agility posture. Fix the most rigid systems before the migration clock pressure becomes acute.
Start with network transport. Deploy ML-KEM in hybrid mode for TLS 1.3 connections on your highest-risk external surfaces. Most modern TLS libraries support this — OpenSSL 3.x with the OQS provider, BoringSSL, AWS-LC. Validate performance impact (ML-KEM handshakes are slightly larger; not a performance problem in most cases). Establish the operational playbook before scaling.
This is the longest lead-time workstream because it depends on the CA ecosystem. Internal code signing can migrate to ML-DSA on your own schedule. Public-facing TLS certificates depend on CAs issuing PQC certificates — watch CABF progress and your CA's roadmap. Plan for a hybrid period where you maintain both classical and PQC certificate chains.
Migrate key encapsulation for data encryption keys. Long-lived data stores — backups, archives, data warehouses — require the most careful handling. A re-encryption project for a large data estate is an engineering undertaking, not a configuration change. Sequence by data sensitivity: highest sensitivity data first, highest volume data last.
The longest tail. Device replacement cycles and firmware update constraints mean this workstream extends beyond any reasonable "complete migration" horizon for some asset classes. The practical approach: ensure all new device procurement includes PQC algorithm support requirements in contracts, and plan systematic replacement of devices where firmware updates are not feasible. This is a procurement policy problem as much as an engineering problem.
The six workstreams overlap and sequence like this — earlier phases feed the later ones, and embedded systems run the longest tail:
The Board Conversation
Post-quantum cryptography has reached the point where it belongs in a board-level risk discussion — not because boards need to understand lattice-based cryptography, but because the migration programme is material in terms of cost, timeline, and risk exposure.
The questions the board should be able to answer after that conversation:
- Do we have data that would remain sensitive in 2035? (Almost certainly yes if you are in financial services, healthcare, or critical infrastructure.)
- Do we have a documented threat model that includes HNDL risk?
- Do we have a cryptographic inventory?
- Do we have a migration plan with a budget and timeline?
If the answer to any of these is no, that is the finding. The board does not need a technical briefing. They need to understand that this is a 3–5 year programme that needs to start now, not when quantum computers make the news.
Regulatory timelines are converging on yours
The EU's Cybersecurity Act, NIS2 implementing regulations, and sector-specific mandates from the EBA, EIOPA, and national authorities are all moving toward explicit post-quantum requirements. DORA already requires ICT risk management frameworks that should encompass cryptographic lifecycle management. If you are a regulated entity in the EU, your next regulatory examination may ask about your PQC posture. "We are monitoring the situation" is not an adequate answer in 2026.
What to Do Next Week
The gap between "aware of HNDL" and "operating a migration programme" does not close itself. Three concrete actions that move you from awareness to posture:
First: Commission a cryptographic inventory if you do not have one. This is a 6–8 week exercise with the right team. It will surface findings you did not expect. It is also the prerequisite for everything else.
Second: Pull your cyber insurance policy and check whether it covers cryptographic incidents. Most policies have not caught up to PQC risks. Your broker should be asking you about your quantum roadmap if they are not already.
Third: Review your highest-sensitivity data categories and their retention periods. Anything that will still be sensitive in 2032 and is currently protected only by RSA or ECDH-based encryption is in scope for HNDL risk today. That data should be your first migration priority.
The threat is not coming. For certain categories of data, the collection phase is already complete. What happens next depends on how fast quantum hardware matures — and on whether you migrated before that window closes.
If you need to move this from a threat briefing to an engineering programme, let's talk — book a 30-minute discovery call. I've run cryptographic modernisation programmes inside regulated enterprises and can help you scope what your organisation actually needs versus what the vendor community wants to sell you.