Standards & Compliance | Post-Quantum Cryptography

Overview

Cryptographic algorithms do not become deployable when researchers publish papers. They become deployable when standards bodies codify them into numbered documents, government agencies mandate their use, compliance frameworks reference them by name, and validation programs certify that implementations actually conform to the specifications. The post-quantum cryptography transition is no exception — and the standards landscape is evolving faster than most organizations realize.

As of early 2026, the PQC standards ecosystem has moved from theoretical to operational. NIST published FIPS 203, 204, and 205 in August 2024. The NSA’s CNSA 2.0 timeline has hard deadlines starting in 2025. The European Union issued its first formal Recommendation on post-quantum cryptography in April 2024. FIPS 140-3 validation of PQC modules is underway. And industry compliance frameworks — PCI DSS, HIPAA, FedRAMP, SOC 2, GDPR — are beginning to grapple with what “strong cryptography” means when RSA and ECC have an expiration date.

This page maps the entire PQC standards and compliance landscape: the NIST FIPS standards in detail, U.S. government mandates, European regulatory positions, the FIPS 140-3 validation pipeline, and a compliance mapping across the major frameworks that security teams must navigate. For the technical details of the algorithms themselves, see Lattice-Based Cryptography and Hash-Based Signatures. For migration planning that operationalizes these requirements, see Migration Strategies & Crypto Agility. For the standardization process that produced these standards, see NIST PQC Standardization Process.

1. NIST FIPS Standards for PQC

On August 13, 2024, NIST published three Federal Information Processing Standards that define the first generation of post-quantum cryptographic algorithms. These are not advisory documents or technical reports — they are mandatory federal standards that carry the force of law for U.S. government systems and ripple through the global technology supply chain via procurement requirements.

1.1 FIPS 203: ML-KEM (Module-Lattice-Based Key Encapsulation Mechanism)

What it specifies: FIPS 203 defines ML-KEM, the standardized version of CRYSTALS-Kyber. ML-KEM is a key encapsulation mechanism (KEM) — it allows two parties to establish a shared secret key over an insecure channel. It replaces the key exchange functions currently served by RSA key transport, Diffie-Hellman, and Elliptic Curve Diffie-Hellman.

Algorithm family: Module Learning With Errors (MLWE), a structured lattice problem. The security relies on the computational hardness of distinguishing MLWE samples from uniform random samples — a problem for which no efficient quantum algorithm is known.

Approved parameter sets:

Parameter Set	NIST Security Level	Shared Secret Size	Public Key Size	Ciphertext Size	Classical Security Equivalent
ML-KEM-512	1	32 bytes	800 bytes	768 bytes	AES-128
ML-KEM-768	3	32 bytes	1,184 bytes	1,088 bytes	AES-192
ML-KEM-1024	5	32 bytes	1,568 bytes	1,568 bytes	AES-256

Security levels explained:

NIST defines five security levels based on the computational effort required to break the scheme, anchored to symmetric cryptographic operations:

Level 1: At least as hard to break as AES-128 key search (brute-forcing a 128-bit key)
Level 2: At least as hard to break as SHA-256 collision search
Level 3: At least as hard to break as AES-192 key search
Level 4: At least as hard to break as SHA-384 collision search
Level 5: At least as hard to break as AES-256 key search

These levels account for both classical and quantum attacks. The quantum security margin is built in — Level 1 requires security against quantum adversaries at the stated threshold, not just classical ones.

Implementation requirements:

Implementations MUST support all three parameter sets
The KEM interface follows the standard KeyGen(), Encaps(), Decaps() pattern
Constant-time implementation is required to prevent timing side-channels
Random number generation must use an approved DRBG (per SP 800-90A)
The decapsulation procedure includes an implicit rejection mechanism — if decapsulation fails, a pseudorandom shared secret is returned rather than an error, preventing chosen-ciphertext attacks

1.2 FIPS 204: ML-DSA (Module-Lattice-Based Digital Signature Algorithm)

What it specifies: FIPS 204 defines ML-DSA, the standardized version of CRYSTALS-Dilithium. ML-DSA is a general-purpose digital signature scheme intended to replace RSA-PSS, ECDSA, and EdDSA across all applications — code signing, certificate issuance, document signing, authentication tokens, and protocol handshakes.

Algorithm family: Module Learning With Errors and Module Short Integer Solution (MLWE/MSIS). Security relies on the hardness of finding short vectors in module lattices.

Approved parameter sets:

Parameter Set	NIST Security Level	Public Key Size	Signature Size	Secret Key Size
ML-DSA-44	2	1,312 bytes	2,420 bytes	2,560 bytes
ML-DSA-65	3	1,952 bytes	3,309 bytes	4,032 bytes
ML-DSA-87	5	2,592 bytes	4,627 bytes	4,896 bytes

Key design characteristics:

Deterministic or hedged signing: ML-DSA supports both fully deterministic signing (from the message and secret key alone) and hedged signing (incorporating additional randomness). The hedged mode provides fault-attack resistance — if an implementation’s internal state is partially compromised by a fault injection, the randomness prevents the fault from leaking key material
No hash-then-sign: ML-DSA signs the message directly (after internal hashing), not a pre-computed hash. The specification defines the complete hash-and-sign pipeline
Context strings: FIPS 204 introduces an optional context string parameter that binds signatures to a specific application context, preventing cross-protocol signature reuse

Implementation requirements:

Implementations MUST support all three parameter sets
Signature verification must be constant-time with respect to the public key (but may be variable-time with respect to the message, as messages are assumed public)
The signing procedure requires matrix operations over polynomial rings — implementations must handle the algebraic structure efficiently without introducing timing leaks
Rejection sampling is used during key generation and signing; implementations must handle variable-time rejection loops carefully

1.3 FIPS 205: SLH-DSA (Stateless Hash-Based Digital Signature Algorithm)

What it specifies: FIPS 205 defines SLH-DSA, the standardized version of SPHINCS+. SLH-DSA is a hash-based digital signature scheme that provides algorithmic diversity — its security relies solely on the properties of hash functions, not on structured lattice problems. If a catastrophic break is found against lattice-based schemes, SLH-DSA remains standing.

Algorithm family: Stateless hash-based signatures using a hypertree construction (a tree of Merkle trees built on WOTS+ and FORS one-time/few-time signature schemes).

Approved parameter sets:

SLH-DSA defines twelve parameter sets across two hash function instantiations (SHA-256 and SHAKE256) and two optimization targets (small signatures vs. fast signing/verification):

