PQC Readiness Assessment

Independent Design Review Before Board Approval

A PQC Readiness Assessment is an independent, evidence-based review of an organisation's post-quantum cryptography strategy, its cryptographic estate, its third-party exposure and its migration readiness. It happens before implementation. Not after. The party designing a PQC programme may also be the party hoping to build it. That is not a compliance failure. It is a structural condition. No one inside that arrangement has the standing, or the incentive, to say a design will not survive execution.

This piece explains what the assessment covers, the regulatory calendar driving it, the failure patterns we repeatedly find, and what the board receives at the end.

What does a PQC Readiness Assessment cover?

The assessment examines six areas independently:

PQC strategy and roadmap. Whether the programme design is coherent, sequenced correctly, and aligned to the organisation's actual risk profile rather than a generic threat narrative.

Cryptographic estate. What cryptography the organisation actually uses, where it sits, and what depends on it. This is rarely well understood. Discovery tooling helps, but only if it can interrogate the systems that matter, which are often the oldest and least visible.

Third-party cryptographic risk. Providers classified and prioritised against data sensitivity, cryptographic longevity, dependency depth, external connectivity, migration complexity and business criticality. This classification determines which vendors need engaging first and what evidence should be demanded before contract renewal.

External connections, protocols and classical-cryptography dependencies. The transport-layer and protocol-level dependencies an organisation forgets it still relies on. These are often the systems nobody thought to ask about.

Governance and accountability. Who owns cryptographic risk, who escalates it, who resolves it. A programme without clear governance will stall the moment it encounters the first cross-functional dependency.

Migration readiness. Whether the organisation can actually execute the transition it has committed to, given its current architecture, tooling, team capacity and supplier landscape.

The method is evidence-based, not confidence-based. Existing PQC and cryptographic documentation is reviewed. A structured assessment questionnaire is run against the organisation, not the vendor. Stakeholders are interviewed. Cryptographic dependencies and exposure are mapped. Third-party risk is reviewed independently. The whole is tested against applicable standards, sector-specific obligations and emerging regulatory expectations.

The output is a Qualification Statement: an evidence-based determination of whether the organisation is positioned to proceed, subject to stated conditions and residual risks. The full mechanics of how it is produced are set out in our earlier piece on Independent Validation. https://www.linkedin.com/posts/bcouzens_postquantumcryptography-pqc-boardgovernance-ugcPost-7447166229062266880-yqgj/?utm_source=share&utm_medium=member_desktop&rcm=ACoAAABeKQsBN9AnJvvQ3fQ4HlWJFqy-p-elxdM

Why does a PQC programme need independent review?

Somewhere in a regulated organisation right now, a cryptographic transformation programme is sitting on a desk waiting for board approval. It is multi-year, often eight figures in cost, and carries direct fiduciary consequences: the decision will sit in the board minutes beside the names of the directors who approved it. Once mobilised, it cannot be unwound without a second budget on top of the first.

The designer is often the builder. The builder is the beneficiary. The beneficiary defines the work. This creates a risk of quantum washing: exaggerating the scale of the threat to justify a programme whose scope has not been independently evidenced.

PQC readiness cannot be demonstrated by owning a strategy document or naming a migration target. It requires evidence: that the organisation understands its cryptographic estate, knows where its dependencies sit, has assigned ownership, understands its third-party exposure, and can actually execute the transition it has committed to.

A deck from the firm being reviewed is an argument for approval, not independent evidence for approval.

The PQC regulatory calendar: what is binding and what is guidance

The regulatory calendar driving PQC migration is frequently misrepresented. Dates from different jurisdictions and institutions carry different legal weight: binding requirements scoped to specific sectors, non-binding recommendations, technical guidance, a live programme-status change with procurement consequences, and at least one proposal not yet adopted. Treating them as equivalent is itself a design risk.

September 2026: FIPS 140-2 transition to Historical List

All FIPS 140-2 validation certificates move to the CMVP Historical List under the FIPS 140-3 Transition Effort timetable. A historical validation means the module is no longer actively tracked as current on the CMVP list. Organisations initiating new procurement should specify FIPS 140-3 where applicable.

