Don't ignore, don't panic — the realistic post-quantum journey.

The threat that is already here

Most conversations about quantum computing and cryptography begin in the future: a point — variously estimated at 2030, 2035, 2040 — when a sufficiently powerful quantum computer can break RSA and elliptic-curve cryptography by running Shor's algorithm at scale. That framing is misleading, because it implies the threat is also in the future. It is not.

The attack that matters right now is called harvest now, decrypt later (HNDL). Nation-state adversaries — and sophisticated criminal organisations — are capturing encrypted network traffic today, storing it, and waiting for quantum capability to mature before decrypting it. For data that will still be sensitive in 2030 or beyond — long-duration insurance contracts, health records, regulatory submissions, board communications — the threat window has already opened.

A firm that begins its post-quantum transition in 2030, when NIST's new standards become regulatory requirements, is protecting its future traffic. It is not protecting the traffic that has already been captured.

Why the official timeline is too comfortable

The United States National Institute of Standards and Technology finalised its first set of post-quantum cryptographic standards in 2024 — ML-KEM (formerly CRYSTALS-Kyber), ML-DSA, SLH-DSA. NCSC guidance, ENISA recommendations and most regulatory frameworks are working toward a 2030–2035 migration horizon. This is a reasonable political timeline for the bulk of the regulated sector. It is not a reasonable timeline for organisations protecting data with a long sensitivity shelf-life.

My own analysis, grounded in practical implementation rather than standards committee timelines, suggests that organisations serious about quantum risk should target completion of their core migration by 2028. This is achievable. OpenSSL 3.5, released in 2025, includes native post-quantum algorithm support. OpenSSH 10, also released in 2025, enables hybrid post-quantum key exchange by default. The building blocks are available today, at production quality, at zero incremental licence cost.

The question is not whether the algorithms exist. They do. The question is whether your organisation can actually swap them in — which is precisely what Cryptoagility is designed to answer.

Cryptoagility — what it means in practice

I coined the term Cryptoagility to describe an organisation's demonstrated ability to swap out its cryptographic algorithms at speed — not just in principle, but in practice, across its full technology stack, without requiring a multi-year programme each time a standard is superseded.

Most organisations are not cryptoagile. Their cryptographic choices are baked into custom code, hardcoded into configuration files, embedded in hardware security modules with fixed firmware, distributed across third-party libraries that are rarely updated, and governed by no one with explicit accountability. The result is that when a standard changes — as it will, repeatedly, over the coming decade — the transition becomes an emergency programme rather than a routine operational task.

Building Cryptoagility means treating your cryptographic layer as a first-class architectural concern: documented, inventoried, owned, and tested. It means knowing precisely which algorithms are in use across your estate, which components are responsible for each, and what the dependency chain is. It means ensuring your procurement process includes cryptographic agility as an explicit requirement. And it means testing your ability to rotate algorithms before you are required to do so under pressure.

A realistic assessment of your technology stack

A practical post-quantum readiness assessment covers five layers. For each, the question is the same: does this layer use cryptography that is vulnerable to a quantum attack, and can we migrate it?

Web and API traffic. TLS 1.3 with classical algorithms is universally deployed. Migration to hybrid post-quantum cipher suites (using ML-KEM alongside classical ECDH) is available today in OpenSSL 3.5, nginx, Cloudflare and AWS. This is the easiest layer to migrate and should be first.

Remote access and server management. SSH. OpenSSH 10 enables hybrid post-quantum key exchange by default. If you are running a current Linux distribution, you may already be partially protected. Check your server and client versions.

Email. SMTP with STARTTLS uses TLS — the same migration path as web traffic. However, email signatures (S/MIME, PGP) use RSA or ECC key pairs that require direct replacement. Email is the layer most organisations address last and should arguably address first, given that sensitive email communications are a primary HNDL target.

Data at rest. AES-256 symmetric encryption is quantum-resistant — Grover's algorithm halves the effective key length, but AES-256 remains secure at 128-bit post-quantum strength. Your key management and key exchange mechanisms are the vulnerability, not the symmetric encryption itself.

Third-party and vendor dependencies. This is the hardest layer. Ask every significant technology vendor for their post-quantum roadmap. If they do not have one — or if it has no committed delivery date — treat that as a risk to manage.

What to do this year

A pragmatic programme for 2026 has four steps. First, complete a cryptographic inventory: every algorithm, every component, every third-party dependency. This does not require a large consulting engagement — it requires someone with the authority to ask the question and the technical knowledge to assess the answers.

Second, migrate your web and API layer to hybrid post-quantum TLS. This is the highest-visibility, lowest-risk migration available and sets a reference implementation for the rest of the programme.

Third, update your SSH infrastructure. On current Linux kernels with OpenSSH 10, this is largely configuration — not a major programme.

Fourth, classify your data by sensitivity shelf-life. For data that will still be sensitive in 2030 or beyond, build a specific plan. For data that will not, a standard migration timeline is probably sufficient.

To support firms beginning this journey, I built Kyber.Club — the world's first public platform for generating NIST FIPS-compliant post-quantum cryptographic key pairs, available free of charge. Over 30,000 key pairs have been generated to date.