Parameter Set	Security Level	Signature Size	Public Key Size	Signing Speed	Verification Speed
SLH-DSA-SHA2-128s	1	7,856 bytes	32 bytes	Slow	Fast
SLH-DSA-SHA2-128f	1	17,088 bytes	32 bytes	Fast	Slow
SLH-DSA-SHA2-192s	3	16,224 bytes	48 bytes	Slow	Fast
SLH-DSA-SHA2-192f	3	35,664 bytes	48 bytes	Fast	Slow
SLH-DSA-SHA2-256s	5	29,792 bytes	64 bytes	Slow	Fast
SLH-DSA-SHA2-256f	5	49,856 bytes	64 bytes	Fast	Slow
SLH-DSA-SHAKE-128s	1	7,856 bytes	32 bytes	Slow	Fast
SLH-DSA-SHAKE-128f	1	17,088 bytes	32 bytes	Fast	Slow
SLH-DSA-SHAKE-192s	3	16,224 bytes	48 bytes	Slow	Fast
SLH-DSA-SHAKE-192f	3	35,664 bytes	48 bytes	Fast	Slow
SLH-DSA-SHAKE-256s	5	29,792 bytes	64 bytes	Slow	Fast
SLH-DSA-SHAKE-256f	5	49,856 bytes	64 bytes	Fast	Slow

The “s” variants optimize for small signatures (at the cost of slower signing), while the “f” variants optimize for fast operations (at the cost of larger signatures). The trade-off is significant — SLH-DSA-SHA2-128f signatures are over twice the size of SLH-DSA-SHA2-128s signatures.

Implementation requirements:

Implementations MUST support at least one parameter set per security level
Hash function implementations must be constant-time
The stateless design means no state management is required between signing operations — a critical advantage over stateful hash-based schemes like XMSS and LMS (see NIST SP 800-208 below)
SLH-DSA is explicitly recommended by NIST as the “conservative choice” for organizations that want defense-in-depth against lattice cryptanalysis breakthroughs

1.4 Standards Relationship Map

graph TB
    subgraph "NIST PQC Standards (August 2024)"
        FIPS203["FIPS 203<br/>ML-KEM<br/>(Key Encapsulation)"]
        FIPS204["FIPS 204<br/>ML-DSA<br/>(Digital Signatures)"]
        FIPS205["FIPS 205<br/>SLH-DSA<br/>(Hash-Based Signatures)"]
    end

    subgraph "Supporting Standards"
        SP800_208["SP 800-208<br/>XMSS & LMS<br/>(Stateful HBS)"]
        FIPS140["FIPS 140-3<br/>Cryptographic Module<br/>Validation"]
        SP800_227["SP 800-227<br/>PQC Migration<br/>Recommendations"]
    end

    subgraph "Government Mandates"
        CNSA2["CNSA 2.0<br/>NSA/CSS"]
        NSM10["NSM-10<br/>White House"]
        EO14028["EO 14028<br/>Cybersecurity"]
    end

    subgraph "Industry Frameworks"
        PCI["PCI DSS 4.0"]
        HIPAA["HIPAA"]
        FEDRAMP["FedRAMP"]
        SOC2["SOC 2"]
    end

    FIPS203 --> FIPS140
    FIPS204 --> FIPS140
    FIPS205 --> FIPS140
    SP800_208 --> FIPS140

    CNSA2 --> FIPS203
    CNSA2 --> FIPS204
    CNSA2 --> FIPS205
    NSM10 --> CNSA2
    EO14028 --> NSM10

    FIPS140 --> FEDRAMP
    FIPS140 --> PCI
    FIPS203 --> HIPAA
    FIPS204 --> SOC2

    style FIPS203 fill:#1a1a2e,stroke:#e94560,color:#eee
    style FIPS204 fill:#1a1a2e,stroke:#e94560,color:#eee
    style FIPS205 fill:#1a1a2e,stroke:#e94560,color:#eee
    style CNSA2 fill:#1a1a2e,stroke:#0f3460,color:#eee
    style NSM10 fill:#1a1a2e,stroke:#0f3460,color:#eee
    style EO14028 fill:#1a1a2e,stroke:#0f3460,color:#eee
    style FIPS140 fill:#1a1a2e,stroke:#16213e,color:#eee
    style SP800_208 fill:#1a1a2e,stroke:#16213e,color:#eee
    style SP800_227 fill:#1a1a2e,stroke:#16213e,color:#eee

2. CNSA 2.0 Timeline

The Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) is the NSA’s algorithm suite for protecting classified and sensitive U.S. government information. Published by the NSA’s Cybersecurity Directorate in September 2022 and updated through 2025, CNSA 2.0 replaces the original CNSA 1.0 suite with exclusively quantum-resistant algorithms and establishes binding transition deadlines for National Security Systems (NSS).

2.1 Algorithm Requirements

CNSA 2.0 mandates the following algorithms:

Function	CNSA 2.0 Algorithm	FIPS Standard	Minimum Parameter Set
Key Establishment	ML-KEM-1024	FIPS 203	Level 5 only
Digital Signatures	ML-DSA-87	FIPS 204	Level 5 only
Digital Signatures (software/firmware)	ML-DSA-87 or SLH-DSA-SHA2-256s	FIPS 204 / 205	Level 5 only
Symmetric Encryption	AES-256	FIPS 197	256-bit keys
Hashing	SHA-384 or SHA-512	FIPS 180-4	384-bit minimum

A critical detail: CNSA 2.0 mandates Level 5 parameter sets only. There is no allowance for ML-KEM-512, ML-KEM-768, ML-DSA-44, or ML-DSA-65 in National Security Systems. This is more conservative than NIST’s general guidance, which considers Level 1 and Level 3 parameter sets acceptable for most applications.

2.2 Transition Timeline

The CNSA 2.0 timeline establishes hard deadlines by system category. “Preferred” dates indicate when CNSA 2.0 algorithms should be the default; “Required” dates indicate when legacy algorithms must be fully removed.

Category	Description	Preferred By	Exclusively Required By
Software & Firmware Signing	Code signing for software updates, firmware images, boot sequences	2025	2030
Web Browsers & Servers	TLS for web traffic, HTTPS endpoints	2025	2030
Cloud Services & Environments	Cloud infrastructure, IaaS/PaaS/SaaS platforms	2025	2030
Networking Equipment	Routers, switches, firewalls, VPN concentrators, load balancers	2026	2030
Operating Systems	OS-level cryptographic services, kernel-level crypto, boot verification	2027	2033
Niche Equipment	Embedded systems, IoT devices, SCADA/ICS, specialized hardware	2027	2033
Custom Applications (new)	New applications under development	2025	2030
Custom Applications (existing)	Deployed applications requiring refactoring	2027	2033
Legacy Systems	Systems that cannot be upgraded and require replacement or encapsulation	2030	2033

2.3 What the Timeline Means in Practice

The 2025 “preferred” dates for software signing, web traffic, and cloud services are not aspirational targets — they are operational now. Organizations providing services to U.S. defense and intelligence agencies must already be offering CNSA 2.0 compliant options. The practical impact:

