Deploying PQC Is Not the Same as Proving It Works

The Assurance Gap Nobody Is Measuring

The first three NIST post-quantum standards are published. FIPS 203, 204, and 205 are final. CNSA 2.0 procurement gates take effect on 1 January 2027. The question that separates a functional migration from a governance failure remains largely unasked: can you prove your PQC deployment does what you claim it does?

Deployment is a logistics problem. Assurance is a governance problem. The two are not interchangeable, and conflating them introduces systemic risk into the programmes designed to eliminate it.

Procurement officers, compliance leads, and board risk committees need more than a vendor's assertion that ML-KEM-1024 is "implemented." They need independently verified evidence that the implementation handles encapsulation, key rotation, hybrid fallback, and side-channel mitigations correctly, under conditions that include failure, deprecation, and regulatory change.

That evidence is what PQC assurance produces. Its absence is what deployment alone cannot fill.

What PQC Assurance Actually Requires

PQC assurance is not a certificate. It is not a vendor attestation stapled to a deployment report. It is the structured, evidence-based demonstration that a cryptographic implementation behaves as specified, under conditions that include failure, algorithm withdrawal, and adversarial scrutiny.

NIST IR 8547 sets the context for migration planning. CNSA 2.0 sets procurement thresholds. FIPS 140-3 governs module validation. None of these instruments answers a core operational question: once ML-KEM-1024 sits inside your key establishment pipeline, who validated that encapsulation failures are handled, that side-channel countermeasures function, and that hybrid configurations degrade safely?

The CMVP validation backlog now exceeds 500 days on average. FIPS 140-2 certificates transition to historical status on 21 September 2026. CMMC 2.0 Phase 2 third-party assessments begin on 10 November 2026. Organisations that assumed validation would arrive before deployment deadlines are discovering that assurance cannot be retrofitted to a timeline it was never part of.

The Distinction Between Compliance and Control

Compliance asks whether the right algorithm is present. Assurance asks whether it performs correctly under stress, whether its key material is governed across its lifecycle, and whether the organisation can demonstrate that governance to an auditor on demand.

The difference is not semantic. It is the difference between a cryptographic bill of materials that lists ML-DSA-87 and one that proves ML-DSA-87 signatures verify under the organisation's actual certificate chain, revocation policy, and failover conditions.

The Structural Problem with Vendor-Led Assurance

When the entity that built an implementation is also the entity asserting its correctness, the assurance model is compromised at the point of origin. This is not a theoretical governance concern. It is the structural condition under which vendor self-attestation operates.

Vendor-led assurance conflates two functions that governance requires to remain separate: construction and validation. A vendor has commercial incentives to confirm its product works. An independent assurance function has a structural obligation to determine whether it does.

This separation is not novel governance thinking. Financial audit has enforced it for decades. Clinical trials enforce it through independent review boards. Cryptographic assurance in the post-quantum transition demands the same structural independence, because the consequences of a compromised implementation cascade through supply chains, certificate hierarchies, and trust frameworks.

SITG-Consulting's Quantum Trust and PQC Assurance Services are built on this principle. A 24-month Independence Commitment prevents the firm from bidding on remediation work arising from its own findings, structurally eliminating the conflict that undermines vendor-led models.

Six Dimensions of Cryptographic Trust

Effective PQC assurance operates across multiple governance surfaces simultaneously. A single-dimension check, whether algorithm presence or module validation, leaves the remaining attack surface unexamined.

Governance and Policy Assurance

Does the organisation's cryptographic policy reflect the post-quantum transition? Are deprecation timelines aligned with CNSA 2.0 milestones and sovereign mandates from BSI, NCSC, and ANSSI? Is there a named accountable owner for cryptographic risk at board level?

Implementation Validation

Do the deployed algorithms conform to FIPS 203, 204, and 205 specifications? Are parameter selections appropriate for the threat model? Has the implementation been tested against known-answer vectors, and are side-channel mitigations verified rather than assumed?

Operational Assurance

Can the organisation rotate keys, revoke certificates, and deprecate algorithms without service disruption? Is there a tested runbook for algorithm substitution if a deployed standard is weakened or withdrawn?

Supply Chain Cryptographic Integrity

Do third-party components, libraries, HSMs, and cloud KMS services carry their own PQC assurance evidence? Is there a cryptographic bill of materials that traces algorithm usage through the supply chain, maintained under change control?

Regulatory Readiness

Can the organisation demonstrate compliance with FIPS 140-3, CNSA 2.0, DORA Article 11, and the EU Cybersecurity Act's certification frameworks? A FIPS 140-3 Gap Analysis provides the structured assessment of module-level compliance that underpins this readiness.

Continuous Assurance

Assurance is not a point-in-time event. Algorithm confidence levels change. New vulnerabilities emerge. Regulatory thresholds tighten. An assurance model that does not include continuous monitoring and periodic revalidation decays from the moment it is issued.

Why This Matters Now

The convergence of three regulatory deadlines within a four-month window creates a compliance surface that cannot be addressed by deployment alone. FIPS 140-2 sunset falls in September. CMMC 2.0 Phase 2 assessments begin in November. CNSA 2.0 procurement gates close in January.

Organisations that have migrated to post-quantum algorithms without establishing independent assurance will face a specific problem: they will be unable to demonstrate, under audit, that their implementations are correct.

A PQC Readiness Assessment identifies the gap between current cryptographic posture and the evidence threshold that regulators and auditors will require. A Discovery Sprint provides the structured entry point for organisations that have not yet mapped their cryptographic estate.

The question is not whether your organisation has deployed PQC. The question is whether you can prove it works. If you cannot prove it, you do not control it.