Sign in Subscribe
compliance

Multi-Framework PQC Compliance: Resolving the CNSA 2.0, NCSC, and BSI Conflicts

Organizations operating across U.S., UK, and German regulatory jurisdictions already face a January 1, 2027 hard deadline: all new National Security System (NSS) acquisitions must meet CNSA 2.0 algorithm requirements from that date forward.[NSA CNSA 2.0] Validated products carrying quantum-resistant implementations have long lead times, and NIAP Protection Profiles for those implementations are still maturing. Compliance officers managing procurement pipelines that also touch UK NCSC or German BSI requirements cannot defer framework reconciliation until harmonization guidance appears-none has been published, and none is imminent.

What Each Framework Actually Requires: A Side-by-Side Baseline

CNSA 2.0, published by the NSA, is the most prescriptive of the three frameworks. It mandates a specific algorithm set for NSS: AES-256 for symmetric encryption, ML-KEM-1024 (FIPS 203) for key establishment, ML-DSA-87 (FIPS 204) for general digital signatures, and LMS or XMSS (NIST SP 800-208) for firmware and software signing.[NSA CNSA 2.0 Algorithm Guidance] It also sets five discrete enforcement milestones running from immediate obligations through December 31, 2031, and requires FIPS-validated implementations for NSS environments. Compliance with CNSA 2.0 is not optional for contractors building or operating systems that process classified national security information.

BSI TR-02102, Germany's technical guideline for cryptographic mechanisms, includes PQC profiles that converge on ML-KEM and ML-DSA variants-but does not mandate LMS or XMSS for signing use cases, and does not impose equivalent hard enforcement deadlines.[BSI TR-02102 Cryptographic Mechanisms] BSI's posture is risk-informed and technically rigorous, but it leaves implementation sequencing to the organization's own risk assessment process more explicitly than CNSA 2.0 does.

NCSC's UK guidance on PQC adoption is explicitly risk-tiered and non-prescriptive on algorithm selection beyond broad family recommendations.[NCSC Post-Quantum Cryptography Guidance] NCSC endorses ML-KEM and ML-DSA-family algorithms and encourages hybrid deployments during transition, but it does not publish enforcement milestones equivalent to CNSA 2.0's milestone table, and it does not mandate FIPS validation. The absence of LMS and XMSS from NCSC's primary signing guidance-combined with CNSA 2.0's explicit requirement for those algorithms in firmware contexts-constitutes the first structural conflict compliance officers must manage.

Where the Conflicts Are Real and Where They Are Overstated

The broadest point of genuine alignment across all three frameworks is the core algorithm family: ML-KEM for key encapsulation and ML-DSA for general digital signatures are endorsed or mandated by CNSA 2.0, BSI TR-02102, and NCSC guidance alike. This convergence gives compliance officers a workable foundation for procurement language. Products implementing ML-KEM-1024 and ML-DSA-87 will not be non-compliant under any of the three frameworks-they may simply require additional documentation layers depending on jurisdiction.

The conflicts that require escalation, rather than documentation, are narrower but consequential. First: signing algorithm selection for firmware. CNSA 2.0 mandates LMS or XMSS (per NIST SP 800-208) for software and firmware signing.[NSA CNSA 2.0 Algorithm Guidance] Neither NCSC nor BSI TR-02102 imposes an equivalent LMS/XMSS mandate, and SLH-DSA (FIPS 205)-which BSI and NCSC treat as a viable stateless alternative-is absent from CNSA 2.0's required algorithm set. An organization building a firmware signing pipeline that must satisfy both NSS and EU/UK regulatory requirements cannot resolve this conflict through implementation choices alone; it requires a documented jurisdiction-prioritization decision. As NIST IR 8547's deprecation schedule puts additional pressure on RSA-based signing timelines, the signing algorithm conflict between frameworks becomes more operationally urgent, not less.

Second: validation requirements. CNSA 2.0 requires FIPS-validated cryptographic implementations for NSS. BSI and NCSC impose no equivalent validation mandate, though both encourage standards-aligned implementations. For vendors selling into both U.S. federal and EU/UK markets, this means FIPS validation is necessary but not sufficient-and the absence of a FIPS 140-3 validated PQC module today (a gap documented elsewhere in the CMVP pipeline) creates an interim compliance problem specific to NSS-scope systems.

