Does a Successful Handshake Prove the Migration? Fault-Injection Evidence on Verifying Post-Quantum TLS Deployments

Operators often verify a post-quantum TLS migration with cheap proxies: a connection still succeeds, or a configuration names a post-quantum group. How much false assurance do such proxies give? We built a fault-injection harness (60 deployments, i.e. 30 server configurations on two network paths; 1,260 handshakes; OpenSSL 3.6.3) that reads the negotiated group from the wire, and scored eight verification procedures ("oracles") against a reference standard: the outcome of five client profiles run on the deployment's own path. The grid is deliberately fault-dense; 58 of the 60 deployments are faulty. A configuration check passes 46 of the 58; a connection-succeeds check passes 38, because hybrid key exchange can degrade silently to a classical group while the session stays authenticated and error-free (all 29 such sessions exited with status 0). Reading the negotiated group with the same client cuts the count to 10; adding a legacy-client regression probe leaves 2, both reachable only on a path the verifier did not use; running both probes on the production path leaves 0. Changing the probe client alone changes the counts (16 instead of 10), so the choice of probe client is itself a verification hazard. On a 24-intent grid over OpenSSL and Go, the same configuration-level policy written in each stack's syntax produced different outcomes in 5 intents. These are results for a finite, designed fault set and two stacks, not estimates of deployment prevalence.