Learn PQC, then check what matters

Post-quantum cryptography is cryptography designed to resist attacks from both conventional computers and future quantum computers. It runs on ordinary devices. You can start with one connection, then expand the assessment to the systems and data that depend on it.

This short path explains what a green connection result means and helps you turn it into a useful plan. You do not need to implement cryptographic algorithms yourself.

1. Why prepare before a powerful quantum computer exists?

An attacker can record encrypted traffic today and keep it. If a future computer can break the public-key exchange that protected it, the attacker may recover old session secrets. This is called harvest now, decrypt later. Data that must stay confidential for years deserves attention before it is collected. OpenSSH's explanation gives a concrete example for remote-access sessions.

There is no reliable universal date when such a computer will arrive. Your useful planning inputs are the data's confidentiality lifetime, how exposed its traffic is, and how long replacing its dependencies will take. Start with an inventory and an owner rather than a countdown.

2. Recognize three different cryptographic jobs

Job	Example	What to check
Establish a shared secret	ML-KEM, often combined with X25519 in TLS	The group actually negotiated by both endpoints.
Authenticate a signer	ML-DSA or SLH-DSA; classical deployments use RSA/ECDSA/EdDSA	Certificates, trust chains, verifiers, signed updates, and device roots of trust.
Encrypt data using a shared key	AES in a connection, disk, database, or backup	The encryption configuration and how that key is generated, protected, transported, and recovered.

NIST's ML-KEM standard addresses key establishment; ML-DSA and SLH-DSA address signatures. Swapping one does not replace the others. A TLS cipher name containing AES is not a post-quantum key exchange result.

3. Understand “hybrid”

A hybrid key exchange combines a traditional mechanism with a post-quantum mechanism in a specified protocol construction. For example, X25519MLKEM768 combines X25519 and ML-KEM-768. Its design aims to preserve confidentiality if either component remains secure, subject to the construction's assumptions and a correct implementation. It does not mean the entire application uses two complete layers of encryption.

Use established protocol implementations, not a home-made combination. RFC 10024 defines the ML-KEM hybrid TLS groups; the standards reference separates that protocol work from algorithm standards and actual product deployments.

4. Follow the data through each connection

BrowserClient software and policy
Hop 1 · public checkCDN / load balancerA browser result covers this connection when it terminates TLS here.
Hop 2 · separate evidenceOrigin websiteCollect edge-to-origin TLS telemetry.
Hop 3 · separate evidenceInternal serviceCheck the application's API, database, or other service connection.

Each arrow is a separate connection when these components terminate TLS. A green result for hop 1 leaves hops 2 and 3 unassessed. If your architecture passes TLS through instead, identify its actual termination point.

The CheckPQC banner reports your browser's connection to checkpqc.app. A domain scan makes a different connection from CheckPQC's server to the submitted hostname. Neither result certifies your device, stored files, or all visitors. See how the checks work.

Two applications on one device can differ because they ship different TLS libraries, settings, proxies, or protocols. For example, a browser result cannot establish a Node.js service or Windows application's negotiated group.

5. Make a small, evidence-based plan

Choose a check for one connection or application you own or use.
Record the result as observed, vendor-documented, or unknown. Keep the date, version, peer, and limits with it.
Add the next dependency to your private readiness worksheet: origin, internal service, SSH, VPN, messaging, certificates, or backups.
Assign an action and owner. Retest after supported upgrades and retain both the old and new evidence.

This workflow follows the discovery and interoperability focus of NIST's migration project. Unknown results are useful work items; they should stay visible until evidence resolves them.

Continue beyond TLS

Certificates, software signatures, and device trust — identify who verifies what and test the whole trust path.
Stored data, key management, and backups — follow the keys as well as the encrypted data.
Ask vendors for a usable migration plan — turn a product claim into dated evidence and a testable commitment.

A short glossary

Capability: A component can support an algorithm. It might not select it in your configuration.
Negotiation: The algorithm selected for a particular connection between peers.
Key encapsulation mechanism (KEM): A public-key mechanism used to establish a shared secret, such as ML-KEM.
Crypto agility: The ability to change cryptographic dependencies with manageable operational effort.
Trust anchor: A key or certificate a verifier is configured to trust as the starting point for authentication.

Documentation reviewed 25 September 2026. This learning path is educational guidance; readiness depends on the system and evidence you assess.