In most boardrooms, “quantum” still lives in the future-tense bucket alongside carbon neutrality targets and metaverse pilots. It is treated as a long-range planning item, not a live operational risk. This framing is wrong — and the window to correct it is narrowing.
The asymmetry of harvest attacks
A harvest-now, decrypt-later (HNDL) attack requires no quantum computer today. A well-resourced adversary — a nation-state intelligence service, a sophisticated criminal organisation with state backing — captures encrypted traffic now and stores it. The ciphertext sits inert in their archive until a cryptographically relevant quantum computer (CRQC) becomes available. At that point, everything captured over the preceding decade becomes plaintext retroactively.
This is not theoretical. HNDL operations have been documented in intelligence community assessments from the NSA, GCHQ, and the German BSI. The key insight: the adversary does not need to break encryption today. They only need to break it eventually. And the cost of storage has fallen below the threshold where it even represents a meaningful operational consideration.
The 2029–2033 planning window
NIST’s post-quantum cryptography standardisation project published its first final standards in August 2024 (FIPS 203, 204, 205), giving migration teams a stable algorithm baseline. NSA CNSA 2.0 guidance, Germany’s BSI TR-02102 series, and European ENISA PQC guidance all point teams toward near-term inventory and transition planning for long-lived sensitive data.
A decade sounds comfortable. It is not. Enterprise cryptographic migrations are multi-year programmes. Identifying every cryptographic dependency across a large organisation — certificates, VPN tunnels, firmware signing chains, API authentication tokens, HSM-backed key stores — typically takes six to twelve months before remediation begins. Then the migration itself proceeds in waves, each wave requiring testing, staged rollout, and regression verification. Organisations that start in 2027 may not finish by 2033.
What the board needs to understand
Three questions that belong in the next risk committee agenda:
- What is our cryptographic inventory? Most organisations cannot answer this. They know they use TLS, but not which libraries implement it, which certificates are RSA vs ECDSA, which internal services use deprecated algorithms, or which embedded systems have no upgrade path at all.
- What data are adversaries already archiving? Any traffic that crosses a public network — even encrypted — should be assumed harvested by capable adversaries. The question is whether that data retains sensitivity beyond the projected CRQC horizon.
- What is the migration lead time for our most critical systems? Legacy SCADA systems, hardware security modules on fixed firmware, and long-lived certificates in embedded devices may require hardware replacement, not software updates.
Starting the migration
The NIST standards provide a clear algorithm selection baseline. For key encapsulation (replacing ECDH and RSA encryption), ML-KEM (CRYSTALS-Kyber, FIPS 203) is the primary choice. For digital signatures, ML-DSA (CRYSTALS-Dilithium, FIPS 204) and SLH-DSA (SPHINCS+, FIPS 205) are standardised. Hybrid modes — running classical and post-quantum algorithms in parallel — are the recommended migration bridge.
The migration is an engineering programme, but it starts with a business decision: when does the board accept that this is a present-tense risk rather than a future-tense planning item? For organisations handling data with a sensitivity horizon beyond 2030, the answer is already overdue.