DRAFT, FOR LEGAL REVIEW. This article analyses post-quantum cryptography obligations under multiple regulatory frameworks. It does not constitute legal or regulatory compliance advice. Organisations must seek qualified legal and regulatory counsel before making compliance decisions. Claims about regulatory requirements reflect the state of legislation and guidance as of May 2026.

PQC Compliance Readiness: A Gap Analysis Framework for Security Teams

Most compliance programmes address one framework at a time. PQC compliance does not permit that luxury. By 2026, an organisation operating across US federal procurement, defence contracting, EU financial services, and EU critical infrastructure simultaneously faces overlapping obligations from four different frameworks, NIST IR 8547, CNSA 2.0, DORA, and NIS2, with a shared technical foundation but different scope definitions, timeline milestones, and evidence requirements.

This article provides a structured gap analysis methodology for that multi-framework environment. It is a practitioner tool, not a regulatory compliance audit. The scoring model in Section 6 is synthesised from compliance programme management methodology and should be labelled as such in any formal documentation. It is not endorsed by any regulatory body.

Why PQC Compliance Is a Multi-Framework Problem

The four primary frameworks share a technical foundation. NIST FIPS 203 (ML-KEM), 204 (ML-DSA), 205 (SLH-DSA), and 206 (FN-DSA) are the approved post-quantum algorithm suite on which all four frameworks converge. AES-256 remains the recommended symmetric cipher under all four. Where the frameworks diverge is in scope, parameter set requirements, timeline, and how compliance is evidenced.

NIST IR 8547 (November 2024) is the US federal and contractor baseline. It creates mandatory obligations for US federal agencies and informs the compliance expectations of frameworks that reference NIST cryptographic guidance (FedRAMP, CMMC). Its deprecation timeline is the international technical reference regardless of whether an organisation is subject to US law.

CNSA 2.0 (September 2022) applies to national security systems as defined in 44 USC section 3552(b)(6) and the contractors who supply them. Its parameter set requirements are more stringent than NIST IR 8547 (ML-KEM-1024 and ML-DSA-87 rather than ML-KEM-768 and ML-DSA-65), and its new-system restriction is already in effect.

DORA (Regulation (EU) 2022/2554) applies to 20 categories of EU financial entity plus designated critical ICT third-party service providers. Its cryptographic controls obligations are derived from Article 9 and the Delegated Regulation (EU) 2024/1774 on ICT risk management.

NIS2 (Directive (EU) 2022/2555) applies to essential and important entities across 18 sectors in EU member states. Article 21(2)(h) requires "the use of cryptography and, where appropriate, encryption" as part of appropriate security measures. Member state transposition was due October 2024; in practice, transposition was uneven across the EU at that deadline, with several member states having not enacted implementing legislation by the time it fell due (European Commission infringement context). Organisations operating across multiple EU jurisdictions should verify their national competent authority's transposition status and any jurisdiction-specific guidance rather than assuming uniform enforcement from October 2024.

For the detailed NIST IR 8547 transition timeline and milestone requirements, see /insights/nist-ir-8547-transition-timeline/.

An organisation subject to three of these four frameworks does not benefit from conducting three separate compliance audits. The gap analysis framework below maps consistently across all four, producing a single document that identifies where the organisation's current posture falls short of each framework's requirements and in what order to remediate.

Gap Dimension 1: Cryptographic Inventory Completeness

Every PQC compliance framework requires a complete cryptographic inventory as the prerequisite for any further compliance work. The language differs by framework; the requirement does not.

NIST IR 8547 Section 5 explicitly references cryptographic asset discovery as the first migration step. CNSA 2.0 requires identification of all cryptographic use in national security systems. DORA Article 9(4) requires identification and classification of all ICT assets, cryptographic algorithms and key material are ICT assets. NIS2 Article 21(2) requires appropriate cryptographic controls, which implies an inventory of current cryptographic use that can be assessed against the "appropriate" standard.