Vendors selling to DoD/IC: Your TLS endpoints must support ML-KEM-1024 and ML-DSA-87. If your product cannot negotiate post-quantum cipher suites, you are at risk of losing contract eligibility
Cloud service providers: FedRAMP High and DoD IL4/IL5/IL6 environments must support CNSA 2.0 algorithms. AWS, Azure, and GCP have all announced PQC support timelines aligned with these requirements
Software distributors: Code signing certificates and firmware signing keys for government-destined software must transition to ML-DSA-87 or SLH-DSA. This requires updates to signing infrastructure, key management, and certificate chains

gantt
    title CNSA 2.0 Transition Timeline
    dateFormat YYYY
    axisFormat %Y

    section Preferred
    Software & Firmware Signing    :done, 2025, 2025
    Web Browsers & Servers         :done, 2025, 2025
    Cloud Services                 :done, 2025, 2025
    Networking Equipment           :active, 2026, 2026
    Operating Systems              :2027, 2027
    Niche Equipment                :2027, 2027
    Legacy Systems                 :2030, 2030

    section Exclusively Required
    SW/FW, Web, Cloud, Network     :crit, 2030, 2030
    OS, Niche, Legacy              :crit, 2033, 2033

3. NSA Guidance and U.S. Government Mandates

3.1 CNSA 2.0 Advisory (September 2022)

The NSA’s Cybersecurity Directorate published the CNSA 2.0 advisory as an update to the original CNSA suite guidance from 2015. The advisory is not merely a recommendation — for National Security Systems (classified and sensitive U.S. government systems regulated under CNSSP-15), CNSA 2.0 compliance is mandatory.

Key elements of the advisory:

Harvest-now, decrypt-later (HNDL) acknowledgment: The NSA explicitly recognizes that adversaries are collecting encrypted traffic today for future decryption. This is the first official U.S. government acknowledgment that the quantum threat is not just theoretical — it is an active intelligence concern
No hybrid mode for NSS: Unlike NIST’s general guidance, which encourages hybrid classical/PQC approaches during transition, CNSA 2.0 mandates a direct transition to PQC-only for NSS. The rationale: hybrid modes add complexity and are unnecessary when Level 5 parameter sets provide sufficient security margin
Algorithm specificity: CNSA 2.0 names exact algorithms and parameter sets. There is no discretion to select Level 3 parameters for convenience — NSS must use ML-KEM-1024 and ML-DSA-87

3.2 National Security Memorandum 10 (NSM-10)

NSM-10, “Promoting United States Leadership in Quantum Computing While Mitigating Risks to Vulnerable Cryptographic Systems,” was issued by the White House on May 4, 2022. It is the foundational policy document driving the U.S. government’s PQC transition.

Key requirements:

Cryptographic inventory mandate: All federal agencies must complete a comprehensive inventory of their cryptographic systems, identifying which algorithms are in use, where they are deployed, and which systems handle sensitive data vulnerable to HNDL attacks
Prioritization framework: Agencies must prioritize systems for migration based on data sensitivity, system lifespan, and exposure to network-based collection
Annual progress reporting: Agency heads must submit annual reports on PQC migration progress to the National Manager for National Security Systems (the NSA Director) and to CISA
NIST coordination: NSM-10 directs NIST to complete PQC standardization and produce migration guidance — which NIST fulfilled with FIPS 203/204/205 and the ongoing SP 800-227 effort

3.3 Executive Order 14028

Executive Order 14028, “Improving the Nation’s Cybersecurity” (May 12, 2021), is the umbrella policy under which NSM-10 and subsequent PQC directives operate. While EO 14028 does not specifically address quantum threats, it establishes the framework for cryptographic modernization by mandating:

Zero trust architecture adoption across federal agencies
Encryption of data at rest and in transit using “strong” cryptographic standards
Software supply chain security requirements (SBOM mandates) that intersect with code signing migration
CISA’s role as the operational coordinator for civilian federal cybersecurity

The connection to PQC is direct: as NIST redefines what constitutes “strong” cryptographic standards to include quantum resistance, the EO 14028 mandate automatically extends to PQC compliance. Software supply chain requirements are particularly relevant — code signing with PQC algorithms directly supports the SBOM integrity verification mandated by EO 14028.

3.4 CISA Guidance

The Cybersecurity and Infrastructure Security Agency (CISA) has published several resources supporting the federal PQC transition:

“Post-Quantum Cryptography Initiative”: CISA’s dedicated PQC program provides guidance, tools, and coordination for federal civilian agencies
Quantum-Readiness Factsheet: Published jointly with NSA and NIST, this document outlines immediate steps organizations should take to prepare for PQC migration
Critical Infrastructure Outreach: CISA is engaging critical infrastructure sectors (energy, water, healthcare, financial services) on PQC migration planning through sector-specific guidance and the Sector Risk Management Agencies (SRMAs)
Vulnerability Disclosure: CISA has indicated that cryptographic vulnerabilities related to quantum threats may be incorporated into future Binding Operational Directives (BODs) for federal agencies

3.5 OMB Memorandum M-23-02

OMB M-23-02, “Migrating to Post-Quantum Cryptography” (November 2022), operationalizes NSM-10 for civilian federal agencies. Its key requirements:

Agencies must submit cryptographic system inventories to CISA and OMB
High-value assets and high-impact systems are prioritized for early migration
Agencies must develop PQC migration plans with milestones and funding requests
The memorandum explicitly calls out the need to assess HNDL risk for each system

4. European Standards and Guidance

The European PQC standards landscape is fragmented across multiple national agencies and EU-level bodies, each with distinct positions on algorithm selection, hybrid requirements, and migration timelines.

4.1 ETSI: TC CYBER QSC Working Group

The European Telecommunications Standards Institute (ETSI) established the Quantum-Safe Cryptography (QSC) working group under Technical Committee CYBER to address PQC standardization for European industry.

Key publications:

ETSI TS 103 744: Technical specification for quantum-safe hybrid key exchanges in TLS 1.3. Defines the protocol mechanics for combining classical and PQC key exchanges
ETSI TR 103 616: Technical report on migration strategies for quantum-safe cryptography. Provides a European-context migration framework
ETSI TR 103 823: Quantum-safe cryptography — threat and risk assessment. Analyzes the timeline for quantum threats and prioritizes system categories for migration
ETSI TS 104 015: Quantum-safe cryptography — algorithm catalogues and parameter recommendations for European deployment

ETSI’s position is generally aligned with NIST on algorithm selection (endorsing ML-KEM, ML-DSA, and SLH-DSA) but places stronger emphasis on hybrid modes during the transition period.

4.2 BSI (Germany): Federal Office for Information Security

The Bundesamt fur Sicherheit in der Informationstechnik (BSI) is one of the most technically rigorous national cybersecurity agencies in Europe, and its PQC guidance has significant influence across the EU.

Algorithm recommendations:

