NIST post-quantum standards are here. Migrating to ML-KEM and ML-DSA is critical for future-proofing your tech stack. Get the implementation guide now.
Why Kyber and Dilithium Matter Now
NIST post-quantum standards give you two building blocks that replace the crypto most stacks still rely on for key exchange and signatures. Kyber is standardized as ML-KEM for key encapsulation; Dilithium is standardized as ML-DSA for digital signatures. Both are lattice-based and designed so that an adversary with a large-scale quantum computer cannot break the core hardness assumptions the way Shor’s algorithm breaks RSA and elliptic-curve schemes.
Migration is about harvest-now-decrypt-later risk as much as “quantum day.” Anything encrypted today with classical public-key crypto and stored by an adversary can be opened later if those algorithms fall. Signatures face a different clock: certificates, firmware signing, and long-lived tokens must still verify years from now. Planning around ML-KEM and ML-DSA is how you keep both confidentiality and authenticity on a path that does not depend on classical hardness alone.
Map Where Classical Crypto Still Runs
Start with an inventory, not a library swap. List every place your stack uses public-key cryptography: TLS termination, mTLS between services, JWT or token signing, code signing, certificate authorities, VPN tunnels, encrypted backups, and message queues that do end-to-end encryption. For each, record the algorithm family (RSA, ECDH, ECDSA, EdDSA), key sizes, certificate lifetimes, and whether keys are generated in software, HSMs, or cloud KMS.
Separate ephemeral use from long-lived use. Short-lived TLS sessions may tolerate a hybrid transition sooner; firmware signatures and root CAs need a slower, carefully staged cutover because invalid signatures break installs and trust chains. Mark anything that encrypts data at rest with a public key or that issues signatures with multi-year validity as high priority for post-quantum planning.
Implement ML-KEM and ML-DSA Without Breaking Clients
Prefer hybrid constructions during the transition. For key exchange, combine a classical ECDH (or similar) share with an ML-KEM encapsulation so the session key depends on both. An attacker must break both paths to recover the key. For signatures, hybrid certificates or dual signatures (classical plus ML-DSA) let old verifiers keep working while new ones enforce the post-quantum path. Negotiate hybrids through protocol extensions your stack already supports rather than hard-forking to PQ-only overnight.
- Key sizes and ciphertext/signature sizes grow; budget bandwidth, storage, and handshake latency, especially on constrained devices and high-QPS edge paths.
- Generate and store ML-KEM/ML-DSA keys with the same custody rules as today’s private keys—HSM or KMS where you already require it.
- Pin algorithm identifiers and test interoperability early: server, client, load balancer, and any middlebox that inspects or terminates TLS.
- Keep classical algorithms available until every critical peer can speak the hybrid or PQ suite; remove them only after metrics show zero residual classical-only traffic you still care about.
Use libraries and protocol stacks that expose NIST ML-KEM and ML-DSA by their standard names, and treat “Kyber” and “Dilithium” as the algorithm families behind those names when reading older docs or vendor notes. Validate vectors from the standards, not only “it connects in staging.”
Roll Out, Monitor, and Retire the Old Path
Roll out in layers: internal services first, then edge TLS, then customer-facing APIs and mobile clients. Enable hybrid ciphersuites in canaries, watch failure rates and handshake size, then expand. For signing, issue dual-signed artifacts or short-lived hybrid certs before you mint long-lived PQ-only roots. Document which teams own each crypto surface so a single library upgrade does not leave one service stranded on classical-only configs.
Success looks like measurable progress, not a big-bang cutover: inventory complete, hybrids live where traffic is highest, long-lived secrets re-encrypted or re-signed under a plan that includes ML-KEM/ML-DSA, and classical-only suites scheduled for removal with a clear owner. NIST standardized ML-KEM and ML-DSA so implementers can stop waiting for “the right algorithm” and start shipping a migration path that future-proofs the stack without guessing at quantum timelines.