Third: timeline binding. CNSA 2.0's hard milestones create legal and contractual exposure for NSS contractors. NCSC and BSI guidance does not create equivalent hard deadlines. Treating these frameworks as symmetrically binding in internal risk registers overstates the EU/UK exposure while potentially understating the U.S. federal one.

The CNSA 2.0 Milestone Timeline: What Compliance Officers Must Track Now

CNSA 2.0 specifies five enforcement milestones. Compliance officers in active procurement cycles must track all five, but two are immediately material:

  • Immediate (ongoing): Annual reporting on quantum-vulnerable systems under NSM-8 and NSM-10 is already active. This is not a future obligation-it applies to any organization operating systems within NSS scope.[NSA CNSA 2.0]
  • December 31, 2025: Existing NIAP and CSfC validations under CNSA 1.0 remain valid through this boundary. Systems already approved under prior profiles are not immediately non-compliant.
  • January 1, 2027: All new NSS acquisitions must meet CNSA 2.0 requirements. This is the deadline that makes current procurement pipeline reviews urgent-not a future planning consideration.
  • December 31, 2030: All fielded NSS equipment must be CNSA 2.0 compliant or subject to a formal waiver process.
  • December 31, 2031: Full enforcement across NSS environments. No CNSA 1.0 systems remain authorized.

A 90-day waiver mechanism applies following CNSSP 15 updates, and RMF integration under Security Control SC-12 is required. Compliance officers should ensure that CNSA 2.0 transition status is reflected in current RMF assessment documentation-not deferred to a future authorization cycle. The reporting obligations established under NSM-10 make quantum-migration status a live compliance matter for federal agencies and their contractors, not a planning-phase consideration.

The Validation Gap: Managing Compliance When Certified Products Do Not Yet Exist

CNSA 2.0 mandates deployment of validated products "as available"-a phrase that places compliance officers in a structurally difficult position. NIAP Protection Profiles for quantum-resistant implementations are still maturing, and current profiles exclude signature generation from the Target of Evaluation (TOE) boundary in several product categories. No FIPS 140-3 validated module implementing the full CNSA 2.0 algorithm set is yet listed in the CMVP active validation database.[NIST Cryptographic Module Validation Program]

The defensible interim posture is a hybrid CNSA 1.0/2.0 implementation: deploying CNSA 2.0 algorithms where validated products exist, maintaining CNSA 1.0 where they do not, and documenting the gap formally in RMF risk assessments. This is not a compliance failure under current NSA guidance-it is the explicitly anticipated transition state. What constitutes a compliance failure is the absence of documentation. Compliance officers should raise the validation gap in board-level risk registers now, because the January 1, 2027 new acquisitions deadline arrives before the FIPS 140-3 PQC module pipeline is likely to be fully populated. Organizations that have not surfaced this gap formally will face retroactive audit exposure when the milestone passes.

Multi-Jurisdiction Procurement: Building a Vendor Checklist That Satisfies All Three Frameworks

For vendors and operators with simultaneous U.S., UK, and German regulatory exposure, the practical approach is a layered compliance matrix rather than a single unified standard. The cross-framework anchor-the algorithm set acceptable under all three frameworks-is ML-KEM and ML-DSA. Procurement language should require both as a baseline condition for any cryptographic product entering a multi-jurisdiction environment. When assessing vendor PQC capability, require explicit confirmation of which algorithm parameters are implemented, not just which algorithm families are supported-ML-KEM-768 and ML-KEM-1024 are not interchangeable in an NSS context.

Jurisdiction-specific layers sit above that anchor:

  • NSS/U.S. federal scope: FIPS 140-3 validation, LMS/XMSS for firmware signing, CNSA 2.0 parameter sets, NIAP Protection Profile alignment where applicable.
  • German BSI scope: BSI TR-02102 PQC profile alignment; SLH-DSA as an acceptable stateless signing alternative where LMS/XMSS is not mandated.
  • UK NCSC scope: Risk-tier classification documentation; hybrid implementation during transition is explicitly supported; no hard deadline for algorithm enforcement.