BSI endorses ML-KEM (all parameter sets), ML-DSA (all parameter sets), and SLH-DSA
BSI recommends FrodoKEM as an alternative to ML-KEM for high-assurance applications. FrodoKEM is based on unstructured Learning With Errors (LWE), which avoids the ring/module algebraic structure that some cryptographers consider a potential attack surface. FrodoKEM was not selected by NIST but remains a BSI-approved option
For hash-based signatures, BSI additionally recommends XMSS and LMS (per NIST SP 800-208) for firmware signing and other bounded-use cases

Migration timeline:

BSI TR-02102 (Technical Guidelines for Cryptographic Mechanisms) has been updated to include PQC algorithms
BSI recommends beginning PQC migration immediately and completing it for critical infrastructure by 2030
Hybrid mode is mandatory during the transition period in BSI’s guidance — organizations must run classical + PQC in parallel until confidence in PQC implementations matures

4.3 ANSSI (France): National Agency for the Security of Information Systems

The Agence nationale de la securite des systemes d’information (ANSSI) has taken the most cautious position among major European agencies.

Hybrid-only position:

ANSSI’s position paper on PQC (published March 2022, updated January 2024) mandates hybrid cryptography for all French government systems and critical infrastructure
The rationale: PQC algorithms have not undergone sufficient real-world cryptanalysis to justify full trust. Classical algorithms (RSA, ECC) have decades of cryptanalytic confidence. Hybrid mode preserves classical security guarantees while adding quantum resistance
ANSSI will not approve PQC-only configurations until at least 2030, and potentially later depending on cryptanalytic developments
This position creates a tension with CNSA 2.0, which mandates PQC-only for U.S. NSS. Organizations operating across both jurisdictions must support both modes

Security recommendations:

Minimum Level 3 (ML-KEM-768, ML-DSA-65) for government applications
Level 5 preferred for classified or long-lifetime data
SLH-DSA recommended as a backup signature scheme regardless of primary algorithm choice

4.4 ENISA (EU Agency for Cybersecurity)

The European Union Agency for Cybersecurity (ENISA) plays a coordinating role in PQC standardization across the EU:

PQC Integration Study (2022): ENISA published a comprehensive study on the challenges of integrating PQC into existing European digital infrastructure, covering protocols, hardware constraints, and migration risks
Algorithm Recommendations: ENISA’s technical recommendations align with NIST selections but emphasize the need for European cryptographic sovereignty and continued investment in alternative algorithm families
NIS2 Directive Intersection: The NIS2 Directive (effective October 2024) requires “essential” and “important” entities to implement “state-of-the-art” security measures. As PQC becomes state-of-the-art, NIS2-regulated entities will face compliance pressure to adopt quantum-resistant cryptography
Certification Schemes: ENISA is developing European Cybersecurity Certification Schemes (under the Cybersecurity Act) that will eventually incorporate PQC algorithm requirements

4.5 European Commission Recommendation on PQC (April 2024)

On April 11, 2024, the European Commission published its first formal Recommendation on a Coordinated Implementation Roadmap for the transition to Post-Quantum Cryptography. This is a non-binding but politically significant document that:

Calls on all EU Member States to develop national PQC migration strategies by end of 2024
Recommends a coordinated EU approach to cryptographic inventory and risk assessment
Endorses the NIST-selected algorithms (ML-KEM, ML-DSA, SLH-DSA) as acceptable for EU use
Recommends hybrid approaches during the transition period, aligning with ANSSI and BSI positions
Directs ENISA (the EU Agency for Cybersecurity) to develop PQC migration guidance for critical infrastructure operators under the NIS2 Directive
Acknowledges the HNDL threat and urges immediate action for systems protecting data with long confidentiality requirements

The Recommendation also establishes a Post-Quantum Cryptography Coordination Group under the European Commission to harmonize national approaches and avoid fragmentation.

4.6 EU Standards Comparison

Aspect	NIST (U.S.)	BSI (Germany)	ANSSI (France)	EU Commission
Approved KEMs	ML-KEM	ML-KEM, FrodoKEM	ML-KEM (hybrid only)	ML-KEM
Approved Signatures	ML-DSA, SLH-DSA	ML-DSA, SLH-DSA, XMSS/LMS	ML-DSA, SLH-DSA (hybrid only)	ML-DSA, SLH-DSA
Hybrid Requirement	Encouraged, not mandatory	Mandatory during transition	Mandatory until 2030+	Recommended
Minimum Security Level	Level 1 acceptable	Level 1 acceptable	Level 3 minimum	No specification
Migration Deadline	CNSA 2.0 timeline	2030 for critical infrastructure	No fixed deadline	National strategies by end 2024
FrodoKEM Position	Not standardized	Recommended alternative	Not specifically addressed	Not specifically addressed

5. NIST SP 800-208: Stateful Hash-Based Signatures

NIST SP 800-208, “Recommendation for Stateful Hash-Based Signature Schemes,” was published in October 2020 — predating the FIPS 203/204/205 standards by nearly four years. It defines two stateful hash-based signature schemes:

5.1 XMSS (eXtended Merkle Signature Scheme)

Defined in RFC 8391
Single Merkle tree construction
Suitable for scenarios with bounded signing operations (the tree height determines the maximum number of signatures)
Parameter sets: XMSS-SHA2_10_256 (1,024 signatures), XMSS-SHA2_16_256 (65,536 signatures), XMSS-SHA2_20_256 (1,048,576 signatures)
Multi-tree variant (XMSS^MT) supports larger signature counts

5.2 LMS (Leighton-Micali Signature Scheme)

Defined in RFC 8554
Hierarchical signature scheme using Merkle trees
Parameter sets defined by hash function, tree height, and Winternitz parameter
LMS/HSS (Hierarchical Signature System) extends LMS to support larger signature counts through tree layering

5.3 Critical Operational Constraint: State Management

The defining characteristic of XMSS and LMS — and the reason they are separate from SLH-DSA — is that they are stateful. Each signature consumes a one-time key from the Merkle tree, and the signer must track which keys have been used. Reusing a one-time key catastrophically breaks security, allowing signature forgery.

This means:

State must be persisted reliably: If the signing state is lost (system crash, backup restoration, VM rollback), the signer risks key reuse
State must not be cloned: Running two instances of a signer with the same key and state will inevitably produce key reuse
HSMs are strongly recommended: Hardware security modules provide the atomic state management required for safe XMSS/LMS operation

5.4 XMSS vs. LMS vs. SLH-DSA Decision Matrix

Criterion	XMSS	LMS	SLH-DSA
Statefulness	Stateful	Stateful	Stateless
Signature Size (Level 1)	~2,500 bytes	~1,600-4,600 bytes	7,856-17,088 bytes
Signing Speed	Fast	Fast	Slow (s variants)
Verification Speed	Fast	Fast	Moderate
State Management Risk	Key reuse = catastrophic	Key reuse = catastrophic	No state risk
NIST Standard	SP 800-208	SP 800-208	FIPS 205
FIPS 140-3 Validated	Yes (multiple vendors)	Yes (multiple vendors)	In process
Best Use Case	Firmware signing, secure boot	Root CA, code signing	General purpose

