Separate the cryptographic jobs
Key establishment and digital signatures have different jobs. NIST's published standards include ML-KEM for key establishment and ML-DSA and SLH-DSA for signatures. Selecting a standard therefore settles only part of the design. The library, protocol integration and deployed product still need to support the intended use.
Inventory the negotiated protocols, certificate and signature formats, libraries, hardware and retention requirements. Include supplier-operated systems. With that information, ask the vendor for a supported migration path and evidence that it works with the actual peers. Describing a product as quantum-safe does not answer these implementation questions.
Illustrative case: two different migration priorities
Suppose a company retains confidential design files for fifteen years and also operates a portal with short-lived session data. The design-file exchange deserves early investigation because disclosure would remain consequential long after the exchange. The portal still needs a plan. Its certificates, signing keys and shared libraries may support uses with different lifetimes from the session data.
Pilot the design-file exchange with its actual counterparties before changing production. Check supported client versions and record whether they interoperate. The reason for doing this work is the information's lifetime together with the lead time for replacing its dependencies. It does not require a prediction about when a cryptographically relevant quantum computer will exist.
Turning the inventory into a migration decision
Different uses may be ready for different next steps. One can enter a pilot, another may need a supplier update, and a third may be deferred until a stated condition changes. Record the reason, required information lifetime and compatibility evidence for each decision. A single readiness score would conceal the work still required.
| Decision field | Evidence to capture |
|---|---|
| Protected function | Confidential exchange, signature verification or another exact use |
| Required lifetime | The period for which confidentiality or authenticity must remain useful |
| Dependencies | Protocol, library, device, certificate system and external peer |
| Supported change | The supported vendor version, configuration and documented compatibility |
| Pilot acceptance | Observed successful exchange, failure behavior, message size and latency |
| Decision | Pilot now, resolve the named dependency, or defer with an owner and review trigger |
Test compatibility and limits
Specify what should happen when a peer does not support the new configuration. A connection that completes through an undocumented fallback does not establish that the intended migration occurred. Observe message size, handshake behavior, CPU cost and troubleshooting requirements under realistic network conditions. Compatibility includes the failure behavior as well as the successful exchange.
Make cryptographic agility concrete: identify the configuration or software change that replaces an algorithm, who can authorize it and how consumers receive the new trust configuration. These are migration decisions. They do not constitute a cryptographic evaluation or establish resistance to every quantum attack. Implementation still requires the current NIST standards and support information for the exact product.
Record the algorithms actually used
An endpoint's capability list says what it supports. It does not tell us what a particular connection selected. Record the endpoint versions, negotiated key exchange, host-authentication signature, trust check and user-authentication method. Keep missing observations explicit. If user authentication was not captured, a successful key exchange cannot fill that gap.
For example, OpenSSH's mlkem768x25519-sha256 key exchange combines ML-KEM with X25519. Host and user authentication are separate decisions. OpenSSH 10.4 introduced experimental ML-DSA 44 and Ed25519 composite signatures, disabled by default in that release. That fact is specific to the release; check the exact version documentation before inferring what another deployment supports or enables.
The fictional observations below show hybrid key exchange on one connection. They leave authentication and other connections as separate questions. Compare the result with the pilot's stated objective, and retain the negotiated algorithms with the decision. This keeps the remaining work on authentication, stored data and other connections visible.
| Fictional pilot observation | Conclusion and evidence boundary |
|---|---|
| Negotiated key exchange: mlkem768x25519-sha256 | This connection used hybrid key establishment. The observation does not describe other connections. |
| Host signature: ssh-ed25519 | The host used a classical signature; the trusted key or certificate still needs its own evidence. |
| User-authentication method: not captured | The method is unknown. Key exchange cannot supply the missing authentication observation. |
| Older peer: classical key exchange | This remains a compatibility exception with an owner and review date, rather than a migrated connection. |
References: OpenSSH: Post-Quantum Cryptography, OpenSSH 10.4 release notes, OpenBSD: ssh_config(5).
Sources and reference editions
- NIST Post-Quantum Cryptography projectCurrent project inspected 2026-10-03
- OpenSSH: Post-Quantum CryptographyOfficial guidance checked October 4, 2026; consult release-specific documentation for signature support
- OpenSSH 10.4 release notesReleased July 6, 2026; checked October 4, 2026
- OpenBSD: ssh_config(5)Online manual checked October 4, 2026; deployment defaults depend on the installed version