Post-Quantum Cryptography for SFTP and MFT | SFTP To Go

Post-quantum cryptography is already changing SFTP

An SFTP transfer may be over almost instantly. The data it carries, however, may need to stay confidential for years.

That creates a future problem worth dealing with now.

An attacker could capture encrypted SSH traffic they can’t read today and simply keep it. If sufficiently powerful quantum computers eventually become capable of breaking the public-key cryptography used to establish those sessions, old captured traffic could become useful again.

This is the harvest now, decrypt later problem, and it’s one reason the security industry isn’t waiting for quantum computers to become an immediate threat before changing cryptography. OpenSSH specifically identifies recorded SSH sessions as being exposed to this kind of future attack when quantum-vulnerable key agreement is used.

SFTP To Go is already operating endpoints where mlkem768x25519-sha256 is the default SSH key-agreement method. For compatible clients, this combines ML-KEM with X25519, adding post-quantum protection to the part of the SSH connection that establishes the session secret.

The rest of SSH doesn’t change all at once. Authentication keys, digital signatures and other cryptographic functions are separate parts of the protocol, and each will move toward post-quantum alternatives on its own timeline.

What exactly could quantum computing change?

Importantly, quantum computing is by no means expected to make SFTP obsolete. SFTP runs over SSH, and SSH uses several types of cryptography to authenticate connections, agree on session keys and protect traffic.

The main concern is actually public-key cryptography. A sufficiently capable quantum computer could eventually undermine widely used public-key systems based on mathematical problems that are difficult for conventional computers but vulnerable to quantum algorithms.

For SSH, two areas need to evolve: key agreement and digital signatures. OpenSSH identifies both as potentially vulnerable to a cryptographically relevant quantum computer.

Key agreement is receiving attention first because it protects the confidentiality of an SSH session. If an attacker records that session today and can break its key agreement later, they may be able to recover the encrypted traffic.

That’s the connection between post-quantum cryptography and SFTP, and it’s something we’re prepared for.

Post-quantum cryptography is no longer just research

In August 2024, NIST finalized its first three post-quantum cryptography standards.

They include ML-KEM for establishing shared secrets and ML-DSA and SLH-DSA for digital signatures. NIST is encouraging organizations to begin preparing for migration rather than wait until quantum attacks become a present threat.

SSH has already started moving in the same direction.

OpenSSH has included hybrid post-quantum key agreement by default since version 9.0. Version 9.9 added `mlkem768x25519-sha256`, and OpenSSH 10.0 made it the default key-agreement method.

So, while useful quantum computers may still be some way off in the public (and cyber-criminal) sectors, post-quantum SSH is already here.

Why hybrid cryptography works well for SFTP

The word hybrid is an important part of this.

OpenSSH’s `mlkem768x25519-sha256` combines the post-quantum ML-KEM algorithm with X25519, an established classical key-agreement method. OpenSSH designed the approach so that discovering a weakness in the newer post-quantum component shouldn’t leave the connection weaker than the classical component on its own.

That gives SFTP a practical route into post-quantum security without demanding an overnight switch. Needless to say, an overnight switch would be unrealistic.

MFT environments can include new OpenSSH clients alongside older scripts, desktop applications, ERP connections, libraries and embedded systems that have been transferring files reliably for years. 

New cryptography has to improve security without breaking those connections in the process. NIST’s own PQC migration work puts considerable emphasis on interoperability for exactly this reason: standardized algorithms still have to work across the systems and software organizations already depend on.

What SFTP To Go is doing now

Our phased rollout of post-quantum-capable endpoints allows us to work through the transition in deployed, highly active environments while gradually expanding support and testing compatibility with the clients and integrations our customers rely on. Not as glamorous as talking about quantum computers, but considerably more useful.

This is worth doing before post-quantum support becomes a procurement requirement or a security checkpoint.

For SFTP To Go, this is also a natural part of running compliance-focused managed file-transfer infrastructure. Customers use the service so they don’t have to operate and continually modernize their own SFTP servers. It massively cuts down on effort, and it has major security and compliance pros.

PQC is another change the infrastructure needs to be ready for.

What post-quantum cryptography doesn’t change

“Quantum computers can break encryption” is a convenient headline but it smells a little like clickbait because it makes the threat sound universal. It isn’t! The biggest quantum threat is to certain forms of public-key cryptography. Symmetric encryption is affected differently.

SFTP To Go encrypts stored data using AES-256. NIST’s current guidance continues to support AES for existing applications, with stronger AES key sizes retaining substantial security against known quantum attacks. AES-256 is still considered suitable in a post-quantum context, so post-quantum cryptography does not mean replacing the AES-256 encryption protecting files stored in SFTP To Go.

For SFTP, the more immediate concern is SSH key agreement. That’s the process used to establish the encrypted session, and it is where the harvest-now-decrypt-later risk comes in.

There is another distinction worth noting. The SSH public key you add to an SFTP To Go credential is used for authentication. It proves that the connecting client is authorized to log in. It’s not the same thing as the key-agreement process used to establish the encrypted session!

SFTP To Go currently accepts RSA, ECDSA and Ed25519 keys for public-key authentication. Those authentication methods have their own post-quantum transition ahead, but that’s separate from the key-agreement changes already being introduced to protect SSH sessions against future decryption. Hybrid post-quantum key exchange protects session confidentiality, but it does not make SSH authentication post-quantum secure.

Do customers need to do anything now?

There’s no reason to tear apart a working SFTP integration because quantum computers may become a threat in the future. Keeping SSH clients and libraries current is sensible. Newer versions are where post-quantum capabilities are appearing first.

It’s also useful to know where older SSH implementations are hiding in your environment and which transferred data needs to remain confidential for many years. Cryptographic inventories are one of the areas NIST is examining as organizations prepare for PQC migration.

Older clients may eventually need updating. No managed service can make decades-old software understand a cryptographic method it was never designed to support. What SFTP To Go can do is prepare the managed infrastructure early, test the transition properly and avoid leaving that work until everyone is suddenly in a desperate hurry.

Preparing while we have the luxury of time

There is no publicly known cryptographically relevant quantum computer capable of breaking today’s widely deployed public-key cryptography.

There’s no immediate quantum threat to SFTP To Go customers, and there’s no urgent migration for customers to perform. We’re starting early precisely so that, as post-quantum cryptography becomes standard, the transition can be controlled, tested and as uneventful as possible.

There’s no reason to disrupt working integrations today. However, teams should begin preparing by checking whether their SSH clients and integrations support post-quantum cryptography and testing compatibility where possible.

You see, we already know enough to start preparing. Post-quantum cryptography standards now exist. ML-KEM has been standardized for key establishment. OpenSSH has already made hybrid post-quantum key agreement its default.

SFTP To Go isn’t waiting either. We’ve already deployed post-quantum-capable endpoints and are gradually expanding support across our infrastructure.

That doesn’t mean every SFTP To Go connection uses post-quantum cryptography today. We are taking a phased approach to implementation to account for the broader ecosystem, where many legacy clients and third-party integrations do not yet support post-quantum cryptography, ensuring a seamless transition without disrupting operational workflows.

If your team is already preparing SSH clients or integrations for post-quantum cryptography, we’d like to hear from you. Get in touch with us to discuss your environment, client compatibility, and opportunities to test post-quantum SSH connections with SFTP To Go.

Frequently asked questions