5.5 Recommended Use Cases

SP 800-208 recommends XMSS and LMS for scenarios where:

The number of signing operations is predictable and bounded (firmware signing, root CA issuance, secure boot)
The signing infrastructure is centralized and state management is feasible
The organization wants quantum-resistant signatures available before FIPS 203/204/205 implementations are FIPS 140-3 validated
High-assurance environments where hash-only security assumptions are preferred

SP 800-208 algorithms have been available for FIPS 140-3 validation since 2020, giving them a head start over ML-DSA and SLH-DSA. Several HSM vendors already offer FIPS 140-3 validated XMSS and LMS implementations — making them the only production-ready, FIPS-validated, quantum-resistant signature algorithms available today.

5.6 Relationship to FIPS 205

SP 800-208 and FIPS 205 serve complementary roles:

SP 800-208 (XMSS/LMS): For constrained, centralized signing operations where state management is feasible and small signatures are critical. Already FIPS 140-3 validated. The right choice for firmware signing, secure boot chains, and root CA operations
FIPS 205 (SLH-DSA): For general-purpose signing where statelessness is required — TLS handshakes, end-entity certificates, email signing, document signing, and any scenario where multiple signing instances might operate concurrently

Organizations should deploy both: XMSS or LMS for infrastructure signing (boot, firmware, root CAs) and SLH-DSA or ML-DSA for application-level signing. This layered approach provides defense-in-depth and leverages the strengths of each scheme.

6. FIPS 140-3 Validation for PQC

The Cryptographic Module Validation Program (CMVP), jointly operated by NIST and the Canadian Centre for Cyber Security (CCCS), validates cryptographic implementations against FIPS 140-3. For any algorithm to be used in U.S. federal systems, it must be implemented in a FIPS 140-3 validated module. This creates a critical dependency: even after FIPS 203/204/205 are published, PQC algorithms cannot be deployed in regulated environments until validated modules exist.

6.1 The CMVP Process

The FIPS 140-3 validation process involves:

Algorithm validation: The implementation must first pass algorithm-level testing through the Cryptographic Algorithm Validation Program (CAVP). NIST publishes Algorithm Validation Test Requirements (AVTR) documents that define the test vectors and procedures. CAVP test requirements for ML-KEM, ML-DSA, and SLH-DSA were published in Q1 2025
Module validation: The complete cryptographic module (which may contain multiple algorithms) is tested by an accredited Cryptographic and Security Testing (CST) laboratory against the FIPS 140-3 requirements (security levels 1-4, covering physical security, key management, self-tests, etc.)
Validation report: The CST lab submits a test report to CMVP for review
Certificate issuance: CMVP reviews the report and, if satisfactory, issues a validation certificate

Typical timeline: The end-to-end process historically takes 12-24 months from initial lab engagement to certificate issuance. CMVP has acknowledged the PQC urgency and is working to streamline the process, but the backlog is substantial.

6.2 Current Validation Status (Early 2026)

Algorithm	CAVP Test Requirements	First CAVP Validations	First CMVP Module Validations	Status
ML-KEM	Published (Q1 2025)	Available (mid 2025)	In process	Labs testing modules
ML-DSA	Published (Q1 2025)	Available (mid 2025)	In process	Labs testing modules
SLH-DSA	Published (Q1 2025)	Available (mid 2025)	In process	Labs testing modules
XMSS	Published (2020)	Available	Available	Validated modules exist
LMS	Published (2020)	Available	Available	Validated modules exist

6.3 Timeline for PQC Module Validation

graph LR
    A["Aug 2024<br/>FIPS 203/204/205<br/>Published"] --> B["Q1 2025<br/>CAVP Test<br/>Requirements"]
    B --> C["Mid 2025<br/>First CAVP<br/>Validations"]
    C --> D["Late 2025 -<br/>Mid 2026<br/>First Module<br/>Submissions"]
    D --> E["Mid 2026 -<br/>2027<br/>First CMVP<br/>Certificates"]

    style A fill:#1a1a2e,stroke:#e94560,color:#eee
    style B fill:#1a1a2e,stroke:#e94560,color:#eee
    style C fill:#1a1a2e,stroke:#0f3460,color:#eee
    style D fill:#1a1a2e,stroke:#0f3460,color:#eee
    style E fill:#1a1a2e,stroke:#16213e,color:#eee

6.4 Impact on Procurement

The gap between FIPS standard publication and FIPS 140-3 validated implementations creates a procurement paradox:

CNSA 2.0 “preferred” dates (2025) precede validated module availability. Organizations cannot simultaneously comply with CNSA 2.0’s preference for PQC algorithms and with FIPS 140-3 validation requirements
NIST has addressed this with interim guidance: CMVP has indicated that implementations using FIPS 203/204/205 algorithms may be submitted as part of FIPS 140-3 modules during the validation queue period. Agencies are advised to procure products that implement FIPS 203/204/205 algorithms and are “in process” for validation
The “FIPS Inside” gap: Many procurement vehicles (GSA Schedule, DoD UC APL) require FIPS 140-3 validated modules. Vendors without validated PQC modules face a competitive disadvantage even if their implementations are technically correct
Transition certificates: CMVP is exploring mechanisms for expedited validation of PQC algorithm additions to already-validated modules, reducing the time required for vendors to add ML-KEM and ML-DSA to existing FIPS 140-3 certificates

6.5 FIPS 140-3 Security Levels and PQC

FIPS 140-3 defines four security levels for cryptographic modules, each adding requirements beyond the previous:

Level 1: Basic requirements — approved algorithms, no physical security. Software-only modules qualify. Most PQC library implementations will target Level 1 initially
Level 2: Role-based authentication, tamper-evidence (tamper-evident coatings or seals). Requires an operator to authenticate before accessing cryptographic functions
Level 3: Identity-based authentication, tamper-resistance (active tamper response). The module must detect and respond to physical intrusion attempts. HSMs typically target Level 3
Level 4: Complete physical protection envelope, environmental failure protection. The module resists all forms of physical attack. Rarely required outside military and intelligence applications

For PQC specifically, the interaction between FIPS 140-3 security levels and NIST PQC security levels (1-5) is distinct — they measure different things. FIPS 140-3 levels address implementation security (physical tamper resistance, key management, self-tests). NIST PQC security levels address algorithm security (computational hardness of breaking the scheme). A Level 1 FIPS 140-3 module can implement Level 5 PQC algorithms, and vice versa.

6.6 Side-Channel Testing Requirements

FIPS 140-3 introduced non-invasive attack resistance requirements that are particularly relevant for PQC:

