Why a Cryptographic Assurance Standard Is Now a Board-Level Requirement

NIST finalised FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) on 13 August 2024. CNSA 2.0 sets exclusive-use deadlines for quantum-resistant algorithms from 2030 to 2033 across National Security Systems. NIST IR 8547, an initial public draft published 12 November 2024, proposes deprecating RSA and ECDSA after 2030 and disallowing them after 2035. The algorithms are arriving. What has not kept pace is the ability to prove that a given implementation delivers the protection it claims.

Migration plans describe intent. An assurance standard describes evidence.

Migration Without Assurance Is Governance by Assumption

A cryptographic migration plan addresses algorithm selection, vendor evaluation, and deployment scheduling. It does not verify that deployed controls function as specified, that key management practices survive the transition, or that hybrid implementations avoid introducing the weaknesses they were designed to prevent.

When NIST IR 8547 proposes disallowing RSA and ECDSA after 2035, the question boards will face is not "did we migrate?" but "can we prove the replacement works?" A migration plan answers the first. A cryptographic assurance standard answers the second.

What a Cryptographic Assurance Standard Demands

Where a migration framework asks "have you started?", an assurance standard asks "does it hold?"

SITG-Consulting's Quantum Cryptographic Assurance Standard (QCAS v1.1) applies 32 technical controls across 8 domains, each mapped to international standards including NIST FIPS 140-3, FIPS 203, FIPS 204, FIPS 205, CNSA 2.0, ISO/IEC 19790, and ETSI quantum key distribution security frameworks. It produces three verdicts: Compliant, Conditionally Compliant (with remediation required), or Non-Compliant.

Control-Level Verification Across the Cryptographic Assurance Standard Lifecycle

The distinction is sharpest in specifics. QCAS domain ALG (Algorithmic Integrity) does not ask whether an organisation has selected ML-KEM or ML-DSA. It verifies, through controls QCAS-ALG-01 to QCAS-ALG-04, that the implementation addresses the transition from RSA and ECC to lattice-based schemes, enforces public-key reuse policies, and verifies entropy source integrity.

QCAS domain KMS (Key and Identity Management) requires, through controls QCAS-KMS-01 to QCAS-KMS-05, quantum-resistant key derivation functions, identity-based access controls for private keys, and HSM-based orchestration. Domain HBY (Hybrid Systems and Agility) evaluates whether hybrid classical-plus-PQC implementations maintain security guarantees without the classical layer weakening the quantum-safe one. Domain INV (Inventory and Certificate Operations) requires real-time certificate discovery and automated rotation to prevent outages during migration.

A general requirement of the standard is that asset owners maintain a machine-readable Cryptographic Bill of Materials (CBOM) and demonstrate crypto-agility through documented, API-driven abstraction layers.

Regulatory Convergence Demands Verifiable Controls

The regulatory environment has moved beyond guidance and into enforceable obligation. The EU's Digital Operational Resilience Act (DORA, Regulation (EU) 2022/2554), applicable to financial entities since 17 January 2025, requires the protection of cryptographic keys throughout their full lifecycle under Articles 7.2, 7.3, and 9.4(d). The US SEC cyber disclosure rules require disclosure of material cybersecurity incidents, which implicitly demands documented security controls. Singapore's MAS Technology Risk Management Guidelines and Australia's APRA CPS 234 both address controls over information security assets, cryptographic infrastructure included.

None of these regulations treats a migration plan, by itself, as sufficient evidence of compliance. Each addresses verifiable controls and documented governance. DORA in particular extends this to the lifecycle protection of cryptographic keys held by third-party ICT providers.

A cryptographic assurance standard bridges migration programme and regulatory obligation, translating "we are adopting ML-KEM-1024" into auditable evidence that the implementation operates within the parameters CNSA 2.0 specifies.

Assurance as Evidentiary Infrastructure

When a regulator or counterparty asks how an organisation knows its cryptographic controls are effective, the answer must be more substantive than vendor documentation or a completed project plan.

QCAS addresses this by mapping its 32 controls against the 22 international standards it references, producing an alignment matrix that traces a control domain through to the specific normative requirement it satisfies. The result is documentation that serves as evidence, not narrative.

For boards, this reframes the conversation. The question shifts from "are we compliant?" (a binary that conceals complexity) to "against which controls, measured by which standard, producing which verdict?"

The Cost of Operating Without a Structured Cryptographic Assurance Standard

An organisation that migrates without an assurance framework carries three specific risks. First, it cannot demonstrate to a regulator that its post-quantum implementation satisfies the standards it references. Second, it cannot detect whether hybrid implementations weaken the classical layer, a risk QCAS domain HBY is designed to evaluate. Third, it cannot produce, at the point of challenge, an evidentiary trail that traces algorithm selection through key management to operational deployment.

The CNSA 2.0 timeline is not distant. For National Security Systems, software and firmware signing should already prefer CNSA 2.0 algorithms. VPNs and routers follow by 2026, with exclusive use required across NSS categories from 2030 to 2033. Organisations referencing these timelines in board papers without an assurance standard to verify compliance will reach each milestone without the means to prove they have met it.

The migration is not the destination. Provable, auditable assurance is. That requires a standard built for the purpose.