Post-Quantum Security: What Is Intercepted Today Will Be Read Tomorrow

The usual headlines on the topic of quantum computers are either panic-mongering or reassurance. Neither helps. Viewed soberly, the situation is manageable: part of the encryption currently in use has an expiration date, another part does not, and the difference can be explained in a single sentence. However, it becomes practical from there — and that is where the real problems lie.

The Problem Is Called “Harvest Now, Decrypt Later”

Anyone who intercepts encrypted data traffic today can store it. Not to read it now, but to read it once the means to do so exist. A sufficiently large quantum computer breaks precisely those procedures that currently secure key exchange using Shor’s algorithm: RSA, Diffie-Hellman, and elliptic curves.

The attack thus takes place in the future, but the collection of data happens now. For risk assessment, this means: the date of the first quantum computer does not count, but rather the question of how long the data flowing over the line today remains sensitive. A health insurance contract, a design drawing, or a legal mandate is no less confidential in ten years than it is today.

The classic formulation for this is Mosca’s inequality: If the time your data must remain secret, plus the time your transition takes, is greater than the time until the first capable quantum computer — then you are too late. You do not need to know the date of the quantum computer for this. It is enough to know that your own transition takes years.

What Is Affected — and What Is Not

Precision is worthwhile here, as it saves effort.

From these three lines follows the entire prioritization: Key exchange is the construction site; everything else has time.

The Solution Is Here — and It Is Hybrid

The algorithms have been standardized since August 2024. NIST published FIPS 203 ML-KEM, a lattice-based key exchange procedure that, according to the current state of knowledge, also holds up against quantum computers.

The decisive factor is how it is deployed: hybrid. The classical procedure remains in place, the new one is added on top, and the session key is derived from both. If one of the two procedures fails, the other continues to protect. This is not hesitation, but justified caution — the new procedures are significantly younger and have been publicly attacked for a much shorter time than RSA or X25519. The German BSI recommends exclusively hybrid deployment for precisely this reason. So, with the transition, you are not taking on a new risk, but adding a second layer on top.

In practice, the procedures are named as follows — both are available, both are proven:

Where It Fails in Practice

If algorithms and standards are finished — why is the transition then work? For five reasons, none of which have anything to do with cryptography.

1. No one knows where all the crypto is. The web server is not the problem, but the backup that replicates somewhere at night, the monitoring agent, the database connection between two data centers, the device in manufacturing with the web interface from 2014. The most difficult part of a PQ migration is a complete inventory list — not the selection of the algorithm.
2. The software version decides, not the will. ML-KEM is available in OpenSSH only from version 9.9. Ubuntu 24.04 ships 9.6, whereas Debian 13 ships OpenSSH 10. Whoever hardcodes the new algorithm into the configuration brings down every server that does not know it: The service refuses to start due to an unknown name in the configuration. For an SSH server, this is, in the worst case, the loss of access.
3. Old systems can never do it. In almost every grown environment, there is a system whose software will never receive a PQ-capable version — because the application on it is not migratable, because the manufacturer no longer exists, or because a certification process depends on it. Such systems do not disappear just because you write a policy. They need a classification: What runs over them, for how much longer, and what protection layer is placed in front of them in the meantime?
4. Enforcement breaks things no one is aware of. Whoever disables the classical procedures locks out not only attackers, but also every client that is too old — the backup agent, the CI runner, the monitoring. These connections rarely fail immediately. They fail when you need the backup.
5. The most deceptive trap: PQ is configured, but never used. Client and server agree on the first common entry in their algorithm list. If the PQ procedure is in third place and a classical one is before it, the classical one is used — every time. The configuration looks correct, an audit report reports “present,” and in fact, the entry is dead weight. It is not the presence that counts, but the order.

How We Solve This

Our own infrastructure runs on automated hardening baselines: One script sets the security standard of a server, a second measures it independently. The guiding principle behind this is older than the quantum topic:

Hardening without verification is hope.

We have experienced once that a seemingly exemplary configuration file had no effect at all because another file overrode it. Since then, we never check whether a setting exists somewhere, but always what the service actually does.

On this basis, our transition looks like this:

The Algorithm List Is Built at Runtime

The script asks the server which procedures its SSH version actually knows, and takes the best available combination — ML-KEM where present, otherwise the older hybrid procedure. A server with Debian 13 thus automatically receives ML-KEM, one with Ubuntu 24.04 continues to run unchanged, and with the next distribution upgrade, the configuration follows automatically. One script for all systems, without version checks that someone would have to maintain. If the service still rejects the new configuration, it is automatically rolled back — for an SSH configuration, this is the difference between a warning and a server outage.

The Order Is Checked, Not the Presence

The audit run objects if a classical procedure stands before the PQ procedure — exactly the trap from point 5.

What Actually Happens Is Counter-Checked

The audit run establishes a real connection to the service, which allows only the PQ procedure, and evaluates what the two sides have agreed upon. Not “no error message” — that would be worthless, because even a crashed service reports no error. But the logged confirmation that the exchange actually took place post-quantum.

The Hard Cut Is a Switch, Not a Standard

Completely switching off the classical procedures is possible, but it is a conscious decision per system and not the default. The correct order is: first hybrid everywhere, then measure, then identify the remaining old clients — and only then switch off.

The Biggest Lever Is Not in SSH

SSH traffic runs with us exclusively in internal networks and over VPN. Whoever wants to intercept it is already in the network. The traffic that can really be collected on a large scale is the public HTTPS traffic at the edge of the network. There, PQ capability depends on the version of the TLS library — with the currently common container images, the limit lies exactly in between: One version can do it, the previous one cannot. The way there thus leads via an image update and one line of configuration, not via a project.

Some Things Are Already Secure Without You Noticing

Our administration VPN uses WireGuard with classical key exchange — but with an individual pre-shared key per device. This key never goes over the line, and it makes the tunnel quantum-resistant. A detail from the setup procedure that was originally set for a different reason and is today coincidentally exactly right. You only find such points if you systematically go through the inventory — which brings us back to point 1.

What We Recommend

Post-Quantum is not a project that you start and finish, but a property that you build into the standard with which systems are set up and checked. Whoever starts today should proceed in this order:

1. Take an inventory. Which connections carry data that will still be sensitive in ten years? This is the only question that determines priority.
2. Edges first. Everything that runs over the open internet, especially internal.
3. Switch to hybrid, not replace. The protection of today remains preserved.
4. Measure effect, not read configuration. The order of the algorithms decides whether the transition actually achieves something.
5. Name legacy systems. What will never become PQ-capable belongs on a list with an expiration date — and in the meantime behind additional protection layers.
6. Enforce only at the end. And then with a way back.

The effort for the first four points is manageable if the environment is managed automatically. For us, it was additions to existing scripts, not new infrastructure.

We advise and accompany companies in precisely this inventory and transition — from inventorying to hardening systems to ongoing, automated verification. Contact us if you want to know how your connections stand.