Post-Quantum SSH: What RFC 10042 Standardizes

RFC 10042 gives SSH implementers a published specification for three post-quantum/traditional hybrid key-exchange methods. The IETF published it in August 2026 as an Informational RFC, not as a Standards Track RFC or an Internet Standard.

The scope is deliberately narrow. RFC 10042 protects the establishment of SSH session keys by combining ML-KEM with a classical elliptic-curve exchange. It does not define post-quantum host keys, user keys or SSH signatures. A connection that negotiates one of these methods can have hybrid post-quantum key establishment while still authenticating the server and user with classical signatures.

For the wider engineering rationale, see Hybrid Cryptography Explained. This guide focuses on what the SSH specification changes and how migration teams should validate it.

What RFC 10042 standardizes

RFC 10042 defines a hybrid exchange in the SSH transport layer. The client contributes an ephemeral ML-KEM encapsulation key and an ephemeral classical ECDH public key. The server returns an ML-KEM ciphertext and its ephemeral classical ECDH public key. Both parties derive a post-quantum secret and a classical secret, then compute:

K = HASH(K_PQ || K_CL)

That shared secret enters SSH’s existing key-derivation process. The exchange is hybrid because the security of the session-key establishment is not placed entirely on either ML-KEM or the classical curve.

The RFC also specifies:

SSH message numbers 30 and 31 for the hybrid exchange;
the order and fixed-length encoding of the two public contributions;
public-key, ciphertext and length validation;
failure behavior for invalid exchanges;
fresh ephemeral ML-KEM and ECDH keys per connection;
three registered SSH key-exchange method names.

The IANA registry marks all three methods SHOULD in its “OK to Implement” column. That is implementation guidance within the SSH registry. It does not make RFC 10042 mandatory for every SSH product or deployment.

The three exact KEX method names

SSH key-exchange method	ML-KEM component	Classical component	Exchange hash
`mlkem768nistp256-sha256`	ML-KEM-768	ECDH over NIST P-256 (`ecdh-sha2-nistp256`)	SHA-256
`mlkem1024nistp384-sha384`	ML-KEM-1024	ECDH over NIST P-384 (`ecdh-sha2-nistp384`)	SHA-384
`mlkem768x25519-sha256`	ML-KEM-768	X25519 (`curve25519-sha256`)	SHA-256

These identifiers are protocol names and must be copied exactly. The spelling, parameter level, curve and hash function are part of the negotiated method.

For all three methods, the client sends the ML-KEM encapsulation key before the classical public key. The server likewise sends the ML-KEM ciphertext before its classical public key. Implementers should follow the byte layout in RFC 10042 rather than infer an encoding order from the method name.

The ML-KEM and classical shared secrets are fixed-length byte arrays before combination. The classical contribution is 32 bytes for X25519 and P-256, or 48 bytes for P-384. The RFC requires validation before encapsulation or decapsulation and requires a failed exchange to terminate rather than silently continue with only one component.

Informational does not mean experimental

RFC 10042 is a published IETF RFC approved by the IESG, and its method names are registered for SSH. It is also explicitly not an Internet Standards Track specification.

Those facts can coexist:

Published RFC: the document has completed RFC publication;
Informational: its RFC status is not Standards Track;
Registered methods: SSH implementations can negotiate the exact names;
Not mandatory: the RFC does not require universal implementation or deployment;
Not universal support: each client and server version still needs evidence.

The former draft-ietf-sshm-mlkem-hybrid-kex is useful for standards chronology. Current technical and procurement references should point to RFC 10042 rather than describe the methods as an active Internet-Draft.

Why hybrid rather than ML-KEM alone

The construction retains a classical ECDH exchange while adding ML-KEM. This limits the migration from depending solely on a newer post-quantum primitive while also addressing the future quantum risk to the classical exchange.

Hybrid does not remove implementation risk. Random-number generation, validation, negotiation, secret handling and the surrounding SSH state machine still matter. RFC 10042 requires fresh ephemeral key pairs per connection and prohibits reuse of randomness when producing ML-KEM ciphertexts.

Do not copy its combiner into another protocol. The method is specified with SSH’s exchange hash and key-derivation behavior. TLS uses a different protocol construction, covered separately by RFC 10024 for hybrid ML-KEM in TLS 1.3.

What RFC 10042 does not cover

RFC 10042 does not standardize:

