A new date, not a new panic

On 27 October 2026 NIST published the final version of NIST IR 8547, "Transition to Post-Quantum Cryptography Standards". In short, it sets a timetable for retiring the algorithms that protect most secure traffic on the internet. A week earlier, on 20 October, the European Commission updated its page on post-quantum cryptography, restating that all Member States should start their transition by the end of 2026.

The calm reading: nobody switches your website off in 2030. But the question "where do we use cryptography that will eventually age out, and which data must stay secret for years to come?" is far cheaper to answer now, while it is an inventory exercise rather than an emergency project.

First, the terms. Post-quantum cryptography (PQC) means algorithms designed to withstand a future quantum computer. Current secure email, VPNs, HTTPS and digital signatures rely on asymmetric cryptography, where each party has a key pair, one public and one private. The best-known algorithms are RSA and ECC (elliptic-curve cryptography, which includes ECDSA and ECDH), plus Diffie-Hellman (DH) key exchange. A sufficiently powerful quantum computer could break them using Shor's algorithm. No such machine has been built yet; NIST itself says the transition is starting before one exists.

What NIST actually wrote

The core of IR 8547: RSA, ECDSA, EdDSA, Diffie-Hellman and its elliptic-curve variant are marked "Deprecated after 2030" and "Disallowed after 2035". The words matter.

• Deprecated: the algorithm may still be used, but there is some security risk. The data owner must examine that risk and decide whether to carry on.

• Disallowed: the algorithm is no longer allowed for the stated purpose.

So "RSA is banned in 2030" is wrong. In 2030 it becomes deprecated, and under NIST's plan the ban comes after 2035. Two further points. First, these dates concern NIST standards, and application-specific guidance may require earlier moves, above all for key exchange in protocols such as TLS (Transport Layer Security, behind HTTPS). Second, this is not a call to re-encrypt everything: symmetric algorithms such as AES are far more resistant to quantum attack, and NIST believes approved primitives with at least 128 bits of strength meet at least Category 1 on its post-quantum security scale. The problem sits on the asymmetric side.

Replacements already exist. In August 2024 NIST published three standards: FIPS 203 (ML-KEM, key establishment), FIPS 204 (ML-DSA, signatures) and FIPS 205 (SLH-DSA, hash-based signatures). For key exchange NIST recommends ML-KEM-768 as the default parameter set.

"Harvest now, decrypt later"

2035 sounds distant, so here is why the inventory cannot wait. The threat's name, "harvest now, decrypt later" (HNDL), explains most of it. An attacker intercepts and stores encrypted traffic or stolen archives now and decrypts them once quantum computers are available.

NIST calls this one of the main reasons the transition is urgent. The European Commission goes further on its page: data that is not quantum-safe and must stay confidential for a long time may already be at risk, and such "store now, decrypt later" attacks are, in its words, likely already occurring. That is the Commission's assessment, not a proven fact, but worth planning around.

An important distinction: HNDL concerns confidentiality, meaning encryption and key exchange. Signatures are not exposed to it. NIST explains that authentication stays secure as long as the algorithms and keys are secure at the moment it is performed, so it may keep using vulnerable algorithms until a relevant quantum computer exists. But it adds that signatures should not be left late either, because the transition is long and needs many parties to coordinate. Think of certificate authorities, smart cards and hardware tokens.

Why "ten years" is not a cushion

NIST cites a simple piece of logic known as Mosca's theorem. Let X be the number of years your data must stay secret, Y the number of years your migration will take, and Z the number of years until a relevant quantum computer arrives. If X plus Y exceeds Z, the data is already at risk. Nobody knows Z, and the primary sources give no date, so we will not guess one. X and Y you can estimate yourself.

Y is usually longer than people assume. NIST notes that the journey from standardising an algorithm to full integration into systems has historically taken ten to twenty years.

A hypothetical example (invented, with illustrative numbers). A company holds contracts and medical certificates that must stay confidential for fifteen years, and its team reckons migration will take five. X plus Y is twenty. The question is whether you can be sure no such computer will exist within twenty years.

What the EU and the UK say

In April 2024 the European Commission issued a Recommendation on PQC, and in June 2025 the Member States adopted a Coordinated Implementation Roadmap. It is written for states, not for each company: all Member States should start the transition by the end of 2026, and protection of high-risk use cases should move as soon as possible and no later than the end of 2030. National plans can reach business through regulators, customers and the supply chain.

The UK's NCSC gives the most concrete milestones for organisations in its guidance on migration timelines:

• by 2028: define migration goals, carry out a full discovery exercise across your estate and build an initial plan;

• by 2031: carry out the earliest, highest-priority migration activities and refine the plan;

• by 2035: complete migration of all systems, services and products.

The NCSC says the guidance is aimed mainly at large organisations, operators of critical national infrastructure and companies with bespoke IT. For small and medium-sized businesses on commodity IT, migration should happen seamlessly as vendors update their services. The caveat: custom or specialised software follows the same timetable as for large organisations.

Six steps, no panic

What follows is practice, not a requirement of any standard. Each step builds on the one before.

1. Inventory your cryptography. Ask a plain question: where do we use asymmetric cryptography? The NCSC stresses that at this stage you need to understand each system, not build a formal register of every item. For each system, record:

• where it runs and who looks after it (in-house, cloud, contractor);

• which protocols and algorithms it uses: TLS, VPN, SSH, email encryption, document and code signing, an internal certificate authority;

