Testing PQC: interoperability and performance before you commit
PQC changes fail in the field over larger messages, mismatched algorithm support, and middlebox quirks. Build an interoperability matrix and a performance baseline before any production cut-over.
Prove interop and performance on the real path, not the lab LAN
Before cutting over, validate two things: interoperability — every client, server, and middlebox on the real path negotiates and completes the PQC or hybrid exchange — and performance — the added bytes and CPU stay within budget. Most PQC failures are not cryptographic; they are size and compatibility failures that only appear across genuine network paths and older endpoints.
The algorithms themselves are standardized and well-implemented; that is not where migrations break. They break because a post-quantum key share makes a handshake bigger, an old load balancer chokes on a multi-packet ClientHello, a legacy client does not support the hybrid group, or a constrained device cannot parse a larger certificate chain. Testing is how you find these before your customers do.
Build an interoperability matrix
Enumerate the parties that must interoperate and test the cross-product, not just the happy path:
- **Client population** — the browsers, SDKs, and library versions your users actually run, including the oldest you still support.
- **Server and edge stack** — load balancers, reverse proxies, CDNs, and origin servers, each with its own TLS library.
- **Middleboxes** — firewalls, DPI appliances, and legacy network gear that inspect or forward handshakes.
- **Fallback behavior** — confirm that a non-PQC client still connects via classical negotiation, and that a PQC client is not silently downgraded.
A LAN test hides the failures that matter
Server-to-server on a fast local network is exactly where the larger-message problems do not show up — no lossy links, no old middleboxes, no MTU surprises. Test through the production path: real internet routes, the actual firewalls and load balancers, and the constrained or legacy endpoints you are most worried about. The bugs live in the path you were tempted to skip.
Baseline and budget performance
Measure before and after, and set a budget in advance so "acceptable" is defined, not argued. The relevant metrics for key exchange are handshake latency, handshake CPU, and per-connection bandwidth from the larger key shares. For signatures, measure signature size, verification time, and any storage or transmission impact from larger certificates. The overheads are generally modest for lattice algorithms, but modest is not zero — quantify it against high-throughput and latency-sensitive services specifically.
- Handshake completion rate (the real success metric) across the interop matrix.
- Median and tail handshake latency, classical vs. hybrid.
- CPU per handshake at expected connection rates.
- Signature size and verification cost for the signature domains.
- Behavior under packet loss and constrained MTU, where larger handshakes suffer most.
Gate the cut-over on evidence
Testing produces the sign-off artifact for the lifecycle's validate phase. A wave is not ready to cut over until its interop matrix passes end to end and its performance sits within budget, with fallback verified. Keep the test evidence with the roadmap item — it is what lets you cut over with confidence and what you point to if something regresses later.