This is a programme-status change with direct procurement consequences. It is not, in itself, a PQC mandate, but any organisation still procuring against FIPS 140-2 after this date is procuring against a historical standard.

Status: NIST programme milestone. Binding for federal procurement; consequential for any organisation that references FIPS validation in contracts or compliance frameworks.

31 December 2026: EU coordinated PQC roadmap (first milestone)

The European Commission's Recommendation on a Coordinated Implementation Roadmap calls on member states to establish national transition roadmaps and develop cryptographic inventories by this date.

Status: Commission Recommendation. Non-binding on organisations directly, but it sets the policy framework that supervisory expectations will follow.

2028: UK NCSC migration guidance (Phase 1)

The UK National Cyber Security Centre published Timelines for migration to post-quantum cryptography on 20 March 2025. The 2028 target covers the discovery and assessment phase: completing a full inventory of cryptographic dependencies and building an initial migration plan, including highest-priority activities and supplier dependencies.

Status: Guidance from the UK's national technical authority. Not a legal mandate, but the benchmark UK regulators will use when assessing preparedness.

2030: EU coordinated PQC roadmap (second milestone) and CNSA 2.0 (first category)

Under the same EU coordinated roadmap, high-risk use cases should be addressed by 2030.

Separately, under the NSA's CNSA 2.0 policy for National Security Systems, exclusive use of quantum-resistant algorithms is required by 2030 for specified categories including software and firmware signing and traditional networking equipment.

Status: EU Recommendation (non-binding) and NSA policy (binding for National Security Systems). Two distinct instruments with different legal force, converging on the same year.

2031: UK NCSC migration guidance (Phase 2) and CNSA 2.0 (broad NSS transition)

The NCSC's recommended target for completing highest-priority migration activities and refining the plan toward full migration by 2035.

Under CNSA 2.0, the broader National Security Systems transition is due by 31 December 2031, subject to applicable exemptions.

Status: UK guidance and US NSS policy respectively.

2033: CNSA 2.0 (browsers, servers, cloud, operating systems)

The exclusive-use requirement under CNSA 2.0 extends to web browsers, web servers, cloud services and operating systems for National Security Systems.

Status: Binding for NSS. Sets the de facto standard for any vendor selling into US government or defence supply chains.

2035: UK NCSC and EU coordinated roadmap (completion)

The NCSC's target for completing migration across all systems, services and products. The EU roadmap's target for full transition "as far as feasible."

Status: Guidance and Recommendation respectively. The shared endpoint that both the UK and EU frameworks are working toward.

NIS2: direction of travel, not yet law

On 20 January 2026, the European Commission published a proposed amendment to NIS2, COM(2026) 13 final, that would add a named obligation for member states to adopt national post-quantum transition policy. It still needs formal adoption and a twelve-month transposition period. Treat it as direction of travel, not a current requirement.

DORA: already binding, crypto-adjacent

Regulation (EU) 2022/2554 has been binding EU law for financial entities since 17 January 2025. It does not define cryptographic dependency as a standalone term, but its ICT risk-management and third-party oversight obligations can extend to cryptographic risk in practice.

Why the distinctions matter

A programme that treats an NCSC guidance target and a binding EU Regulation as carrying equal force is a programme built on a misreading of its own obligations. That misreading is exactly the kind of gap this assessment is designed to catch.

Where does the assessment look?

The assessment looks wherever cryptography actually lives, which is rarely where the strategy document says it lives. That means applications, infrastructure, cloud environments and the critical data flows running through them. It means external connections and protocols: the classical-cryptography dependencies an organisation forgets it still relies on. It means governance: who owns cryptographic risk, who escalates it, who resolves it.

It also means third parties, and this is where exposure tends to concentrate. Providers are classified and prioritised against data sensitivity, cryptographic longevity, dependency depth, external connectivity, migration complexity and business criticality. That classification decides which vendors need engaging first, why, and what evidence should be demanded of them before anyone signs a renewal.

Who commissions a PQC Readiness Assessment?