• which certificates and keys exist, where they are held (files, a hardware security module or HSM, a cloud key service) and when they expire;

• which libraries, versions and suppliers are involved.

Do not forget code signing, device firmware, staff tokens, site-to-site VPNs and partner APIs.

2. Prioritise by data lifetime. Write down how long each system's data must stay secret and set it against your migration estimate, as in Mosca's logic. First come systems where the secrecy period is long and the data crosses channels that can be intercepted: site-to-site VPNs, archive transfers, partner integrations. The NCSC says the same: identify the services handling your most valuable or long-lived data, and those depending on long-lived hardware.

3. Choose a strategy per system. Not everything needs migrating. The NCSC lists five options: in-place migration, re-platforming, retiring the service, running to end of life, or consciously tolerating the risk.

4. Build crypto-agility. This is the ability to change an algorithm without rebuilding the system, and NIST urges organisations to build it into their infrastructure. In practice: algorithms and key lengths set by configuration rather than hard-coded; libraries updated centrally; certificates managed by a process, not one person with a spreadsheet. Before buying a new system, ask whether it can change algorithms. NIST adds a warning for devices whose signature verification cannot be updated after release: they must require post-quantum signatures from the start if they may outlive a relevant quantum computer.

5. Set supplier requirements. Much of your cryptography is provided by others: the cloud, SaaS (software as a service), the contractor running your IT, network equipment makers. The NCSC notes that managed service providers should carry out the same assessment for every service they provide. Put these questions in writing:

• do you know where the service you provide us uses asymmetric cryptography?

• what is your plan and indicative timing for moving to post-quantum algorithms?

• can the product change algorithms through configuration, or does that need a new version?

• how will you tell us about changes that affect compatibility?

Write the answers into contracts and service level agreements (SLAs) for new and renewed deals. "We are monitoring the situation" is not a plan.

6. Write the roadmap. Pull it into one short document on the NCSC horizons: discovery and an initial plan first, the highest-priority moves second, the remainder third. Each item needs an owner, dependencies, a rollback plan and a budget line.

Hybrids and TLS: neither rush nor refuse

For key exchange, NIST describes hybrid schemes in which a post-quantum and a classical algorithm work together, so the key stays secure while at least one holds. That insures against a flaw in a new algorithm, but NIST is candid that hybrids add complexity and risk and are usually temporary. The decision depends on the application.

NIST also names TLS as an early priority, with TLS 1.3 as a practical route to post-quantum key exchange. If some of your services still run old TLS versions, moving to TLS 1.3 is good preparation whatever your quantum plans.

Common mistakes

• Waiting for 2035. The secrecy period of your data may reach further, and migration (Y) is slow.

• Assuming everything must be re-encrypted. The problem is the asymmetric part.

• Buying "quantum protection" before taking stock. Without a list of systems, nobody can say what it protects.

• Keeping a register nobody owns. With no review date it will go stale faster than your certificates.

What this means for organisations in the UK and the EU

Nothing above is a legal requirement on your company; for obligations, ask your adviser and regulator. What the sources support is this. For UK organisations the NCSC timetable is the nearest national yardstick, aimed at large organisations, critical infrastructure and bespoke IT. For organisations in the EU or serving customers there, the practical channels are your regulator, customer security questionnaires and the supply chain. Anyone holding personal, financial or medical data for long periods has a long X and should start with data classification; anyone building software or devices must think about code signing and firmware updates; anyone relying on standard cloud services depends largely on supplier plans.

A practical way in: a cybersecurity audit shows where cryptography and its management are weak even now: expired certificates, outdated protocols, keys with no owner. A review of system and infrastructure security shows which protocols and settings actually run across networks, VPNs and servers. And if you already run an information security management system, the cryptography register fits the same asset and risk records; see ISO 27001 implementation.

Where to start this month

Not with choosing an algorithm. Take three systems: the one holding the most data, the one sending the most data outward, and the one that will live longest. For each, answer five questions: what is encrypted, with what, who manages the keys, how many years must the data stay secret, and can the algorithm be changed without a rebuild. Then add the remaining systems, send the questions to your suppliers and draft the first roadmap.

If you cannot answer, that is a normal starting point: in most organisations cryptography has grown over decades, and nobody kept count.

Frequently asked questions

Is RSA really banned in 2030?

No. Under IR 8547, RSA, ECDSA, EdDSA and key exchange based on DH and ECDH become "Deprecated after 2030" (still usable, with the data owner judging the risk) and "Disallowed after 2035". Application-specific guidance may set earlier requirements for particular uses.

Does this apply to a small business?

Yes, but more lightly. The NCSC says that for organisations on commodity IT, migration should arrive with vendor updates. Keep systems up to date, ask key suppliers about their plans, and list anything custom: code, devices, integrations.

What is crypto-agility in plain words?

The ability to change an algorithm or key length through configuration or a library update rather than by rewriting the system. It insures against new algorithms proving weaker than expected and against future changes to standards.

Do we need hybrid solutions?

Not necessarily. NIST allows them but warns about complexity and risk and expects them to be temporary. A hybrid should have its own security review before launch.

Can the EU roadmap oblige my company?

It is addressed to Member States: start the transition by the end of 2026, move high-risk use cases no later than the end of 2030. Obligations for companies come from national regulators, sector rules and customer contracts. Ask your legal adviser and regulator.

Would you like to look with us at where cryptography lives in your infrastructure, and what is truly urgent? Let's talk.