Post-quantum SSH and SFTP security refers to the hardening of the Secure Shell protocol and its file-transfer subsystem against attacks by future cryptographically relevant quantum computers, specifically by replacing classical Diffie-Hellman and elliptic-curve key exchange with ML-KEM (FIPS 203) key encapsulation and ML-DSA (FIPS 204) digital signatures, as defined in IETF draft-ietf-sshm-mlkem-ssh. For European organisations operating sovereign infrastructure in regulated sectors, this migration is not optional: it is a legally bounded obligation with a hard deadline.
Why SSH and SFTP Are Quantum-Vulnerable Right Now
Every SSH session established today using ECDH or classical Diffie-Hellman key exchange is potentially compromised by the harvest-now-decrypt-later threat. An adversary, including a state-level actor, can record encrypted SSH handshakes and bulk SFTP transfers in their entirety and store them until a quantum computer capable of running Shor’s algorithm becomes available. At that point, the recorded session keys can be reconstructed and the plaintext recovered.
SSH protocol version 2, the current standard, is not inherently quantum-safe. The security of its key exchange rests on the computational hardness of the discrete logarithm problem or elliptic curve discrete logarithm problem, both of which Shor’s algorithm solves efficiently on a large-scale quantum computer. RSA-4096 host keys and ECDSA authentication keys share the same vulnerability on the signature side. The confidentiality of administrative sessions, credential exchanges and bulk data transferred over SFTP is therefore contingent on quantum computers not becoming available, a contingency that security planners can no longer assume.
“Organisations should not wait for quantum computers to arrive before migrating to post-quantum cryptography. The time to act is now, because data harvested today can be decrypted tomorrow.”
Dustin Moody, Mathematician and PQC project lead, NIST Computer Security Division
IBM projects that a cryptographically relevant quantum computer capable of breaking RSA-2048 could emerge within the next decade (IBM Institute for Business Value, 2023). The average cost of a data breach already reached USD 4.45 million globally in 2023 (IBM Cost of a Data Breach Report, 2023). Combining those two data points: organisations that defer migration are accepting compounding financial and regulatory risk.
The Emerging Standard: IETF draft-ietf-sshm-mlkem-ssh and OpenSSH Support
The authoritative migration path for SSH is defined in IETF draft-ietf-sshm-mlkem-ssh, which specifies ML-KEM key exchange method identifiers for the SSH Transport Layer Protocol. The primary method name is mlkem768x25519-sha256, a hybrid construction that combines ML-KEM-768 (FIPS 203) with X25519 to ensure that security does not regress below classical levels if ML-KEM were somehow weakened.
OpenSSH introduced experimental support for this hybrid key exchange beginning with version 9.0 (released 2022), tracking the IETF draft. Server administrators can enable it by adding mlkem768x25519-sha256 to the KexAlgorithms directive in sshd_config. Client-side, the same method must appear in the client’s KexAlgorithms list. Both sides negotiate the strongest mutually supported algorithm, which means adding the post-quantum method does not break sessions with legacy clients: those sessions fall back to the next shared classical algorithm. This property is the foundation of any non-disruptive migration strategy.
Interoperability across the ecosystem remains uneven. PuTTY, the dominant SSH client in Windows-based regulated environments, had not yet merged ML-KEM support as of early 2025 and organisations relying on it for administrative access face a gap. WinSCP and FileZilla Server, common in SFTP pipeline contexts, depend on their underlying SSH library versions. Paramiko, the Python SSH library widely used in automated batch jobs, requires explicit configuration to enable the new key exchange. Any migration inventory must map each client and library, not just the server daemon.
Migrating SFTP Pipelines Without Breaking Integrations
SFTP pipelines in regulated organisations are rarely simple. They include nightly backup agents pushing encrypted archives to off-site vaults, inter-system data feeds between ERP platforms and data lakes, and automated compliance reporting jobs triggered by schedulers. Each of these has a hardcoded key exchange preference list, often implicitly defaulting to whatever the SSH library compiled in years ago.
A structured migration approach has four phases. First, discovery: enumerate every automated process that initiates or accepts an SSH or SFTP connection, including service accounts, cron jobs, CI/CD pipeline steps and monitoring agents. Second, capability assessment: determine which server and client versions in that inventory already support mlkem768x25519-sha256 and which require upgrades. Third, parallel enablement: add the post-quantum algorithm to the preference list on servers first, without removing classical algorithms. Sessions from upgraded clients will negotiate ML-KEM automatically; sessions from legacy clients continue uninterrupted. Fourth, classical deprecation: once all clients are confirmed capable, remove classical-only key exchange from the server’s permitted list and enforce audit logging of the negotiated algorithm.
Host Key Migration: RSA-4096 and ECDSA to ML-DSA
Key exchange and host authentication are separate concerns. Even after ML-KEM key exchange is in place, server identity is still authenticated using the host key, typically RSA-4096 or ECDSA. These remain quantum-vulnerable to forgery. FIPS 204 standardises ML-DSA (Module-Lattice-Based Digital Signature Algorithm) as the post-quantum replacement.
| Algorithm | Security Level | Signature Size | Public Key Size | Quantum-Safe |
|---|---|---|---|---|
| RSA-4096 | ~140-bit classical | 512 bytes | 512 bytes | No |
| ECDSA P-256 | 128-bit classical | ~72 bytes | 65 bytes | No |
| ML-DSA-65 (FIPS 204) | NIST Level 3 | ~3,293 bytes | ~1,952 bytes | Yes |
The roughly six-fold increase in ML-DSA signature size relative to RSA-4096 has two practical consequences. SSH known_hosts files and trust stores will grow in size, which matters for large fleet management tools that distribute host key fingerprints. For high-frequency SFTP sessions (thousands per hour), the authentication handshake overhead increases, but because the handshake is a negligible fraction of total session data for bulk file transfers, the real-world throughput impact is small. Capacity planning should nonetheless benchmark authentication rates on gateway hardware before completing the migration.
The Binding Migration Timeline: NIS-2, EU PQC Roadmap and NIST IR 8547
Three regulatory instruments converge on the same deadline and create a legally binding obligation for SSH and SFTP in regulated European sectors.
NIS-2 (Directive EU 2022/2555), Article 21, requires essential and important entities to implement state-of-the-art cryptographic measures as part of their risk management. “State of the art” is a living standard: as NIST-approved post-quantum algorithms become available, retaining classical-only cryptography in production systems is progressively harder to justify to national supervisory authorities.
NIST IR 8547 (initial public draft, 2024) sets 2030 as the latest date by which RSA and ECDSA should be deprecated for federal and critical-infrastructure systems. Because NIST standards are referenced in EU technical guidance and procurement specifications, this deadline has de facto relevance for European regulated organisations even absent a direct legal mandate.
The EU NIS Cooperation Group PQC Transition Roadmap, published in coordination with ENISA, targets 2030 as the completion date for post-quantum migration across critical infrastructure sectors. Completion by 2030 implies that planning, inventory, piloting and phased rollout must be underway now, given typical procurement and certification cycles in public sector and financial services environments.
“Critical infrastructure operators must treat cryptographic agility as a core security requirement, not a future aspiration. The NIS-2 obligations on cryptography are legally binding today.”
ENISA, European Union Agency for Cybersecurity, NIS-2 implementation guidance
Audit Evidence and SIEM Integration for Sovereign Infrastructure
Demonstrating compliance to a data protection authority or NIS-2 supervisory body requires more than having ML-KEM configured: it requires evidence that the configuration is enforced and that classical fallback does not occur in practice. This evidence must come from structured logs ingested into a sovereign SIEM.
Each SSH and SFTP session log record must contain the negotiated key exchange algorithm name (such as mlkem768x25519-sha256), the host key type and fingerprint, client and server software version strings, session start and end timestamps with timezone offset, the authenticated user identity, the source IP address, and the authentication outcome. OpenSSH’s verbose logging (LogLevel VERBOSE or DEBUG in sshd_config) surfaces the negotiated algorithm in syslog output, which can then be forwarded to a sovereign SIEM such as a self-hosted Wazuh or Elastic Stack deployment.
A SIEM detection rule should alert on any SSH session where the negotiated key exchange algorithm does not match the approved post-quantum list. This is the technical control that converts a configuration policy into a continuously verified and auditable state. For forensic readiness, log retention must align with NIS-2 incident reporting obligations and any sector-specific requirements (for example, DORA’s five-year ICT incident documentation requirement for financial entities).
FAQ
Is SSH version 2 with ECDH quantum-safe?
No. SSH version 2 with elliptic-curve Diffie-Hellman or classical Diffie-Hellman key exchange is vulnerable to a cryptographically relevant quantum computer. Only ML-KEM-based key exchange as defined in IETF draft-ietf-sshm-mlkem-ssh provides post-quantum security for the SSH handshake.
Which version of OpenSSH first supports ML-KEM key exchange?
OpenSSH 9.0 introduced the hybrid mlkem768x25519-sha256 key exchange method as an experimental feature. Organisations should verify that both the server and client are built against a libcrypto or built-in implementation that supports FIPS 203 ML-KEM, and should monitor OpenSSH release notes as the IETF draft progresses to RFC status.
Does the 2030 deadline mean we have until 2030 to start planning?
No. The EU NIS Cooperation Group PQC Transition Roadmap and NIST IR 8547 both treat 2030 as the completion deadline, not the start. Given the lead times for inventory, testing, phased rollout across SFTP pipelines and audit documentation, organisations in regulated sectors should begin migration assessments immediately and aim to complete high-risk systems well before 2030.
How much larger are ML-DSA host key signatures compared with RSA-4096 signatures?
ML-DSA at the ML-DSA-65 security level produces signatures of approximately 3,293 bytes, compared with 512 bytes for RSA-4096: roughly a six-fold increase. For bulk SFTP transfers the authentication handshake is a small fraction of total session data, so throughput impact is minimal, but high-frequency automated sessions warrant benchmarking before full rollout.
What log fields must appear in SIEM records to satisfy a DPA audit on quantum-safe SSH?
Audit records must include: the negotiated key exchange algorithm name, the host key type and fingerprint, client and server software version strings, session start and end timestamps with timezone, the authenticated user identity, the source IP address, and the authentication outcome. These fields allow a supervisory authority to confirm that no classical-only key exchange was accepted and that the cryptographic posture matches the organisation’s stated security policy.
Hoe Qsentinel dit oplost
Qsentinel is the managed Nextcloud Enterprise workspace, enhanced by Qsentinel with post-quantum encryption and sovereign private AI, hosted in Switzerland or on-premise, out of reach of the CLOUD Act.