Where LMS/XMSS is required for NSS firmware signing but absent from UK/EU guidance, compliance officers should document a jurisdiction-prioritization decision: in NSS-scope contexts, CNSA 2.0 takes precedence; in non-NSS EU/UK contexts, SLH-DSA or ML-DSA is acceptable for signing. LMS/XMSS state management-specifically, the need to track one-time signature usage to prevent key reuse-is a recurring operational pain point in audit contexts. Procurement contracts for firmware signing infrastructure should include explicit state-management requirements and vendor attestation obligations. Including cryptographic agility clauses in vendor contracts protects against algorithm updates across any of the three frameworks without requiring full re-procurement.

A Defensible Compliance Posture Today: What to Document Before Harmonization Arrives

No official body has published multi-framework harmonization guidance for CNSA 2.0, NCSC, and BSI TR-02102. Compliance officers cannot wait for it. The organization that documents its framework-prioritization reasoning clearly is protected against retroactive findings-even when the frameworks themselves remain in flux. Five concrete documentation practices constitute a defensible posture today:

  1. Maintain a living algorithm inventory mapped explicitly to each applicable framework, with jurisdiction scope noted for each system. This is the foundation that makes all subsequent decisions auditable.
  2. Document jurisdiction-prioritization decisions with explicit risk rationale. Where CNSA 2.0 and BSI TR-02102 conflict on signing algorithms, record which framework governs which system and why. Undocumented prioritization decisions become findings.
  3. Flag the FIPS validation gap formally in RMF assessments and equivalent EU risk documentation. The gap is real, acknowledged by NIST, and not the compliance officer's fault-but it must appear in formal risk registers, not only in informal tracking sheets.
  4. Establish a 90-day review cadence tied to NIST FIPS validation announcements and CNSSP 15 updates. Both affect compliance posture; neither will be signaled in advance with sufficient lead time to act reactively.
  5. Ensure procurement contracts include PQC algorithm agility clauses. Vendors unable to update algorithm implementations without full re-procurement create compounding risk as the CNSA 2.0 milestone dates approach.

Before your next board-level risk review, map your current algorithm inventory against the CNSA 2.0 milestone table and identify which systems fall inside the January 1, 2027 new acquisitions boundary. That mapping exercise-documented and dated-is the single most defensible action available to a compliance officer today. The NSA's CNSA 2.0 algorithm and timeline documentation is the primary reference for scoping that exercise.

Key Takeaways

  • CNSA 2.0, NCSC, and BSI TR-02102 converge on ML-KEM and ML-DSA as the cross-framework anchor-this alignment is workable and should anchor multi-jurisdiction procurement language.
  • The genuine conflicts are narrow but consequential: LMS/XMSS vs. SLH-DSA for firmware signing, FIPS validation requirements for NSS, and hard CNSA 2.0 milestones vs. non-prescriptive NCSC/BSI timelines.
  • January 1, 2027 is a hard acquisition deadline for NSS-scope systems-not a planning milestone. Organizations with active procurement cycles must act before this date, as validated product lead times are long.
  • The FIPS 140-3 PQC module validation gap is real and formally acknowledged. A hybrid CNSA 1.0/2.0 posture is defensible when documented in RMF assessments; the absence of documentation is the compliance risk.
  • No official harmonization guidance exists for the three frameworks. Compliance officers must document their own framework-prioritization rationale explicitly-this documentation is the primary protection against retroactive audit findings.
  • Annual NSM-8/10 reporting on quantum-vulnerable systems is already active. This is a current obligation, not a future one, for NSS-scope organizations.

On this site:

Primary sources:

This article draws on primary documentation from NSA CNSA 2.0 algorithm guidance, BSI TR-02102 technical guidelines, NCSC post-quantum cryptography whitepapers, and NIST CMVP program documentation. All claims verified against official sources as of April 2026.

Disclaimer: This content is for informational purposes only and does not constitute legal, regulatory, or compliance advice. Consult a qualified professional before making compliance decisions. pqcinformation.com is independent and not affiliated with any vendor or standards body.

Read next