Somewhere, someone is recording your file transfers. Right now.
They have no idea who you are, which is the unintuitive part, and it’s also why the whole subject tends to get quickly dismissed as a “a problem for next year… or the one after that”.
It’s not like a Mission: Impossible movie, where someone is sitting outside your building with a laptop inside a suspiciously windowless white van. This is a slow game, patient… and cheap: capture encrypted traffic off a backbone, store it, and wait. Storage is the only cost, and storage has never been cheaper.
This strategy has a name: harvest now, decrypt later (or HNDL for short). It’s an attack against the key-exchange, which occurs at the start of a session where two machines agree on a secret to protect a channel anyone can read. Everything after that depends on it. Break the key exchange and you have the session. All of it. Whenever you get around to it.
Classical key-exchange is breakable by a sufficiently large quantum computer. We’ve known how to for years. The only question still open is the date, and that date is approaching faster than ever before.
The session you are having today is the one you cannot fix
A session captured in 2026 and decrypted in 2034 is a 2026 breach with a 2034 discovery date. No amount of later diligence can go back in time to fix it. The upgrade has to happen before the traffic exists, which means now.
If you transfer payroll files, patient records, insurance claims, financial statements, engineering drawings, legal discovery… very little of that becomes harmless in a decade. Some of it never does.
What we actually negotiate
Every protocol we terminate negotiates a hybrid post-quantum key exchange:
SFTP negotiates
mlkem768x25519-sha256, which is ML-KEM-768 combined with X25519FTPS, FTPES and HTTPS negotiate
X25519MLKEM768, the TLS 1.3 equivalent
And hybrid is the keyword here. Both halves run, and the session key is derived from both. An attacker has to break the classical exchange and the ML-KEM to decrypt the session.
And behind the protocol endpoints…
The four protocols are the part your clients connect to. But there is a second set of connections behind them that most vendors never talk about: the platform’s own control plane, and its relative inter-component data plane.
For example, a session on SFTP.cloud involves three components: the Protocol Head that terminates your connection, the control plane that authorizes it, and the Storage Connector running inside your own network. Every link between those components is mutually authenticated TLS (or mTLS for short) and every one of those links also negotiates a hybrid post-quantum key exchange.
Where everybody else stands
We checked the published documentation of nine other vendors on September 21, 2026. Their own official release notes, cipher lists and security pages. Here’s what we found.
AWS Transfer Family has support for hybrid ML-KEM key exchange since May 2025, selected through a security policy, but they only support it for SFTP. Their own security policy reference shows the TLS cipher section is unchanged, so AWS Transfer Family’s FTPS remains only classical.
Files.com has a standing documentation page on post-quantum cryptography, where they say they will ship across HTTPS, FTPS and SFTP when the ecosystem is ready. They also say that there is no target date, and their published cipher list confirms nothing has shipped.
Five other vendors are documenting cryptographic work and leaving post-quantum out. GoAnywhere added four classical Diffie-Hellman key exchange algorithms to its FIPS mode in April 2026. Cleo added three more in the Harmony 5.8.1 line, patched as recently as 10 September 2026. CrushFTP publishes a complete enumerated key exchange list with no hybrid entry, in a changelog that tracks cryptography closely enough to record removing DSA. Serv-U's July 2026 release notes document an OpenSSL update to version 3.0.21, which is several series below the one that introduced ML-KEM. MOVEit Transfer 2026's release notes give OpenSSL 3 and FIPS mode as the cryptography headline and doesn’t mention post-quantum anywhere.
Finally, three other vendors publish too little to say anything about them. Kiteworks, Couchdrop and sftpcloud.io do not publish their cipher inventories, or at least we weren’t able to find them. Absence of a mention is not evidence of absence though. All we can say about these is that we simply don’t know what they support.
Before you compare datasheets…
If you go and read those pages yourself you will run into statements like “FIPS 140-3 everywhere”, often as the headline cryptographic claim for a 2026 release.
FIPS 140-3 is a validation that a cryptographic module is correctly built and correctly implements approved algorithms. It says literally nothing about quantum resistance, because the approved algorithms it validates are only the classical ones.
So the two properties are independent. A product can be FIPS 140-3 validated and still not at all quantum-secure.
The client’s role in all this
The client has to cooperate. A hybrid post-quantum key exchange requires both ends. Connect with an OpenSSH 8 client and you will get a classical exchange, because the alternative would be to refuse the connection.
To ensure older client software is supported, SFTP.cloud does also offer classical key-exchange algorithms, but hybrid post-quantum are always preferred when the client-side also supports them. And if your SFTP.cloud site runs on a Dedicated Tier instance, you can configure strict post-quantum resistance, refusing all classical-only algorithms outright (if you so wish).
Check it yourself, it only takes a minute
You do not have to take any of this from us. Against any SFTP endpoint, ours or your current one run this:
ssh -vvv -p 22 user@endpoint 2>&1 | grep -i “kex: algorithm”
If the answer contains mlkem or sntrup, that session was post-quantum. If it comes back with curve25519-sha256 or a diffie-hellman-group variant, it was not.
And for your FTPS, FTPES, or HTTPS endpoints, ask the TLS handshake which group it settled on. You just need OpenSSL 3.5 or later to run this:
openssl s_client -connect host:port -groups X25519MLKEM768 </dev/null 2>&1 | grep -i “group\|Negotiated”
Run it against us. Then run it against the MFT solution you use today.
Sources
AWS Transfer Family, post-quantum security policies and security policy algorithm reference
Files.com, post-quantum cryptography and published cipher list
SFTP.cloud terminates SFTP, FTPS, FTPES and HTTPS in front of storage you already own, without holding your storage credentials and without writing your files to our disks. How it works covers the architecture, and Security covers the threat model.