Post-quantum migration is reaching the administrative channels used to operate critical systems. RFC 10042 defines three post-quantum/traditional hybrid key-exchange methods for Secure Shell using ML-KEM combined with either NIST elliptic curves or X25519.
The RFC was published in August 2026, so it is older than the preferred 30-day news window. It remains operationally relevant because SSH estates are distributed across servers, endpoints, network devices, bastions, automation runners, deployment systems, and vendor access paths. A standard makes interoperable implementation possible; it does not show which of those pathways can use it today.
SSH is a relationship, not an installed package
An inventory that records an SSH server version without its clients cannot determine migration readiness. Key exchange is negotiated between two endpoints, and the path may include proxies or bastions that establish separate sessions. A modern server may still receive classical connections from an older workstation, embedded appliance, script runner, or supplier tool.
For each important administrative path, teams should capture:
- client, server, bastion, proxy, and accountable owners;
- software and firmware versions plus configuration source;
- key-exchange methods supported, permitted, preferred, and observed;
- host-key and user-authentication algorithms as separate properties;
- automation, break-glass, recovery, and vendor-access dependencies;
- cryptographic module or validation constraints;
- evidence source, observation period, and excluded populations; and
- target state, test result, exception, and closure evidence.
This relationship model prevents a server-side capability from being reported as complete coverage.
Three standardized names require precision
RFC 10042 specifies mlkem768nistp256-sha256, mlkem1024nistp384-sha384, and mlkem768x25519-sha256. Those exact identifiers matter. “ML-KEM supported” does not reveal the parameter set, classical component, negotiation preference, or actual result.
Policy should state which methods are approved for which populations and whether classical-only fallback remains permitted. Observation should then confirm what production sessions choose. Supported, configured, preferred, and negotiated are four different facts.
Key exchange does not migrate authentication
The new methods protect SSH key establishment using a hybrid of post-quantum and traditional cryptography. They do not by themselves make host keys or user authentication post-quantum. A session can use hybrid key exchange while still relying on an RSA or elliptic-curve signature to authenticate the server or user.
That can be a valuable intermediate state, especially for reducing harvest-now-decrypt-later exposure. Reporting should preserve the distinction. A single “PQC enabled” field can hide classical identity dependencies and create an inaccurate completion claim.
Automation may be the slowest client
Interactive administrator workstations are visible and often updated regularly. Automation can be harder: CI runners, configuration-management nodes, backup systems, monitoring collectors, scheduled transfers, and recovery tooling may pin libraries, algorithms, or container images for long periods.
Teams should identify nonhuman SSH clients and test them as first-class migration populations. A change that works for an engineer’s laptop but breaks backup retrieval or emergency recovery is not ready. Conversely, retaining classical methods globally for one unknown script creates an avoidable exception.
Performance and message size need path-level tests
The RFC discusses message size and defines the mechanics for combining the traditional and post-quantum shared secrets. Real deployments still need to test latency, CPU, memory, cryptographic modules, intermediaries, logging, failure behavior, and interoperability for their endpoint combinations.
A pilot should state the exact clients, servers, algorithms, configurations, authentication methods, and network paths exercised. It should include upgrade and rollback behavior, then re-observe negotiated production sessions after change. A laboratory handshake proves a combination can work; it does not prove every administrative path uses it.
What organizations should do next
First, map privileged SSH relationships, including bastions, network devices, automation, vendor access, recovery environments, and dormant but authorized paths.
Second, collect supported and configured key-exchange methods from both endpoints, then compare them with observed negotiation.
Third, separate the key-establishment milestone from host and user authentication. Track both without overstating partial progress.
Fourth, group incompatible populations by remediation path: upgrade, configuration change, replacement, supplier dependency, or time-bound exception.
Finally, define completion as sustained observed coverage for the intended population, with explicit evidence for any excluded path.
How Vista Platform helps
Vista Platform is a self-hosted cryptographic system of record. Its operating loop—discovery, canonical inventory, evaluation, action, and proof—helps organizations relate cryptographic observations to assets, administrative connections, owners, policies, remediation, and evidence.
Vista Platform Core is free of charge and includes discovery, inventory, compliance and PQC assessment, and CBOM generation without asset, sensor, seat, or time caps. Vista tracks and governs post-quantum migration; it does not generate PQC keys or perform every migration. Selected-asset Active Scan is targeted, not indiscriminate network scanning. Vista is not a vulnerability scanner, and incomplete observation is not proof of absence.
Learn more about Vista’s post-quantum migration and cryptographic inventory approach.
Where uncertainty remains
RFC 10042 standardizes key-exchange methods; it does not mandate deployment, enumerate product support, or establish organization-specific policy. Implementation maturity, cryptographic validation, endpoint compatibility, and authentication roadmaps vary. The standard is a concrete target, but organizations still need relationship-level evidence to know where it is deployable.
Source
- RFC 10042: Post-Quantum/Traditional Hybrid Key Exchange with ML-KEM for Use in SSH, RFC Editor / IETF, August 2026.