How to Prove Your Infrastructure Is PQC Compliant
Configuration audits tell you what your system supports. Evidence-driven validation tells you what it actually does — and produces proof you can put in front of an auditor.
There is a meaningful difference between PQC configuration and PQC compliance. Configuration is what you have set up. Compliance is what you can demonstrate, with verifiable evidence, is actually happening at runtime across your entire infrastructure stack.
Most organisations pursuing PQC readiness are working at the configuration layer. They are enabling ML-KEM in their TLS settings, updating cipher suite lists, deploying OQS-capable libraries. This is necessary work. But it is not the same as being able to prove — to a regulator, an auditor, or a board — that your infrastructure is actually behaving in a quantum-resistant manner during live operation.
The gap between those two things is where most PQC programmes currently sit. And it is a gap that existing tools are not designed to close.
Why existing validation approaches are insufficient
The current landscape of PQC validation consists of three distinct approaches, each valuable but each fundamentally partial.
Algorithm validation — through NIST's Cryptographic Algorithm Validation Program (CAVP) and the Automated Cryptographic Validation Protocol (ACVP) — verifies that a cryptographic implementation produces the correct outputs for a given set of inputs. It tests correctness in a controlled environment. It says nothing about whether that implementation is actually used during live protocol execution.
Module validation — through FIPS 140-3 and the Cryptographic Module Validation Program (CMVP) — evaluates cryptographic modules against requirements for physical security, boundary integrity, and self-testing. It is comprehensive within its scope. But validation certificates are bound to specific operational environments — changes in hardware, software version, or deployment context can invalidate a prior certification without triggering any alert.
Network scanning — tools like testssl.sh, Censys, and ZMap — provides visibility into what protocols a server supports and what certificates it presents. But these tools operate at the metadata layer. They cannot tell you what key exchange group was actually negotiated in a given TLS session.
None of these approaches, alone or combined, can answer the most important question: is this system, right now, providing the cryptographic guarantees it claims to provide?
What end-to-end validation actually requires
Answering that question requires validation across four distinct layers simultaneously — and the outputs of each layer need to be verifiably linked so that a post-hoc modification to any finding is detectable.
Each layer addresses a different failure mode. Algorithm validation catches implementation bugs. Wire-level observation catches deployment mismatches. Boundary fingerprinting catches environment drift. Policy enforcement catches topology-level gaps that are compliant at the node level but non-compliant at the system level.
The Known Answer Test problem
FIPS 140-3 requires a Known Answer Test at module initialisation — a power-on self-test pattern that verifies the implementation produces expected outputs before entering operational states. This is a sound requirement, but in practice most implementations run a minimal KAT — one or two vectors — which verifies the happy path but leaves extensive edge cases untested.
A robust KAT system for PQC needs two tiers. A rapid self-test gate — a minimal set of vectors, one per operation per standard, completing in seconds — that runs before every validation pipeline execution and aborts immediately on any byte mismatch. And an exhaustive validation run — covering all the complete official NIST ACVP vector corpus across all ML-KEM, ML-DSA, and SLH-DSA parameter sets, test groups, and variants — that confirms full implementation correctness across the complete parameter space.
The two-second gate matters for operational deployment. The exhaustive validation run matters for certification-grade assurance. You need both.
The mismatch problem — and why it matters
The most important finding that emerges from multi-layer validation is one that configuration auditing is structurally incapable of detecting: the application-layer versus transport-layer PQC mismatch.
Consider a server that initialises post-quantum primitives — key encapsulation and signature algorithms — at the application layer. Its monitoring endpoint confirms these primitives are loaded and operational. A configuration audit identifies PQC algorithm support. Certificate inspection finds nothing anomalous.
But its TLS frontend is running a stock OpenSSL TLS frontend — which does not include OQS group support. Every TLS handshake it completes negotiates classical X25519 key exchange. All session keys are established using classical cryptography. The application-layer PQC operations are cryptographically isolated from the transport security layer.
Wire-level ServerHello parsing reveals this immediately. The negotiated group identifier is 0x001d — X25519, classical only. The server is classified as CLASSICAL_ONLY despite its application-layer PQC capability. This is the correct classification. And it is a classification that no existing tool produces.
This is not an edge case. It is the default state of most systems that have begun PQC implementation at the application layer without upgrading their TLS frontend. It is the gap between PQC readiness and PQC deployment.
Policy enforcement at the topology level
Individual node compliance is necessary but not sufficient. The security of a communication channel depends on both endpoints — and on any intermediaries between them.
A meaningful PQC compliance framework needs to reason about topology, not just nodes. Three cases arise in practice:
Both endpoints PQC-capable. The full cryptographic suite — key encapsulation, signatures, downgrade protection — must pass on both nodes. The channel is quantum-resistant end-to-end.
Asymmetric capability. One node is PQC-capable, the other is not. If either endpoint enforces a PQC-only security mode, the topology fails compliance. Otherwise it passes with a gateway recommendation — but the asymmetry must be explicitly documented and justified, not silently accepted.
Classical endpoints via PQC gateway. Both source and target are classical. A security layer node sits between them and handles PQC operations. The gateway must itself pass the full PQC suite. The classical endpoints are compliant by delegation — but only if the gateway is verifiably PQC-capable.
The same physical infrastructure can produce qualitatively different compliance outcomes depending on which topology is declared and which policy is enforced. This is why topology-level policy enforcement is a separate validation layer, not a property that can be inferred from node-level assessment alone.
The tamper-evident evidence chain
Audit-grade compliance requires more than correct findings. It requires that the findings are verifiably unmodified — that what you present to a regulator or auditor is demonstrably the same as what the validation pipeline actually produced.
A SHA-256 Merkle chain over the ordered validation outputs achieves this. Each block in the chain — covering run metadata, topology inventory, boundary analysis, KAT results, link evidence, and compliance verdicts — is hashed together with the previous block's hash. The final evidence root anchors the chain. Any post-hoc modification to any field changes the root hash, making tampering immediately detectable.
This transforms validation output from a report into a verifiable artefact. The distinction matters as PQC compliance requirements emerge in financial services, healthcare, and government sectors — where the question will not just be "are you PQC ready?" but "can you prove it, with evidence that hasn't been modified after the fact?"
From configuration claims to deployment evidence
The fundamental shift that PQC compliance requires is from static, configuration-based assessment to continuous, evidence-based assurance. Configuration claims are easy to make and difficult to verify. Observable, multi-layer evidence is harder to produce but fundamentally more meaningful.
Post-quantum readiness should be evaluated as an observable deployment property — not a configuration declaration. The tools and frameworks to do this properly are being built now. The organisations that establish evidence-based validation practices in 2026 will be significantly better positioned when compliance requirements become mandatory than those that are still running configuration audits in 2028.
I am working on research in this area — covering wire-level detection methodology, end-to-end validation frameworks, and formal verification of PQC protocol behaviour. I will share findings here as the work progresses. If you are building PQC compliance programmes or have questions about validation approaches, I would welcome the conversation on LinkedIn.