Level 3 and above: Modules must demonstrate resistance to non-invasive attacks, which includes timing side-channels, power analysis, and electromagnetic emanation analysis
PQC-specific concerns: Lattice-based algorithms (ML-KEM, ML-DSA) involve operations like Number Theoretic Transforms (NTTs) and polynomial arithmetic that can leak information through timing and power traces. Constant-time implementations are mandatory but difficult to verify
Testing laboratories: CST labs are developing specialized PQC side-channel testing procedures. The test methodology for PQC side-channel resistance is still maturing, which may contribute to longer validation timelines

6.7 Practical Guidance for Procurement Officers

Accept “in process” for PQC: Require vendors to demonstrate FIPS 203/204/205 compliance and active CMVP submission, not completed validation
Verify CAVP results: Algorithm-level validation (CAVP) is achievable before full module validation. Require CAVP certificates for PQC algorithms
Check the CMVP MIP list: NIST publishes a Modules In Process (MIP) list showing which vendors have submitted for validation
Require crypto agility: Even after validation, ensure products can update algorithm implementations without full re-validation (CMVP allows certain algorithm updates as maintenance actions)
Plan for re-validation cycles: As PQC implementations mature and potential vulnerabilities are addressed, modules may require updated validations. Budget for ongoing validation maintenance

7. Other International Standards Bodies

7.1 ISO/IEC JTC 1/SC 27

The ISO/IEC Joint Technical Committee 1, Subcommittee 27 (Information security, cybersecurity, and privacy protection) is developing international standards for PQC:

ISO/IEC 18033-2 (Amendment): Adding ML-KEM to the international standard for encryption algorithms
ISO/IEC 14888-3 (Amendment): Adding ML-DSA and SLH-DSA to the international standard for digital signatures
ISO/IEC CD 24759: Updated testing methodology that will accommodate PQC algorithm validation

ISO standardization typically lags NIST by 2-3 years but is critical for organizations operating under international regulatory regimes that reference ISO standards rather than NIST FIPS.

7.2 Japan: CRYPTREC

The Cryptography Research and Evaluation Committees (CRYPTREC) maintains Japan’s recommended cryptographic algorithms list:

CRYPTREC has established a PQC task force to evaluate NIST-selected algorithms for inclusion in the CRYPTREC Ciphers List
Japan’s National Center of Incident Readiness and Strategy for Cybersecurity (NISC) has issued preliminary guidance on PQC migration for critical infrastructure
Japanese financial institutions (regulated by the Financial Services Agency) are expected to follow CRYPTREC recommendations

7.3 South Korea: KISA

The Korea Internet & Security Agency (KISA) has been active in PQC research and is developing Korean Cryptographic Algorithm (KCA) standards that include post-quantum schemes. South Korea’s approach closely tracks NIST selections, with additional evaluation of domestically developed algorithms.

8. Industry Compliance Mapping

The transition to PQC intersects with every major compliance framework. This section maps the specific requirements and implications for each framework.

7.1 PCI DSS 4.0

The Payment Card Industry Data Security Standard version 4.0 (effective March 2025, with some requirements having extended compliance dates to March 2026) governs the protection of payment card data.

Relevant requirements:

Requirement 2.2.7: Encrypt all non-console administrative access using strong cryptography
Requirement 3.5: Protect stored account data with strong cryptography
Requirement 4.2: Protect cardholder data with strong cryptography during transmission over open, public networks
Requirement 12.3.3: Perform a targeted risk analysis for any cryptographic cipher suites and protocols in use

PQC implications:

PCI DSS defines “strong cryptography” by reference to industry standards and NIST guidance. As NIST designates pre-quantum algorithms as deprecated (a process that will accelerate once CRQC timelines become clearer), PCI DSS assessors will begin flagging RSA and ECC-only configurations:

Immediate action: Conduct the cryptographic inventory required by Requirement 12.3.3, specifically identifying systems that handle cardholder data and the algorithms they use
Medium-term (2025-2027): Deploy hybrid TLS configurations for cardholder data transmission. PCI QSAs (Qualified Security Assessors) are not yet requiring PQC, but forward-looking organizations are documenting their migration plans as evidence for Requirement 12.3.3
Long-term (2028+): Expect PCI SSC (Security Standards Council) to issue supplemental guidance or a future PCI DSS version that explicitly requires quantum-resistant algorithms for cardholder data protection

7.2 HIPAA

The Health Insurance Portability and Accountability Act requires covered entities and business associates to implement technical safeguards for electronic Protected Health Information (ePHI).

Relevant provisions:

§164.312(a)(2)(iv): Encryption and decryption — implement a mechanism to encrypt and decrypt ePHI
§164.312(e)(1): Transmission security — implement technical security measures to guard against unauthorized access to ePHI being transmitted over an electronic communications network
§164.312(e)(2)(ii): Encryption — implement a mechanism to encrypt ePHI whenever deemed appropriate

PQC implications:

HIPAA is technology-neutral — it does not mandate specific algorithms. The HIPAA Security Rule references NIST guidance for “reasonable and appropriate” safeguards. As NIST guidance evolves to require PQC:

HNDL risk is acute for healthcare: Medical records have multi-decade confidentiality requirements. Patient data collected today must remain confidential through the patient’s lifetime. An adversary harvesting encrypted ePHI today can decrypt it once a CRQC becomes available — this is a concrete HIPAA breach scenario
Covered entities should assess HNDL risk now: Document which ePHI transmission and storage systems use vulnerable algorithms and prioritize migration based on data sensitivity and retention periods
Business Associate Agreements (BAAs): Organizations should begin including PQC migration requirements in BAAs, ensuring that third-party processors commit to quantum-resistant encryption for ePHI

7.3 FedRAMP

The Federal Risk and Authorization Management Program governs the security assessment of cloud services used by U.S. federal agencies.

Relevant requirements:

FedRAMP mandates FIPS 140-3 validated cryptographic modules for all encryption operations
FedRAMP Moderate and High baselines incorporate NIST SP 800-53 controls, including SC-12 (Cryptographic Key Establishment and Management) and SC-13 (Cryptographic Protection)
FedRAMP continuous monitoring requires ongoing compliance with evolving NIST guidance

PQC implications:

FedRAMP High and DoD IL4+: These authorization levels are directly affected by CNSA 2.0 requirements. Cloud service providers holding these authorizations must demonstrate PQC migration plans and timeline alignment with CNSA 2.0
3PAO assessments: Third-party assessment organizations will begin evaluating PQC readiness as part of annual assessments. The SC-12 and SC-13 controls will be interpreted against NIST’s PQC migration guidance (SP 800-227)
CSP competitive pressure: Cloud providers that achieve FIPS 140-3 validated PQC implementations first will have a significant advantage in federal marketplace competitions. AWS, Google Cloud, and Microsoft Azure have all publicly committed to PQC roadmaps

7.4 SOC 2

The System and Organization Controls 2 framework, based on the AICPA Trust Services Criteria, evaluates controls relevant to security, availability, processing integrity, confidentiality, and privacy.

Relevant criteria:

