Harvest Now, Decrypt Later: Why Post-Quantum Migration Is a GRC Programme, Not a Crypto Project

Post-Quantum Cryptography · PQC · Crypto Agility · Harvest Now Decrypt · Later NIST Cryptographic · Inventory · CBOM · Risk Management

The most misunderstood thing about quantum risk is its tense. Framed as "someday a quantum computer might break RSA," it sounds like a 2035 problem, safely delegable to future budgets. Framed correctly, it is happening now: harvest now, decrypt later. Adversaries with long horizons — state actors above all — are intercepting and stockpiling encrypted traffic today, betting that a cryptographically relevant quantum computer will eventually unlock it. For any data whose confidentiality must survive a decade — health records, intellectual property, government material, M&A files, genetic data — the exposure began the moment that traffic left your network. The relevant arithmetic is Mosca's inequality: if the years your data must stay secret, plus the years your migration will take, exceed the years until a capable quantum machine arrives, you are already late. Given that enterprise cryptographic migrations historically take five to ten years, the deadline math is uncomfortable for almost everyone.

The destination is no longer vague. NIST finalised its first post-quantum standards in August 2024: FIPS 203 (ML-KEM, key encapsulation), FIPS 204 (ML-DSA, signatures), and FIPS 205 (SLH-DSA, hash-based signatures), with further algorithms following. NIST's transition guidance signals deprecation of classical public-key algorithms around 2030 and disallowance by 2035; the US CNSA 2.0 timeline pushes national-security suppliers faster, and the EU's coordinated roadmap urges Member States and critical sectors to begin now, with high-risk use cases targeted before the early 2030s. Browsers, major cloud providers, and messaging platforms have already deployed hybrid post-quantum key exchange at scale. The algorithms question is settled. The remaining question — the actual hard one — is organisational, which is why this belongs to GRC.

Step one is an inventory nobody has. You cannot migrate what you cannot see, and almost no organisation knows where its cryptography lives: TLS endpoints, VPNs, code-signing, PKI, database and disk encryption, SSH keys, hardware security modules, firmware, embedded devices, and the algorithms baked into every vendor product you run. The emerging discipline is the cryptographic bill of materials (CBOM) — the crypto analogue of the SBOM — built through discovery scanning, code analysis, and vendor interrogation, and maintained as a living register, not a one-off audit. This inventory is regulator-legible: it slots directly into ISO 27001's asset management and cryptography controls (A.8.24), DORA's ICT asset register expectations, and the CRA's product-security documentation.

Step two is triage by data lifetime, not system criticality. PQC prioritisation inverts the usual risk ordering. The systems to migrate first are not necessarilylayers instead of inline primitives, hybrid classical-plus-PQC modes during transition, and — critically — vendor governance. Most of your cryptography is inside products you buy, so PQC-readiness questions belong in procurement questionnaires and contract clauses now, exactly as SBOM clauses entered them three years ago. Your migration speed will largely be your slowest critical vendor's migration speed.

Framing it for the board is refreshingly easy, because the ingredients are familiar: a defined threat with asymmetric, irreversible impact; regulatory timelines already published; a multi-year remediation with dependencies on suppliers; and a cost curve that punishes late starters, since compressed migrations are the expensive kind. That is an enterprise risk narrative, not a science lecture — no qubit counts required. A credible first-year plan is modest: appoint an owner, build the initial CBOM for internet-facing and long-lived-data systems, add PQC clauses to procurement, pilot hybrid TLS where your stack supports it, and put quantum risk on the risk register with a review cadence tied to external milestones. The organisations that treat PQC as a governance programme with an engineering component — rather than the reverse — will make a decade-long migration boring. Boring, in this domain, is the win condition.