A post-quantum migration checklist for engineering teams

Most teams know they should move to post-quantum cryptography but stall on where to start. Migration is not a single switch; it is an inventory-and-prioritize exercise, and the teams that do it calmly start years before they are forced to. Here is a practical order of operations.

First, inventory where you use public-key cryptography at all: TLS termination, service-to-service auth, signed tokens (JWTs), code and release signing, document signatures, and any data encrypted at rest with a long retention window. Most organizations are surprised by how many places this touches. Second, prioritize by confidentiality lifetime, not by system importance. A session token that lives for an hour is irrelevant to the quantum threat; a backup, a legal archive, or a signed record that must hold up for fifteen years is the real exposure, because of harvest-now-decrypt-later � an attacker can record that traffic today and decrypt it once a quantum computer exists.

Third, migrate key exchange first and in hybrid mode: combine a classical algorithm (X25519) with ML-KEM (Kyber, NIST FIPS 203) so you are never weaker than today and gain quantum resistance immediately. Fourth, migrate signatures on long-lived artifacts to ML-DSA (Dilithium, FIPS 204) � release signing, audit logs, notarized documents. Fifth, and this is the step teams skip, verify: test that your verifiers accept the new formats, budget for the larger key and signature sizes (Dilithium-2 signatures are about 2.4 KB), and keep the classical path during a transition window.

Be honest about scope as you plan. Post-quantum algorithms are resistant to all known classical and quantum attacks per NIST � they are not unbreakable, and migration does not retroactively protect data already harvested under classical crypto. It is forward protection, which is exactly why starting the inventory now, before a deadline forces a rushed migration, is the rational move. A simple post-quantum signing and key-encapsulation API lets a team prototype the new primitives without re-implementing the lattice math while the broader migration plan takes shape.