Post-quantum cryptography for IT managers: what to do this year

Nobody knows for certain when a quantum computer capable of breaking RSA or elliptic-curve cryptography (ECC) will exist. For an IT manager, though, the exact date matters less than it seems. The algorithms used today for key exchange — in TLS, VPNs, SSH — are in principle vulnerable to such a machine, and migrating a whole organisation takes years.

Today's concrete risk has a name: “harvest now, decrypt later”. An adversary can intercept and store encrypted traffic now and decrypt it once the technology allows. For an online order, irrelevant. For medical records, 20-year contracts, intellectual property or government data, very relevant. The right question is not “when will quantum computers arrive” but “how long must the data I transmit today stay secret”.

In August 2024 NIST published the first three final post-quantum cryptography (PQC) standards. You do not need to understand the maths, but it is worth recognising the names, because you will see them in vendor datasheets:

In March 2025 NIST also selected HQC as a backup key-establishment mechanism, based on different mathematics from ML-KEM — a safety net in case an unexpected weakness appears.

Two documents set the pace. NIST IR 8547, published as a draft in November 2024, proposes that quantum-vulnerable RSA- and ECC-based algorithms be deprecated by 2030 and disallowed after 2035 for US federal systems. As a draft, the dates may still change, but the direction is clear and global vendors are aligning with it.

In Europe, the coordinated implementation roadmap published in June 2025 by the NIS Cooperation Group sets three milestones for Member States:

• By the end of 2026: start the transition — inventories, national plans, engagement with industry.
• By the end of 2030: migrate high-risk use cases and critical infrastructure.
• By 2035: migrate as much as feasible of the remaining systems.

For an organisation in NIS2 scope, cryptography is explicitly part of the technical risk-management measures — see NIS2 Art. 21: the technical controls. A documented PQC plan, even an early one, shows the risk has been identified and is being managed.

You cannot migrate what you do not know you use. A cryptographic inventory — sometimes called a CBOM (Cryptography Bill of Materials), by analogy with an SBOM — answers the question: where, in which system and with which algorithm do we protect data or identities? Starting points:

• TLS certificates, internal and external: key algorithm, length, issuer, expiry date.
• TLS and SSH configurations on servers, load balancers, reverse proxies and VPNs.
• Cryptographic libraries and their versions (OpenSSL, BoringSSL, Java, .NET) from your software inventory.
• Public key infrastructure (PKI), HSMs and code signing.
• In-house applications that call cryptographic functions directly or store encrypted data long term.
• Vendor services (SaaS, cloud, network appliances) where cryptography is not under your control.

A simple criterion often used in PQC discussions: if the time the data must remain confidential plus the time needed to migrate exceeds the point at which a relevant quantum computer might exist, you already have a problem. In practice the order becomes:

1. Long-term confidentiality in transit: site-to-site links, VPNs, backups sent off-site, medical or legal archives.
2. Long-lived roots of trust: internal CAs, firmware and code signing for devices that stay in the field for 10–15 years.
3. Ordinary web traffic: TLS to users, where migration largely arrives through software updates.
4. Short-lived data: sessions, temporary tokens — last on the list.

Put the result into a simple register, with an owner for each system and a target date, and treat it like any other entry in the risk register: reviewed periodically, reported to management, tied to the annual budget. Many migrations will coincide with hardware replacements or licence renewals that are already planned — the advantage of a list made early is that you do not buy a device today that cannot be upgraded tomorrow.

The good news: the first migration is already under way without any effort from you. Major browsers use a hybrid key exchange that combines X25519 (classical) with ML-KEM, under the group name X25519MLKEM768. “Hybrid” means an attacker has to break both algorithms — if ML-KEM turned out to be weak, you would still be at least at today's level of security.

On the server side, OpenSSL 3.5 (April 2025) includes ML-KEM, ML-DSA and SLH-DSA and supports this hybrid group. Practical steps for this year:

• Identify servers, reverse proxies and load balancers running old cryptographic library versions and plan their upgrade.
• Enable the hybrid group where the software supports it, after testing with your real clients (some older middleboxes may struggle with the larger handshake messages).
• Remove old protocol versions (TLS 1.0/1.1) and weak cipher suites — PQC does not rescue a configuration that is already outdated.

Most of your cryptography comes from vendors. Add questions like these to procurement and contract renewals:

1. Do you have a published PQC roadmap with dates?
2. Which NIST-standardised algorithms (ML-KEM, ML-DSA, SLH-DSA) do you support today, and from which version?
3. Do you support hybrid key exchange in TLS and VPN?
4. Can algorithms be changed through configuration, or does it require new hardware?
5. How will the product's certificates and signing keys be updated?

The last two questions are about crypto-agility: the ability to change algorithms without rebuilding the system. It is the most durable lesson of the PQC transition — for in-house applications too: algorithms are not hard-coded but read from configuration.