CC6.1: Logical and physical access controls — includes encryption of data at rest and in transit
CC6.7: Encryption and other security controls for data in transit
CC6.8: Controls to prevent unauthorized changes to information in transit

PQC implications:

SOC 2 is principles-based, not prescriptive. Auditors evaluate whether controls are “suitable” — and the definition of suitable cryptographic controls will evolve:

Type II reports: Organizations should begin documenting PQC migration plans within their control descriptions. Auditors reviewing cryptographic controls will increasingly ask about quantum readiness
User entity considerations: SOC 2 reports include complementary user entity controls. Organizations relying on service providers should review SOC 2 reports for PQC migration disclosures
Competitive differentiation: Organizations that proactively address PQC in their SOC 2 reports signal security maturity to customers evaluating vendors

The EU General Data Protection Regulation requires “appropriate technical and organisational measures” for data protection, including encryption.

Relevant articles:

Article 5(1)(f): Integrity and confidentiality — personal data must be processed with appropriate security
Article 25: Data protection by design and by default
Article 32: Security of processing — implement measures including encryption of personal data

PQC implications:

Long-term data protection: GDPR requires protection appropriate to the risk. For data with long confidentiality requirements (health data, financial data, data about minors), the HNDL threat represents a quantifiable risk that should be addressed in Data Protection Impact Assessments (DPIAs)
Supervisory authority guidance: The European Data Protection Board (EDPB) has not yet issued specific PQC guidance, but the European Commission’s April 2024 Recommendation signals that PQC readiness is on the regulatory radar
Cross-border transfers: Organizations using encryption to protect personal data during cross-border transfers (as a supplemental measure under Schrems II) should ensure that encryption remains effective against state-level adversaries — which will eventually require PQC

7.6 Financial Services

Financial services face PQC requirements from multiple regulatory bodies and industry standards.

SWIFT Customer Security Programme (CSP):

SWIFT’s CSP mandates encryption of SWIFT-related data in transit and at rest
SWIFT has published preliminary guidance on quantum threats to financial messaging
The long-lived nature of financial records and the systemic risk of a SWIFT compromise make PQC migration a priority for financial institutions

Basel III / Basel IV Operational Risk:

The Basel framework includes operational risk capital requirements that cover technology risk
Regulators are beginning to consider quantum computing as an emerging operational risk
Banks should assess PQC migration costs within their operational risk framework and capital planning

OCC / FFIEC Guidance (U.S.):

The Federal Financial Institutions Examination Council (FFIEC) IT Examination Handbook references NIST standards for cryptographic requirements
The Office of the Comptroller of the Currency (OCC) has signaled awareness of quantum threats in supervisory communications
Expect examination procedures to include PQC readiness assessment within 2-3 years

SEC Cybersecurity Disclosure Rules:

The SEC’s 2023 cybersecurity disclosure rules (Form 8-K for material incidents, annual Regulation S-K Item 106 disclosure for risk management) create a disclosure obligation for material quantum-related risks
Organizations that assess HNDL risk as material must disclose their risk management approach, which should include PQC migration plans
Public companies should assess whether quantum risk rises to the level of material risk requiring Item 106 disclosure — for financial institutions and healthcare companies handling long-lived data, the answer is increasingly yes

Insurance Industry (NAIC):

The National Association of Insurance Commissioners (NAIC) Insurance Data Security Model Law references NIST standards for cryptographic requirements
State-level adoption of the NAIC model law creates regulatory obligations that will track NIST PQC guidance
Cyber insurance underwriters are beginning to include quantum readiness in risk assessment questionnaires — organizations without PQC migration plans may face higher premiums or coverage exclusions as quantum computing timelines become clearer

7.7 Compliance Framework Summary

Framework	PQC Requirement Status	Action Required Now	Expected Hard Deadline
CNSA 2.0	Mandatory for NSS	Deploy ML-KEM-1024, ML-DSA-87	2025-2033 (by category)
FedRAMP	Tied to NIST/CNSA 2.0	Migration plans; FIPS 140-3 PQC modules	Aligned with CNSA 2.0
PCI DSS 4.0	Not yet explicit	Cryptographic inventory (Req 12.3.3)	TBD (likely 2028+)
HIPAA	Technology-neutral, NIST-referenced	HNDL risk assessment for ePHI	TBD (follows NIST)
SOC 2	Principles-based	Document PQC plans in control descriptions	Evolving
GDPR	Risk-based, technology-neutral	DPIA for long-lived personal data	No fixed date
SWIFT CSP	Preliminary guidance	Monitor SWIFT quantum guidance	TBD
Basel III/IV	Emerging consideration	Include in operational risk assessment	TBD

9. Compliance Mapping by Action Priority

For organizations navigating multiple frameworks simultaneously, here is a prioritized action map:

9.1 Immediate Actions (2025-2026)

Complete cryptographic inventory — Required by NSM-10 (federal), PCI DSS 4.0 Req 12.3.3, and recommended by all frameworks. Identify every algorithm, key length, and protocol in use. See Migration Strategies & Crypto Agility for inventory methodologies
Assess HNDL exposure — Classify data by confidentiality lifetime. Any data that must remain confidential for 10+ years is at risk if encrypted with RSA or ECC today
Enable hybrid TLS — Deploy ML-KEM + X25519 hybrid key exchange on public-facing TLS endpoints. See PQC in Protocols for implementation details
Update procurement language — Require vendors to demonstrate PQC roadmaps and FIPS 203/204/205 compliance (or active CMVP submission)
Begin code signing migration — Transition software and firmware signing to ML-DSA-87 or SLH-DSA, especially for government-destined products

9.2 Medium-Term Actions (2026-2028)

Deploy PQC in production — Move from hybrid/experimental to production PQC deployments based on FIPS 140-3 validated modules as they become available
Update compliance documentation — Revise security policies, BAAs, DPIAs, and SOC 2 control descriptions to reflect PQC deployment
Certificate infrastructure migration — Transition internal PKI to issue PQC certificates (ML-DSA). See PQC in Protocols for certificate format details
Networking equipment refresh — Align router, switch, firewall, and VPN refresh cycles with CNSA 2.0 networking equipment deadline (2026 preferred)
Staff training — Ensure security teams, auditors, and procurement officers understand PQC requirements across applicable frameworks

9.3 Long-Term Actions (2028-2033)

Eliminate legacy algorithms — Remove RSA, ECC, and classical Diffie-Hellman from all systems per CNSA 2.0 “exclusively required” dates
Address niche and legacy systems — Plan for embedded systems, SCADA/ICS, and other constrained environments that require hardware replacement or encapsulation strategies
Continuous compliance monitoring — Implement automated cryptographic monitoring to detect algorithm drift and ensure ongoing compliance across frameworks
Prepare for algorithm evolution — The PQC landscape will continue evolving. HQC standardization, new signature schemes from NIST’s additional signatures competition, and potential algorithm breaks will require ongoing adaptation. Crypto agility is a permanent operational requirement, not a one-time migration

