If SSH warns that your connection is not using a post-quantum key exchange algorithm, the server is still relying on classical cryptography. Here is what that means and how to fix it properly.
Since OpenSSH 10.1, released in October 2025, many engineers have started to see a new message when they connect to a server: “WARNING: connection is not using a post-quantum key exchange algorithm. This session may be vulnerable to “store now, decrypt later” attacks. The server may need to be upgraded.”
It is easy to read this as noise and switch it off. It is better read as a free, early result from your quantum readiness discovery. The warning tells you that a specific connection is still protected only by classical key exchange, which a sufficiently capable quantum computer could break. This article explains what the warning means, why OpenSSH added it, how to fix it properly, and what it says about the rest of your estate.
What the warning actually says
The OpenSSH project describes the warning on its post-quantum cryptography page. From version 10.1, the ssh client warns the user when a connection negotiates a key exchange algorithm that is not post-quantum. The full text is:
** WARNING: connection is not using a post-quantum key exchange algorithm.
** This session may be vulnerable to “store now, decrypt later” attacks.
** The server may need to be upgraded. See https://openssh.com/pq.html
The OpenSSH 10.1 release notes list this as a potentially incompatible change, because scripts and tools that parse client output may now see extra lines. Nothing about the session itself has changed. The connection still works exactly as it did before. What has changed is that the client is now telling you something it previously kept quiet about.
Why OpenSSH added it: store now, decrypt later
SSH uses key exchange to agree the session keys that encrypt everything sent over the connection. Classical key exchange methods such as Elliptic Curve Diffie-Hellman rely on mathematical problems that a cryptographically relevant quantum computer would be able to solve.
That creates a risk today, not only in the future. An adversary who records encrypted SSH traffic now could store it and decrypt it later, once such a machine exists. OpenSSH calls this “store now, decrypt later”. It is the same threat we describe in our guide to harvest now, decrypt later. Anything sent through an SSH session, including credentials, configuration, database exports and file transfers, is exposed for as long as that data stays sensitive.
OpenSSH is candid that nobody knows exactly when a cryptographically relevant quantum computer will arrive. Its post-quantum page notes that estimates range from five to twenty years, with many expecting the mid-2030s. Because the attack collects data now, waiting for certainty is the wrong approach for long-lived secrets.
OpenSSH has been post-quantum by default for years
The reassuring part is that modern OpenSSH already does the right thing. According to the OpenSSH project:
OpenSSH 9.0, released in April 2022, made the hybrid sntrup761x25519-sha512 key exchange the default.
OpenSSH 9.9 added mlkem768x25519-sha256, which combines ML-KEM, the key encapsulation mechanism NIST standardised in FIPS 203 in August 2024, with X25519.
OpenSSH 10.0, released on 9 April 2025, made mlkem768x25519-sha256 the default key exchange.
OpenSSH 10.1, released on 6 October 2025, introduced the warning when a non post-quantum method is negotiated.
These are hybrid schemes. They combine a post-quantum algorithm with a classical one, so the session is at least as strong as X25519 alone even if a weakness were found in the newer algorithm. In August 2026 the IETF published RFC 10042, which specifies ML-KEM hybrid key exchange for SSH. Alongside mlkem768x25519-sha256 it defines mlkem768nistp256-sha256 and mlkem1024nistp384-sha384, and notes that NIST curves are sometimes preferred for regulatory compliance.
So if you see the warning, the usual cause is not your client. It is the server, or a configuration somewhere in the path, that cannot or will not negotiate one of these methods.
How to fix the warning properly
OpenSSH gives two main remedies: upgrade the server, or check that its configuration has not disabled the post-quantum options. In practice, work through these steps.
Identify the server. Note the host that triggered the warning and confirm what SSH software and version it runs. Network appliances, embedded devices, managed file transfer products and older operating systems often run SSH implementations that lag behind current OpenSSH.
Upgrade where you can. A server running a current OpenSSH release will negotiate post-quantum key exchange with a current client without further work.
Review KexAlgorithms. Hardening guides and configuration templates sometimes pin an explicit list of key exchange algorithms. If that list predates the post-quantum options, it will exclude them. Check both the server configuration and any client configuration that overrides defaults.
Ask vendors for a date. For appliances and third-party products you cannot upgrade yourself, ask the supplier when they will support ML-KEM hybrid key exchange, and record the answer.
Retest. Connect again with a current client and confirm the warning has gone.
OpenSSH also documents a WarnWeakCrypto option in ssh_config that can silence the warning, and recommends doing so selectively, for example for a single host inside a Match block. Suppressing the message does not change the key exchange. It only stops you hearing about it. If you do suppress it for a system that cannot yet be fixed, record that system as a known exception with an owner and a review date.
Key exchange and signatures are different problems
The warning is about key exchange, which protects confidentiality. SSH also uses digital signatures, through host keys and user keys, to prove identity. OpenSSH notes that signatures are not exposed to store now, decrypt later attacks, because a forged signature is only useful while the system that checks it is live.
That does not mean classical keys can stay forever. OpenSSH is clear that classical signature keys need to be retired before a cryptographically relevant quantum computer exists. A sensible order of work is to fix key exchange first, because recorded traffic cannot be protected after the event, then plan the migration of host and user keys as post-quantum signature support matures.
What the warning tells you about the rest of your estate
A single SSH warning is a useful signal because it is visible. Most quantum-vulnerable cryptography is not. The same classical key exchange that triggers the warning in a terminal also sits inside TLS libraries, VPNs, internal APIs, payment links, hardware security modules, signing services and the dependencies of your own code. None of those will print a message when they connect.
Regulators are now putting dates on this work. NIST IR 8547, finalised in October 2026, lists SSH among the protocols that need to move to post-quantum cryptography, and sets out that quantum-vulnerable public-key algorithms are deprecated after 2030 and disallowed after 2035. The UK NCSC’s migration timelines ask organisations to complete discovery and an initial plan by 2028, finish their highest-priority migrations by 2031 and complete migration by 2035. We track these milestones, with links to each primary source, on our regulatory clock.
For financial services firms, defence and aerospace suppliers and public bodies, SSH is often the route by which administrators reach the most sensitive systems. That makes SSH key exchange a good place to start. It should not be the only place you look.
Turning a warning into a plan
Treat every instance of the warning as a finding. Record the host, the owner, the software and version, the data that passes over the connection and how long that data must stay confidential. Then extend the same discipline to every other place your organisation uses public-key cryptography.
That is the work QuantSec does. Our vulnerability mode scans on-chain and off-chain infrastructure, code and dependencies for quantum-vulnerable cryptography, including classical key exchange in protocols such as SSH and TLS, and ranks each finding by severity and exposure. The output is a digitally signed report with a prioritised migration plan. Anyone can check that the report has not been altered, because its digital signature must match its content. For larger organisations, our enterprise approach covers estates that mix modern and legacy systems, and our quantum migration as a service team can carry out the remediation with you.
Sources
NIST FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard
NIST IR 8547: Transition to Post-Quantum Cryptography Standards
Find out what a quantum computer could break in your estate
QuantSec scans your on-chain and off-chain systems for cryptography a quantum computer could break, then delivers a digitally signed report with a prioritised migration plan. When you are ready to act, our team can carry out the post-quantum migration with you.