post-quantum SSH host authentication;
post-quantum SSH user authentication;
ML-DSA host or user keys for SSH;
composite SSH signatures;
certificate-authority migration for SSH host certificates;
automatic enablement in every SSH implementation;
a complete end-to-end SSH migration profile.

This distinction matters operationally. Key exchange creates session secrets. Authentication proves which host and user are participating. A team that enables mlkem768x25519-sha256 but retains Ed25519, ECDSA or RSA authentication has improved key establishment without making the authentication layer post-quantum.

Verified implementation status

RFC publication and software support are separate maturity facts.

Implementation	Verified ML-KEM hybrid SSH support	Practical interpretation
OpenSSH 9.9 and later	`mlkem768x25519-sha256` is available by default from 9.9; OpenSSH 10.0 made it the default key agreement	Do not infer release support for both NIST-curve methods from RFC publication
PuTTY 0.83 and later	PuTTY’s official change record says it implements ML-KEM hybrid forms with Curve25519 and the two NIST elliptic curves	Confirm the exact installed PuTTY version and server-side overlap

The current OpenSSH source tree contains additional RFC method work, but source-tree presence is not a fleet deployment guarantee. Migration records should name the released client and server versions actually tested.

This page does not label libssh, wolfSSH, Dropbear or other libraries as supported or unsupported without current first-party, release-specific evidence. Absence from this table means “not verified in this review,” not “not implemented.”

Negotiation, compatibility and downgrade checks

SSH peers exchange ordered key-exchange algorithm lists and select the first mutually supported method according to SSH negotiation rules. A modern client offering an RFC 10042 method can still connect classically when the server does not offer the same method.

That fallback is useful for compatibility but must be visible in migration evidence. Merely configuring a hybrid method on one side does not prove it was selected. Record the negotiated KEX method from a real connection.

Test at least:

a client and server that share the intended RFC 10042 method;
a classical-only peer and the documented fallback outcome;
policy behavior when hybrid key exchange is required but unavailable;
rekeying during long-lived SSH sessions;
malformed or incorrectly sized hybrid messages;
logging and telemetry for the selected method;
bastions, proxies, automation tools and embedded SSH libraries;
rollback without weakening unrelated SSH controls.

Do not describe a failed hybrid negotiation followed by a classical connection as hybrid protection. It is a classical session and should be recorded as such.

Migration checklist

Add SSH transport key exchange as its own row in the cryptographic inventory.
Separate SSH KEX from host-key and user-key authentication in the inventory.
Record client, server, appliance and library versions.
Record the exact method offered and the method actually negotiated.
Test mlkem768x25519-sha256 where both released implementations document support.
Evaluate the NIST-curve methods only where the selected implementations and policy require them.
Retain a controlled classical fallback until the compatibility decision says otherwise.
Define whether hybrid KEX is preferred or required for each connection class.
Test bastions, SFTP automation, CI/CD, network equipment and managed SSH endpoints.
Keep PQ host and user authentication as a separate standards watch item.
Store evidence, owner and rollback criteria in the PQC migration plan template.

The post-quantum migration checklist places this SSH work alongside TLS, VPN, PKI, code-signing and KMS migration. Use Crypto Agility Explained to design configuration and rollback so the chosen KEX method can change without an application rewrite.

Practical verdict

RFC 10042 replaces draft-only status with a published Informational reference for three ML-KEM hybrid SSH key exchanges. That is a meaningful standards maturity change, especially for procurement language, interoperability profiles and migration evidence.

It is not a declaration that SSH is fully post-quantum or that every implementation is ready. Adopt it capability by capability: verify a released client/server pair, observe the negotiated method, preserve controlled fallback, and keep host and user authentication on a separate migration track.

FAQ

Is RFC 10042 an Internet Standard?

No. It is a published Informational RFC. It is not an Internet Standards Track specification.

Which RFC 10042 method does OpenSSH deploy by default?

OpenSSH made mlkem768x25519-sha256 available by default in version 9.9 and the default key agreement in version 10.0. That does not prove support for the other two RFC methods in every OpenSSH release.

Does hybrid ML-KEM KEX replace SSH host keys?

No. The KEX establishes session secrets. Host keys authenticate the server through a separate signature operation.

Is an SSH session fully post-quantum after hybrid KEX?

No. Its key establishment may be hybrid post-quantum, while host and user authentication remain classical. Deployment, endpoint and fallback coverage also need verification.

Must every SSH implementation support these methods?

No. IANA marks the methods SHOULD in its implementation guidance, but RFC 10042 is Informational and does not create universal deployment.