9.4 Compliance Checklist by Role

For CISOs and Security Leaders:

Assign a PQC migration program owner with executive sponsorship
Complete cryptographic inventory across all business units
Assess HNDL risk for data with >10-year confidentiality requirements
Establish a PQC migration budget line item in cybersecurity spend
Brief the board on quantum risk and regulatory timeline
Review cyber insurance policies for quantum-related exclusions

For Security Architects:

Evaluate crypto agility of current architecture (see Migration Strategies)
Design hybrid TLS deployment for external-facing services
Plan PKI migration to PQC certificates (dual-certificate or composite approach)
Assess HSM fleet for PQC algorithm support and firmware upgrade paths
Prototype ML-KEM key exchange in non-production environments
Document algorithm-specific deployment constraints (key sizes, bandwidth impact)

For Compliance Officers:

Map current compliance obligations to PQC requirements (use Section 8 above)
Update risk registers with quantum computing threat entries
Prepare PQC migration evidence packages for upcoming audits
Review third-party vendor contracts for cryptographic requirements
Engage QSAs/3PAOs on PQC readiness assessment expectations
Monitor regulatory bodies for updated PQC guidance

For Procurement Officers:

Add PQC requirements to RFP/RFQ templates
Require vendor PQC roadmaps as evaluation criteria
Verify FIPS 140-3 validation status (or active CMVP submission) for PQC
Include crypto agility requirements in technology acquisition standards
Align hardware refresh cycles with CNSA 2.0 deadlines

10. Key Takeaways

FIPS 203/204/205 are published and final. The algorithms are standardized. The standards are not draft, not provisional, and not optional for federal systems. ML-KEM for key establishment, ML-DSA for general-purpose signatures, SLH-DSA for conservative hash-based signatures
CNSA 2.0 deadlines are now. The 2025 “preferred” dates for software signing, web traffic, and cloud services are active. Organizations in the defense and intelligence supply chain must already be offering PQC-capable products
Europe requires hybrid. BSI and ANSSI mandate hybrid classical/PQC during the transition period. Organizations operating globally must support both PQC-only (for CNSA 2.0) and hybrid (for European compliance)
FIPS 140-3 validation is the bottleneck. Standards are published, but validated implementations are still working through the CMVP pipeline. Accept “in process” for procurement decisions and require CAVP algorithm certificates as an interim measure
Every compliance framework will eventually require PQC. The timeline varies — CNSA 2.0 is mandatory now, FedRAMP follows immediately, PCI DSS and HIPAA will follow NIST guidance, and GDPR’s risk-based approach will incorporate HNDL risk. The question is not whether your framework will require PQC, but when
The cryptographic inventory is the universal first step. Every framework, every jurisdiction, every guidance document starts with the same requirement: know what cryptography you are using and where. If you do nothing else this quarter, complete your inventory. See Migration Strategies & Crypto Agility for a detailed framework

11. Navigating Jurisdictional Conflicts

Organizations operating globally face a fundamental tension: different jurisdictions impose contradictory requirements. The most significant conflicts:

CNSA 2.0 (PQC-only) vs. ANSSI/BSI (hybrid mandatory):

CNSA 2.0 for NSS mandates pure PQC — no classical fallback. ANSSI mandates hybrid — classical must be present. An organization providing services to both U.S. DoD and French government agencies must support both configurations simultaneously
Solution: Implement crypto-agile systems that can toggle between PQC-only and hybrid modes based on connection context, client identity, or policy configuration

NIST Level 1 (acceptable) vs. CNSA 2.0 Level 5 (mandatory) vs. ANSSI Level 3 (minimum):

A single product cannot satisfy all three by picking one parameter set. The product must support multiple parameter sets and select based on the regulatory context
Solution: Implement all parameter sets and use negotiation or policy-based selection

Timeline divergence:

CNSA 2.0 demands PQC deployment now (2025 preferred). EU guidance calls for national strategies by end 2024 with no hard migration deadline. ISO standardization is 2-3 years behind NIST
Solution: Align to the most aggressive timeline (CNSA 2.0) and document compliance against all applicable frameworks. Early adoption never creates compliance problems — late adoption does

Overview

1. NIST FIPS Standards for PQC

1.1 FIPS 203: ML-KEM (Module-Lattice-Based Key Encapsulation Mechanism)

1.2 FIPS 204: ML-DSA (Module-Lattice-Based Digital Signature Algorithm)

1.3 FIPS 205: SLH-DSA (Stateless Hash-Based Digital Signature Algorithm)

1.4 Standards Relationship Map

2. CNSA 2.0 Timeline

2.1 Algorithm Requirements

2.2 Transition Timeline

2.3 What the Timeline Means in Practice

3. NSA Guidance and U.S. Government Mandates

3.1 CNSA 2.0 Advisory (September 2022)

3.2 National Security Memorandum 10 (NSM-10)

3.3 Executive Order 14028

3.4 CISA Guidance

3.5 OMB Memorandum M-23-02

4. European Standards and Guidance

4.1 ETSI: TC CYBER QSC Working Group

4.2 BSI (Germany): Federal Office for Information Security

4.3 ANSSI (France): National Agency for the Security of Information Systems

4.4 ENISA (EU Agency for Cybersecurity)

4.5 European Commission Recommendation on PQC (April 2024)

4.6 EU Standards Comparison

5. NIST SP 800-208: Stateful Hash-Based Signatures

5.1 XMSS (eXtended Merkle Signature Scheme)

5.2 LMS (Leighton-Micali Signature Scheme)

5.3 Critical Operational Constraint: State Management

5.4 XMSS vs. LMS vs. SLH-DSA Decision Matrix

5.5 Recommended Use Cases

5.6 Relationship to FIPS 205

6. FIPS 140-3 Validation for PQC

6.1 The CMVP Process

6.2 Current Validation Status (Early 2026)

6.3 Timeline for PQC Module Validation

6.4 Impact on Procurement

6.5 FIPS 140-3 Security Levels and PQC

6.6 Side-Channel Testing Requirements

6.7 Practical Guidance for Procurement Officers

7. Other International Standards Bodies

7.1 ISO/IEC JTC 1/SC 27

7.2 Japan: CRYPTREC

7.3 South Korea: KISA

8. Industry Compliance Mapping

7.1 PCI DSS 4.0

7.2 HIPAA

7.3 FedRAMP

7.4 SOC 2

7.5 GDPR

7.6 Financial Services

7.7 Compliance Framework Summary

9. Compliance Mapping by Action Priority

9.1 Immediate Actions (2025-2026)

9.2 Medium-Term Actions (2026-2028)

9.3 Long-Term Actions (2028-2033)

9.4 Compliance Checklist by Role

10. Key Takeaways

11. Navigating Jurisdictional Conflicts

Further Reading