The structured output of the inventory is a Cryptographic Bill of Materials (CBOM). A CBOM captures: algorithm identity (RSA-2048, ECDSA P-256, AES-128-GCM); key size; protocol context (TLS 1.3, S/MIME, IPsec IKEv2); location in the software or infrastructure stack; and dependency relationships between systems and cryptographic libraries. IETF draft-ietf-cbom is developing a formal CBOM specification; verify the current draft or RFC status before citing at publication. [ASSUMED, verify IETF CBOM draft status.] NTIA's minimum elements for a Software Bill of Materials (2021) and IETF RFC 9090 (CoSWID) provide adjacent standards context for the dependency tracking dimension.

The CBOM is the prerequisite for every other gap analysis dimension. An organisation that has not completed a CBOM cannot accurately assess algorithm deprecation posture, timeline compliance, or third-party dependency coverage. Starting the gap analysis without a CBOM means scoring the other four dimensions on incomplete information.

Gap Dimension 2: Algorithm Deprecation Posture by Framework

The four frameworks have different positions on algorithm requirements. Mapping the organisation's current deployed algorithms against each framework's requirements reveals the algorithm-level compliance gap.

NIST IR 8547 (November 2024) deprecates RSA-2048 and ECC for new system deployments by 2030 and disallows all uses by 2035. It approves ML-KEM (FIPS 203), ML-DSA (FIPS 204), SLH-DSA (FIPS 205), and FN-DSA (FIPS 206) as replacements. AES-256 is the required symmetric cipher; AES-128 falls below the post-quantum security threshold (64-bit effective security after Grover's algorithm).

CNSA 2.0 requires ML-KEM-1024 (the highest ML-KEM parameter set) and ML-DSA-87 (the highest ML-DSA parameter set) for national security systems. This is more stringent than NIST IR 8547's general enterprise recommendation of ML-KEM-768 and ML-DSA-65. The difference matters for defence contractors whose systems must meet CNSA 2.0: a system configured for ML-KEM-768 meets NIST IR 8547 but not CNSA 2.0. For a detailed treatment of CNSA 2.0 requirements and the compliance audit framework, see /insights/cnsa-2-compliance-audit-framework-checklist/.

DORA does not currently name specific NIST PQC algorithms. Article 9 of DORA and the Delegated Regulation (EU) 2024/1774 require cryptographic controls that remain resilient against developments in cryptanalysis, with the recitals explicitly naming quantum advancements as the class of development contemplated. [ASSUMED, specific recital numbers for quantum cryptographic resilience: verify against EUR-Lex at time of publication.] The EBA, ESMA, and EIOPA are developing Regulatory Technical Standards (RTS) under DORA that may specify algorithm-level requirements. Verify whether any such RTS has been finalised before publication; if published, update the DORA section to reflect actual requirements. [ASSUMED, DORA RTS on PQC algorithm requirements: verify status at publication.] The current DORA compliance baseline for cryptography is outcome-based: cryptographic technology that remains resilient against quantum-era cryptanalytic threats. The NIST FIPS 203/204/205 standards are the current best-available response to that obligation for EU financial entities. For a full treatment of DORA's PQC obligations, see /insights/dora-post-quantum-cryptography-ict-risk/.

NIS2 Article 21(2)(h) requires "appropriate" cryptographic measures. National implementations vary. Germany's BSI Technical Guideline TR-02102 (updated annually) is the practical compliance reference for German NIS2-regulated entities, verify the current TR-02102 version for ML-KEM/ML-DSA recommendations. [ASSUMED, verify current BSI TR-02102 version includes ML-KEM/ML-DSA.] France's ANSSI published "ANSSI views on Post-Quantum Cryptography Migration" (2022), which provides the French jurisdiction reference. Entities operating under NIS2 in multiple EU member states should check their national competent authority's algorithm catalogue for each jurisdiction.

The UK NCSC guidance ("Preparing for quantum-safe cryptography") recommends migration to NIST-standardised PQC algorithms and does not currently impose mandatory timelines on commercial organisations. UK government departments and critical national infrastructure operators may face additional Cabinet Office or NCSC requirements not yet in the public domain. Verify whether NCSC has published updated guidance beyond the 2020 whitepaper since NIST IR 8547 was published in November 2024. [ASSUMED, verify NCSC guidance update status at publication.]

Gap Dimension 3: Timeline Compliance Posture

The gap analysis must assess whether the organisation's current migration programme will meet each applicable framework's timeline requirements. The milestones from the four frameworks, compared:

Framework Scope Algorithm requirement Key timeline milestone
NIST IR 8547 US federal / contractor baseline ML-KEM/ML-DSA/SLH-DSA/FN-DSA; AES-256 Discovery 2025-2026; new systems PQC 2030; legacy migration 2035
CNSA 2.0 US national security systems ML-KEM-1024; ML-DSA-87; AES-256 New NSS restricted from 2025; legacy migration 2033
DORA EU financial entities Outcome-based; RTS pending ICT risk framework live January 2025; RTS timelines TBD
NIS2 EU essential/important entities Appropriate measures; national authority guidance Member state transposition October 2024; enforcement varies
UK NCSC guidance UK government/CNI (advisory; not a mandatory regulatory instrument for commercial entities) NIST-aligned; no mandatory commercial timeline Phase 1 discovery 2025-2028; Phase 2 2028-2031; Phase 3 2031-2035 [ASSUMED, verify phased timeline against current NCSC guidance at publication]

The uncomfortable reality for most organisations in 2026: NIST IR 8547 guidance calls for cryptographic asset discovery to be complete by 2025 to 2026. Organisations that have not yet begun their CBOM are already behind the NIST-recommended discovery phase, not ahead of the 2030 new-system deadline. For organisations within CNSA 2.0 scope, deploying new national security systems with RSA or ECDSA from 2025 onwards is a current non-compliance, not a future risk.

The timeline posture assessment compares: the framework deadline for each migration milestone; the organisation's current programme schedule; and the gap in months. That gap, multiplied across multiple applicable frameworks, is the executive summary of the compliance readiness assessment.

Gap Dimension 4: Third-Party and Supply Chain Dependency

PQC compliance cannot be assessed against the organisation's own systems alone. Three frameworks impose explicit supply chain obligations.

DORA Article 28 requires EU financial entities to include contractual provisions ensuring that ICT third-party service providers supporting critical or important functions maintain adequate cryptographic controls. An entity whose cloud KMS provider has no documented PQC roadmap has a gap in its Article 28 diligence for those critical functions.

NIS2 Article 21(2)(d) requires supply chain security as a component of appropriate technical and organisational measures. For NIS2-regulated entities, third-party cryptographic posture is within scope of the Article 21 assessment.

NIST IR 8547 addresses cryptographic dependencies in software supply chains (section reference: verify section number against current document at time of use). [ASSUMED, verify section number at time of writing.] For any system that relies on cryptographic library implementations from third-party vendors, the migration requires either vendor-supplied library updates or alternative library sourcing.

The practical supply chain gap analysis assesses each critical third-party vendor against four questions: Has the vendor published a PQC migration roadmap? Does the roadmap align with the applicable compliance timeline? Does the vendor support hybrid key exchange (X25519+ML-KEM) today? Has the vendor committed to FIPS 203/204/205/206 support in a specific release timeline? The answers feed directly into the organisation's gap inventory. A critical vendor that cannot answer the fourth question affirmatively by 2026 is a programme dependency that requires escalation.

Cloud service providers (AWS, Azure, GCP, Cloudflare) have published PQC roadmaps. Critical SaaS applications, HSM vendors, network security appliances, and PKI software providers vary considerably in their readiness and transparency. Hardware vendors, TPM and HSM firmware in particular, are often the longest-lead items. Finding a critical HSM without a FIPS 203 roadmap in 2026 is a programme risk; finding it in 2029 is an emergency.

The Gap Analysis Output: Compliance Readiness Scoring

The gap analysis produces a compliance readiness score for each applicable framework across five dimensions. This scoring model is practitioner guidance, not a regulatory methodology.

Each dimension is scored 0 to 4: 0 = not started; 1 = scoped and planned; 2 = in progress; 3 = substantially complete; 4 = compliant with current framework requirements. The maximum score per framework is 20.

Dimension 1, Cryptographic inventory completeness: Is the CBOM complete, current, and covering all critical systems? (0 = no inventory; 4 = full CBOM with dependency mapping, reviewed within 12 months)

Dimension 2, Algorithm deprecation posture: Are deployed algorithms aligned with this framework's requirements? (0 = no assessment; 4 = all critical systems using compliant algorithms or with approved transition plan)

Dimension 3, Timeline compliance posture: Is the migration programme on schedule to meet this framework's milestones? (0 = no programme; 4 = programme schedule demonstrates compliance with all upcoming milestones)

Dimension 4, Third-party dependency coverage: What percentage of critical third-party vendors have been assessed against PQC roadmap criteria? (0 = no assessment; 4 = all critical vendors assessed with documented roadmaps or remediation plans)

Dimension 5, Documentation and governance: Is the migration plan documented, assigned to a named owner, and visible at board level? (0 = no documentation; 4 = formal programme with board-level risk visibility and executive sponsor)

Score thresholds: 0 to 8 (pre-compliance: significant remediation required before any framework deadline); 9 to 14 (in progress: meaningful work under way but gaps remain; establish a formal programme with committed timeline); 15 to 18 (substantially ready: minor gaps; current trajectory likely meets near-term framework milestones); 19 to 20 (compliant: no gaps identified; maintain and monitor as frameworks evolve).

For a multi-jurisdiction organisation, running this scoring across NIST IR 8547, CNSA 2.0, DORA, and NIS2 simultaneously produces a framework comparison table that shows at a glance: which frameworks the organisation is in scope for; the current readiness score for each; the most critical gap for each; and the priority remediation action. For organisations subject to both CNSA 2.0 and NIST IR 8547, the CNSA 2.0 score is typically the binding constraint, its parameter set requirements and 2033 legacy migration deadline are more stringent than the general NIST IR 8547 baseline.

Using the Gap Analysis to Build the Remediation Roadmap

The remediation roadmap that flows from the gap analysis operates across three planning horizons, aligned with NIST IR 8547 milestone targets.

Immediate horizon (0 to 12 months): Complete the CBOM. Deploy hybrid TLS (X25519+ML-KEM) on external-facing systems carrying high-HNDL-risk data. Determine CNSA 2.0 scope for all systems. Assess and document critical third-party vendor PQC roadmaps. Establish a named programme owner and board-level risk visibility. These actions address the dimension 1 and dimension 5 gaps that currently block every other dimension from scoring above 2.

Medium-term horizon (1 to 3 years): Migrate PKI root certificate authorities to ML-DSA. Migrate service mesh and enterprise mTLS to ML-KEM hybrid key exchange. Migrate KMS key wrapping infrastructure to ML-KEM. Complete all new system deployments in PQC-only mode (NIST IR 8547 new-system deadline 2030 requires planning and development to begin no later than 2027 for complex systems). Complete CNSA 2.0-scoped systems migration to ML-KEM-1024 and ML-DSA-87.

Long-term horizon (3 to 10 years): Complete legacy system migration across all applicable framework scopes. Retire all RSA and ECDSA deployments. Achieve full FIPS 203/204/205/206 compliance across the estate. Complete re-encryption of long-duration stored data identified in the HNDL risk assessment.

The gap analysis is a living document. It should be reviewed at a minimum annually, or following any significant change to applicable regulatory frameworks (DORA RTS updates, NCSC guidance updates), the organisation's system landscape (acquisitions, cloud migrations, third-party contract renewals), or the quantum computing timeline assessment. A material change in the Q-Day probability distribution shortens the Mosca inequality margin for all organisations simultaneously; the gap analysis review process is what ensures that change translates into programme action rather than post-event awareness.

Sources