In October 2025, OpenSSH 10.1 shipped a warning that is enabled by default. It fires whenever a connection negotiates key exchange without post-quantum protection. Nothing broke, and no configuration changed. Administrators upgraded a client, connected to a file transfer server that had worked without complaint for years, and were told in their own terminal that the connection was weaker than it should be.
That warning did not create a deadline. It made an existing one visible.
The sequence is worth knowing precisely, because "supports post-quantum" is about to become a very crowded claim.
OpenSSH moved in four steps over two years.
mlkem768x25519-sha256, a hybrid key agreement pairing ML-KEM-768 with X25519.The standards moved in parallel. NIST published FIPS 203, 204 and 205 on 13 August 2024, standardizing ML-KEM, ML-DSA and SLH-DSA. In the IETF, the draft defining hybrid ML-KEM key exchange for SSH was approved by the IESG on 24 February 2026 and moved to the RFC Editor queue the same day. It remains there, and no RFC number has been assigned.
The practical position by mid-2026 is that the algorithms are standardized, the most widely deployed SSH implementation uses them by default, and it now reports when the far end cannot. A server negotiating classical-only key exchange produces a visible signal of that on every connection.
Harvest-now-decrypt-later describes a specific pattern. An adversary captures encrypted traffic today, stores it, and decrypts it years from now once the hardware exists. Capture is inexpensive. Storage is inexpensive. Waiting costs nothing at all.
Whether the pattern is worth an adversary's effort turns on a question that has little to do with cryptography.
Will the contents still matter at the moment they become readable?
For a great deal of encrypted traffic, they will not. An interactive SSH session captured now and decrypted in 2035 would yield shell commands issued against infrastructure that no longer exists, credentials rotated many times over, and configuration for systems long since replaced. The decryption succeeds and returns very little.
File transfer sits at the other end of that spectrum, and it does so on three separate axes.
Sensitivity duration. Consider what moves across an SFTP connection in a regulated environment: patient records, which identify a person for as long as they live; payroll files containing Social Security numbers, which are not reissued because a decade has passed; loan files and account histories held under multi-year retention mandates; source code, engineering drawings, discovery sets, clinical trial data. Under GDPR, a person whose data is exposed ten years after transmission has been harmed no less than one exposed today, and the organization that transmitted it remains accountable.
Volume per capture. An interactive session is a thin stream of keystrokes. A nightly batch to a trading partner is a structured, indexed payload that may contain thousands of records in a single file.
Predictability. Partner integrations run on schedules, to known endpoints, on known ports, with consistent payload shapes. Traffic that is easy to identify and easy to prioritize is easier to select for long-term storage.
Those three properties do not often appear together in other protocols. Whether that makes file transfer the most important place to begin is a judgment each organization will make against its own data. The properties themselves are not really in dispute.
A significant amount of published commentary treats draft guidance as though it were binding, so the two are worth separating.
Settled. FIPS 203, 204 and 205 are published federal standards. In the United States, OMB Memorandum M-26-15, issued 24 June 2026, directs agencies to submit post-quantum migration plans no later than 120 days from that date, or approximately 22 October 2026. It sets an objective of mitigating as much quantum risk as feasible by 31 December 2030, with migration of remaining systems completed by 2035. Its explicit protocol mandate is TLS 1.3 or a successor no later than 2 January 2030. SSH does not appear in the document.
For national security systems, the timeline is tighter. Under CNSSP 15, from 1 January 2027 all new acquisitions for national security systems must be CNSA 2.0 compliant unless otherwise noted, and by 31 December 2030 equipment and services that cannot support CNSA 2.0 must be phased out on the same qualification. CNSA 2.0 specifies ML-KEM-1024 for all classification levels, a stronger parameter set than OpenSSH's ML-KEM-768 default, together with ML-DSA-87. SLH-DSA, though a published FIPS standard, is stated to be "not approved for any use in NSS."
Not settled. NIST IR 8547, the source of the widely quoted dates for deprecating 112-bit-security classical algorithms after 2030 and disallowing them after 2035, remains an initial public draft. It was released in November 2024, comments closed in January 2025, and no final version has been published. FIPS 206, covering FN-DSA, is still in development with no published completion date.
Planning against the draft dates is reasonable, since they represent the clearest available signal of direction. Reading them as current requirements is a different matter, and the distinction is easy to lose when the dates are quoted without their status.
Post-quantum migration is often filed under future work. For many organizations, a related obligation is already in force. It is not a requirement to deploy the new algorithms, but to know which ones are running and to hold a plan for changing them.
Four regimes, arriving independently, land on closely related obligations.
SSH key exchange, cipher and MAC algorithm lists fall within the scope of the first three. The common operational task is the same in each case: know what you are running, and hold a plan for replacing it. For most organizations, the file transfer estate is among the harder parts of that inventory to produce.
There is a reasonable objection to moving quickly. Post-quantum algorithms are new, and new cryptographic implementations are where flaws tend to appear. Placing a decade of confidentiality on a primitive standardized in 2024 carries risk of its own.
Hybrid key exchange addresses that directly. In mlkem768x25519-sha256, both an ML-KEM-768 exchange and an X25519 exchange are performed, and the session key derives from both. An attacker must break both to recover it. A flaw in ML-KEM leaves X25519 protecting the session against classical attack. The arrival of quantum computing leaves ML-KEM protecting it against quantum attack.
NIST's draft transition guidance accommodates hybrid techniques, though it frames them as temporary measures leading to a second transition to post-quantum only. Its timeline disallows quantum-vulnerable key establishment after 2035 without stating a hybrid exception. OpenSSH nonetheless adopted hybrid as a default rather than an option, which suggests the practical case for it is strong even where the long-term standards position is not settled.
It also means that "supports post-quantum cryptography" is an incomplete answer from any vendor. The more useful questions are which parameter set, whether hybrid or standalone, whether it is on by default or requires configuration, and whether the server can be set to require post-quantum rather than merely offer it.
Syncplify Server! added hybrid post-quantum key exchange in version 7, released in October 2025 and announced in April 2025, using mlkem768x25519-sha256 across SSH and therefore SCP and SFTP. Version 8 has been the current release since June 2026.
A typical enterprise SFTP deployment serves partners running client software the operator does not control and cannot upgrade. Some of it is embedded in integration scripts written years ago. Some belongs to counterparties whose change processes are measured in quarters. Requiring post-quantum key exchange across the board will break some of those connections, and an interrupted nightly transfer is a business incident rather than a security improvement.
A workable sequence tends to look like this. Enable hybrid key exchange so that capable clients negotiate it automatically, without requiring it. Then establish which algorithm each connection is actually negotiating, because without that the rest is estimation rather than measurement.
That second step is less straightforward than it sounds. On most servers, the negotiated key exchange algorithm is visible only at verbose or trace-level logging, which is rarely something to leave running against a production system: it is noisy, it costs performance, and it captures far more than anyone wants to retain. In practice a bounded sampling window tends to be enough. Turn trace logging on for a representative period, capture which partners negotiated what, then turn it off.
From there the work is ordinary. Produce a list of partners still falling back to classical-only exchange, ordered by the sensitivity and volume of what they send. Work through the list. Once the remainder is small enough, raise the floor.
The whole process takes months, and it cannot begin before the server supports the algorithms. Whether the server can report the negotiated algorithm at all, and at what logging level, is worth establishing early. It is easier to answer while the migration is still a project than while it is an audit finding.
Most security decisions are made against a threat that either materializes soon or does not. This one is different in a way that is worth sitting with.
Encryption has always been a bet about the future, but usually a short one: that a message stays private long enough to stop mattering. Harvest-now-decrypt-later removes the escape clause. It asks something no engineer can answer with confidence. What will still be worth knowing about a person, a company, or a system in fifteen years, and who will be in a position to read it then?
The files moving through a transfer server tonight will outlive the server, the protocol version, and quite possibly the organizations on both ends of the connection. Information has always had a longer life than the systems built to carry it. What is new is that the systems now have to account for it.