The assessment is commissioned by the people whose names go on the approval: the CIO, the CISO, the board sponsor, sometimes the audit committee directly.

It has to be conducted by a party with no delivery interest in the answer. SITG-Consulting takes one fee: the engagement fee. There is no vendor partnership behind it and no downstream revenue line. We will not bid for, deliver, subcontract on, or accept any role in a remediation programme arising from our own findings, for the same client, within twenty-four months of closing the engagement. A waiver exists in extremis, requires named board-level sign-off from the client, and is published annually in anonymised form.

The assessment exists for the director who gets asked, in an inquiry, what independent evidence supported the decision to fund this programme.

Five failure patterns we keep finding

The following reflects patterns identified across independent design reviews in regulated sectors. It is not a redacted account of any single client, and none of it should be read as a finding against a named organisation.

Across financial services, critical infrastructure and public-sector engagements, five failure patterns recur often enough to name.

1. Sequencing faults

Cryptographic-agility workstreams scheduled after cloud or infrastructure migration, not before it, leaving the organisation locked into a non-agile state for the length of the gap. By the time the agility workstream starts, the decisions that constrained it have already been funded and deployed.

2. Architecture blind spots

Hybrid key-exchange support assumed to be uniform across the estate. It rarely is. The gap is usually in the systems nobody thought to ask about: legacy middleware, embedded devices, operational technology, or third-party integrations where the organisation has no visibility into the cryptographic implementation.

3. Tooling misalignment

Visibility and discovery tooling proposed without confirming it can actually interrogate the organisation's highest-risk or oldest systems. Coverage is assumed, not evidenced. A tool that covers 80% of the estate and misses the 20% that carries the highest cryptographic risk is not a solution. It is a false assurance.

4. Generic risk framing

Harvest-now-decrypt-later named in the risk register, then never modelled against the organisation's own long-lived data classes or sovereign exposure. A threat widely cited and rarely quantified against the estate it is supposed to describe. The risk register entry exists to satisfy a compliance checkbox, not to inform a design decision.

5. Procurement drift

RFP and RFI language that has quietly narrowed to describe one vendor's documentation, so the competitive process is a formality rather than a test. This pattern is particularly common where the vendor who wrote the strategy also drafted the procurement specification.

None of these are exotic. All of them are expensive if they surface after mobilisation instead of before it.

What the board receives

At the end of the assessment, SITG-Consulting issues the Qualification Statement. It is not a vendor recommendation or an implementation proposal. It is a decision statement: whether the programme is qualified to proceed, the conditions attached to that qualification, the residual risks that remain even after revision, and the events that would require re-validation during execution.

It is decision infrastructure, built to enter the board record and survive being read back in an inquiry.

When to commission the assessment

Inside the programme, the assessment sits in one place: after the design lands on the CIO's desk, before the board releases budget. That is the point at which a flawed design is generally cheapest to fix. After board approval, every correction is a change order against a live contract.

There is likely a cryptographic transformation programme on a desk in your organisation now, waiting for a signature. The question this assessment answers is whether that design survives independent challenge before funding is committed.

Full scope and how to start a Stage 0 conversation: PQC Readiness Assessment

Direct enquiries: brian.couzens@sitg-consulting.com

Sources:

• NIST FIPS 203, 204, 205 — standardised PQC algorithms

• CMVP FIPS 140-3 Transition Effort — FIPS 140-2 certificate transition

• NCSC: Timelines for migration to post-quantum cryptography — UK 2028, 2031, 2035 targets (published 20 March 2025)

• European Commission: Coordinated Implementation Roadmap — EU PQC dates

• Proposed NIS2 amendment COM(2026) 13 final — PQC obligation proposal (20 January 2026)

• NSA CNSA 2.0 — National Security Systems milestones

• Regulation (EU) 2022/2554 (DORA) — financial entity ICT risk obligations

• CISA: Quantum Readiness Migration Guide — US federal migration guidance

SITG-Consulting. Strategy. Intelligence. Technology. Governance. Evidence over assumption. Control over narrative.