How to test that your post-quantum migration actually works

A post-quantum migration that has not been tested is a liability wearing the costume of security. Teams often add ML-KEM or ML-DSA to a config, see no errors, and assume they are protected � but the failure modes of post-quantum crypto are quiet and specific, and they surface in production if you do not hunt them first. The good news is that the tests are concrete and cheap to run.

Start with interoperability. If you deployed hybrid key exchange (X25519 + ML-KEM-768), verify that a client and server actually negotiate the hybrid group and not a silent fallback to pure classical. For signatures, round-trip every algorithm you claim to support: generate a keypair, sign a known message, verify it, then verify that a tampered message and a truncated signature both FAIL. A verifier that accepts a bad signature is worse than no signature at all. Then test the size boundaries: Dilithium-2 signatures are about 2.4 KB and keys about 1.3 KB, so anything that assumed 64-byte signatures � database columns, fixed buffers, packet MTUs, JWT header limits � will break, and you want it to break in CI, not at 3 a.m.

Finally, test the transition itself. During migration you run classical and post-quantum in parallel, so verify both paths independently and verify that a peer which only speaks classical still connects while a peer that speaks both prefers the hybrid path. Be honest about what the tests prove: they confirm your implementation negotiates, verifies, and sizes correctly � resistant to known classical and quantum attacks per NIST, not unbreakable, and not a substitute for a real security review. A simple signing and KEM API is useful precisely as a known-good reference to test your own stack against.