TL;DR: SSH is moving toward post-quantum key exchange through hybrid algorithms such as mlkem768x25519-sha256, but support still varies across OpenSSH versions and Linux distributions, according to Cybertrust Japan. The transition is now a practical migration issue, because store now, decrypt later risk applies to long-lived SSH traffic as well as web and API sessions.
At a glance
What this is: This is a Cybertrust Japan analysis of SSH post-quantum key exchange, showing that hybrid KEX is already available in some OpenSSH builds but not uniformly across operating systems and client versions.
Why it matters: It matters because SSH protects administrative access and file transfer paths, so uneven PQC support creates a migration gap where long-lived traffic may remain vulnerable to harvest-now, decrypt-later collection.
Context
SSH is the remote administration workhorse for servers, appliances and developer systems, which makes its key exchange path a governance issue rather than a narrow crypto detail. When a protocol carries long-lived operational traffic, partial support for post-quantum algorithms creates an uneven protection model across fleets, especially where mixed Linux and client versions coexist.
The article frames that gap through the hybrid transition pattern: current classical cryptography is paired with a post-quantum component so that either side can preserve confidentiality during migration. For identity and access teams, the intersection is clear because SSH keys and sessions are part of privileged access, workload administration and machine identity operations, all of which need version-aware control.
Cybertrust Japan’s examples show that the starting position is already common in enterprise environments: some endpoints negotiate the hybrid algorithm, others silently fall back to classical Curve25519. That is typical of a transition phase, not an endpoint.
Key questions
Q: What breaks when SSH endpoints cannot negotiate post-quantum key exchange?
A: The control breaks at negotiation time, because support on one endpoint does not guarantee hybrid protection if the peer lacks the algorithm or policy allows fallback. The result is a classical session that still works operationally but no longer resists future quantum decryption. Practitioners should verify the negotiated cipher suite, not assume PQC from package versions alone.
Q: When should organisations prioritise post-quantum SSH over other crypto upgrades?
A: Prioritise SSH where sessions protect privileged administration, file transfer, or long-lived operational access, because those connections can be high-value targets for harvest-now, decrypt-later collection. If your environment still depends on classical negotiation for those paths, the migration case is stronger than for short-lived, low-sensitivity traffic.
Q: How do security teams know SSH post-quantum controls are actually working?
A: They know it is working when representative client-server pairs consistently negotiate the hybrid algorithm and no critical paths fall back to classical Curve25519 or older KEX options. The key indicator is the handshake result, supported by version inventories and policy validation. Anything less leaves a hidden downgrade path.
Q: What is the difference between hybrid SSH key exchange and classical SSH key exchange?
A: Hybrid SSH key exchange combines a post-quantum algorithm with a classical elliptic-curve method so that both must be broken to recover the session secret. Classical SSH key exchange relies on one cryptographic scheme, which is still operationally secure today but offers no post-quantum hedge against future decryption capability.
Technical breakdown
How SSH hybrid key exchange works
SSH key exchange negotiates a shared session key before any authentication or data transfer completes. In the hybrid model shown here, the protocol combines a post-quantum mechanism such as ML-KEM-768 with Curve25519, then derives one final session key from both outputs. That means an attacker would need to break both components to recover the session secret. The design is a migration pattern, not a wholesale replacement, because it preserves compatibility with deployed OpenSSH stacks while introducing post-quantum protection where both peers support it.
Practical implication: Track which SSH clients and servers actually negotiate the hybrid KEX, not just which versions are installed.
Why version skew changes the negotiated algorithm
SSH does not use a single global setting by default. The negotiated algorithm is chosen from the intersection of the client and server proposals, so support on one side does not guarantee use in practice. The article’s examples show exactly that: a newer server can advertise mlkem768x25519-sha256, but an older client can still force a classical fallback if it lacks the hybrid option. That makes fleet variability the core technical barrier to PQC adoption, especially in mixed Linux and workstation estates.
Practical implication: Inventory client and server versions together, because asymmetric support can silently erase your post-quantum posture.
Why fallback is the real migration risk for ssh sessions
Fallback matters because the security value of PQC only exists when the negotiated session actually uses it. If the connection drops to classical Curve25519, the session regains its current confidentiality properties but loses resistance to future quantum decryption. For SSH, that is operationally relevant because administration sessions, file transfers and embedded device access often live longer than a single interactive login. The migration problem is therefore not abstract crypto readiness, but enforcing acceptable negotiation outcomes across real endpoints and policy files.
Practical implication: Set policy and monitoring around the negotiated KEX result, not just around package presence or upgrade status.
Threat narrative
Attacker objective: The attacker wants to preserve intercepted SSH traffic until quantum capability or weaker negotiation paths make decryption possible.
- Entry occurs when an attacker captures SSH traffic or logs for later analysis, banking on future quantum capability rather than immediate decryption.
- Credential or session secrecy is threatened if the negotiated key exchange remains classical instead of hybrid post-quantum protection.
- Impact emerges later when archived SSH sessions can be decrypted and administrative or transfer content exposed.
Breaches seen in the wild
- Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.
- CISA Private-CISA GitHub leak 2026: A CISA contractor's public GitHub repo exposed AWS GovCloud admin keys, Artifactory credentials and plaintext passwords for six months.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Hybrid SSH is a transition control, not a finished control: the article shows that post-quantum key exchange only changes security outcomes when both endpoints support it and the negotiated result is actually hybrid. That makes SSH a version-governed control surface, not a binary yes-no feature. Practitioners should treat negotiated KEX as the control evidence, not package installation alone.
Store-now, decrypt-later turns SSH into a long-horizon confidentiality problem: administrative sessions and file transfers often carry material access data, configuration details and operational secrets. If those sessions are captured today and remain classical, their value may increase later rather than decay. This is why PQC readiness belongs in privileged access and workload administration planning, not only in cryptography roadmaps.
SSH posture will increasingly depend on fleet consistency: mixed OpenSSH versions, distribution defaults and client tools create silent downgrade paths even when a server advertises post-quantum support. That means the governance challenge is discovery, normalization and enforcement across endpoints. The practitioner conclusion is simple: if you cannot explain which peers actually negotiate hybrid KEX, you do not yet control the migration.
Post-quantum SSH exposes an NHI governance intersection: SSH sessions are a form of machine and operator access that often underpin service administration, automation and cross-system trust. Once those sessions are part of the NHI and privileged access fabric, hybrid key exchange becomes part of identity assurance, because transport confidentiality protects the credentials, commands and data that identity systems rely on.
Named concept, hybrid negotiation drift: the article illustrates a specific migration failure mode where policy enables post-quantum algorithms but endpoints still drift to classical negotiation because of version mismatch. That drift is easy to miss if teams watch configuration intent rather than actual handshake telemetry. The conclusion for practitioners is to measure the negotiated outcome, not the intended one.
What this signals
Hybrid negotiation drift: migration programmes will increasingly fail not because post-quantum algorithms are unavailable, but because the fleet does not negotiate them consistently. That shifts governance from design intent to handshake verification, which is a better fit for privileged access control and machine identity operations.
SSH should now be treated as part of the broader crypto-agility agenda, where the important question is whether endpoints can change cryptographic posture without breaking operational trust. For identity teams, that means the access path itself becomes a policy object, not just the credentials carried over it.
For practitioners
- Audit negotiated SSH key exchange, not just installed versions Collect handshake logs from representative clients and servers, then confirm that mlkem768x25519-sha256 is actually selected where policy expects it. Version presence alone is not proof of post-quantum use.
- Standardise OpenSSH baselines across endpoints Align server and client packages across Linux distributions, macOS and Windows toolchains so that hybrid negotiation is available on both sides of the connection.
- Treat fallback as a risk signal Flag any SSH session that negotiates curve25519-sha256 or another classical KEX where hybrid support is expected, because that session remains exposed to future decryption.
- Use policy files to prefer hybrid KEX Review system crypto policy and SSH configuration inheritance so that hybrid algorithms appear first and are not suppressed by older defaults or local overrides.
Key takeaways
- SSH post-quantum readiness is no longer just a standards discussion, because hybrid key exchange is already appearing in production stacks while older clients still fall back to classical negotiation.
- The main exposure is not the presence of PQC code, but the gap between intended policy and the algorithm actually selected during the handshake.
- Practitioners need telemetry on negotiated SSH algorithms, version alignment across fleets, and a migration plan that removes silent downgrade paths.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-57, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-57 | Part 1 — Key Management Lifecycle | The article is about migrating cryptographic protection for SSH sessions and long-lived confidentiality. |
| Recommendation — Review key lifecycle governance so SSH transport protection can transition to post-quantum algorithms without breaking trust. | ||
| NIST CSF 2.0 | PR.DS-10 — Cryptography | SSH hybrid KEX is a cryptographic protection and crypto-agility issue across managed fleets. |
| PR.AA-05 — Access Permissions, Entitlements and Authorizations | SSH is privileged access infrastructure, so negotiated transport directly supports authorization workflows. | |
| Recommendation — Apply cryptography controls to ensure SSH sessions use approved algorithms and avoid silent classical fallback. Map SSH access paths to PR.AA-05 so privileged sessions inherit policy and monitoring expectations. | ||
| NIST SP 800-53 Rev 5 | SC-13 — Cryptographic Protection | The article centres on cryptographic protection of SSH traffic during the PQC transition. |
| IA-5 — Authenticator Management | SSH session security depends on managed authenticators and the rotation of access material around them. | |
| Recommendation — Use SC-13 to require approved cryptography for SSH and validate that hybrid negotiation is actually occurring. Tie SSH credential governance to IA-5 so deprecated algorithms and session controls are retired on schedule. | ||
| MITRE ATT&CK | TA0006 — Credential Access | Harvest-now, decrypt-later directly targets future access to intercepted session material. |
| Recommendation — Map SSH downgrade exposure to TA0006 and prioritise sessions carrying sensitive administrative traffic. | ||
Key terms
- Hybrid Key Exchange: A transitional cryptographic setup that supports both classical and post-quantum key exchange during session negotiation. It reduces compatibility risk while improving resilience, but it is not a final endpoint because the surrounding certificate and identity estate may still rely on quantum-vulnerable components.
- Harvest now, decrypt later: An attacker strategy where encrypted traffic or stored data is collected today and decrypted later when better computing power becomes available. It matters to NHI governance because machine identities often protect the data paths and secrets most worth preserving over time.
- Crypto-Agility: Crypto-agility is the ability to change cryptographic algorithms, certificates, and trust dependencies without redesigning production systems. It matters because cryptographic standards evolve, and organisations need accurate inventories and automated lifecycle controls before they can migrate safely.
- Session Key: A session key is a temporary encryption key used for one communication session between two systems. It is negotiated for that connection only, then discarded and replaced on the next session. This limits exposure if one session is intercepted, because the same key is not reused indefinitely.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and secrets management. It helps practitioners strengthen identity controls across the systems and sessions that carry privileged access.
Published by the NHIMG editorial team on July 10, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org