PQC Migration for Federal Agencies—Mandates, Architecture, and an Actionable Playbook (Q13b)
This session proposes a technical, implementation-focused briefing and working session that equips federal cybersecurity and infrastructure teams to operationalize post-quantum cryptography (PQC) in response to U.S. Government direction. OMB Memorandum M-23-02 directs agencies (excluding National Security Systems) to begin transitioning by producing a prioritized inventory of cryptographic systems and reporting it annually through 2035, explicitly noting the risk that encrypted data may be recorded now and later decrypted by a future cryptanalytically relevant quantum computer (the “harvest now, decrypt later” threat). In parallel, NSA’s CNSA Suite 2.0 provides quantum-resistant requirements and adoption timelines for NSS, including mandated new-acquisition compliance starting in 2027 and fielded transition milestones through 2030–2031.
Government Drivers Covered (Technical Interpretation): OMB M-23-02: scope definition, inventory criteria (high impact/HVA/CRQC-vulnerable, and data mission-sensitive in 2035), required reporting elements, and annual submission expectations. CISA automation strategy: how agencies are expected to useAutomated Cryptography Discovery and Inventory (ACDI) capabilities, integrate with CDM, and report via CyberScope/FISMA metrics as requirements evolve. NSA CNSA 2.0: compliance boundaries for NSS, algorithm choices, and transition schedule; distinction between NIST standards for general government and NSA requirements for NSS. Quantum Computing Cybersecurity Preparedness Act (context): why agencies have accelerated discovery, inventory, and migration planning (noting that some industry guidance cites aggressive targets).
1. Quick Overview PQC standards and nomenclature: NIST standardized primitives:ML-KEM (FIPS 203) for key encapsulation;ML-DSA (FIPS 204) andSLH-DSA (FIPS 205) for digital signatures.
2.Agency playbook for M-23-02 compliance (inventory → migration): What must be inventoried and reported, including the 9 required data elements per cryptographic system (FISMA system ID, FIPS-199 category, HVA ID, algorithm/service/key length, software package type/vendor, OS, hosting model/provider(s), data lifecycle/time-to-live, and notes).
3.Deployment requirements for PQC algorithms: Deployment patterns for ML-KEM (key establishment) and ML-DSA/SLH-DSA (signatures): TLS/KEM groups, IPsec/IKE, mutual-TLS, SSH, S/MIME, code-signing/firmware signing, certificate profile impacts, and crypto-agility controls. Hybrid support during transition (classical + PQC) with clear policy gates for when hybrid is required vs. when it is a risk-managed choice; also noting NSA expectations for NSS environments and that not all “hybrid” concepts translate into long-term NSS deployable solutions.
4.Reference hardware architecture requirements: The prescriptive “hardware and performance” module suitable for agency engineering and acquisition teams, addressing the user’s requirements:
a.Performance target: hardware architecture capable of Kyber/ML-KEM class operations with sub-microsecond latency targets (e.g., “<200 ns” as a high-performance objective for real-time workloads), enabling inline encryption at scale.
b. Acceleration scope: full hardware acceleration coverage forML-KEM (Kyber),ML-DSA (Dilithium), and SLH-DSA (SPHINCS+) aligned to FIPS 203/204/205.
c. Side-channel resistant design requirements: constant-time implementations, masking/blinding strategy, hardened key storage boundaries, and validation evidence suitable for federal risk acceptance.
d. Integration: standard PCIe form factor for drop-in deployment in existing server infrastructure, with minimal integration overhead and clear operational runbooks (driver lifecycle, firmware updates, attestation hooks, monitoring).
e. Consolidation strategy: address the operational cost/latency of separate HSM + external entropy + PQC accelerator devices by defining a consolidated architecture option and its trust boundaries.
5.Unified cryptographic API / SDK module: Algorithm-agnostic unified API for classical and PQC primitives to reduce application refactoring risk, while still exposing algorithm-specific tuning and telemetry.
6. Hybrid-by-construction workflows (negotiation policies, fallback logic, interoperability testing) to enable staged cutover.