Post-Quantum Cryptography Deep Research for DFIR and Cyber GRC in Early 2026

Executive summary

Post-Quantum Cryptography (PQC) has shifted from “future research” to “near-term program execution” because multiple governments now publish concrete milestones that force cryptographic inventory, migration planning, and procurement changes on a multi‑year runway. In early 2026, you can see the first “plan due” deadlines clearly in the Government of Canada roadmap (initial departmental plans due April 2026) while U.S. federal guidance has already been driving inventories and annual reporting since 2023 through OMB direction tied to NSM‑10. citeturn10view2turn18view0turn17view0

From a Cyber GRC lens, the highest ROI research is learning how to translate PQC migration into: (1) auditable control language (e.g., CSF outcomes and SP 800‑53 controls), (2) measurable “crypto agility” maturity, and (3) procurement and lifecycle governance. NIST’s CSWP 48 is directly designed to map PQC migration project capabilities to NIST CSF 2.0 and SP 800‑53—an unusually explicit bridge between cryptography engineering and governance artifacts. citeturn13view0turn13view1turn5search13

From a DFIR lens, the immediate operational threat is not “quantum breaks today’s TLS session live,” but harvest now, decrypt later (HNDL)—adversaries collecting ciphertext now and decrypting later once sufficiently capable quantum systems exist. NIST explicitly calls out HNDL as a core motivator for migrating to PQC “as soon as possible” for long‑lived secrets. citeturn10view0turn17view4

The practical PQC baseline for 2026 is anchored by NIST’s finalized FIPS standards: FIPS 203 (ML‑KEM) for key establishment, and FIPS 204 (ML‑DSA) plus FIPS 205 (SLH‑DSA) for digital signatures, published August 13, 2024. citeturn1search3turn18view2turn18view3

Quantum readiness policy and compliance drivers

U.S. federal: inventory-first, annually, with migration pressure extending to 2035. The U.S. Office of Management and Budget memorandum M‑23‑02 requires agencies to submit a prioritized inventory of information systems and assets containing CRQC‑vulnerable cryptographic systems by May 4, 2023 and annually thereafter until 2035 (or until superseded). The memo defines “cryptographic system” broadly (key creation/exchange, encrypted connections, and digital signatures), which matters directly for how you scope CBOM coverage in audits. citeturn17view0turn6view0

That inventory requirement is reinforced by statute: the Quantum Computing Cybersecurity Preparedness Act directs OMB to issue guidance and requires executive agencies to maintain inventories of quantum‑vulnerable IT; once NIST issues PQC standards, OMB guidance must drive agency migration planning. citeturn18view1turn5search1

Canada: explicit plan deadline in April 2026 and staged migration to 2035. The Canadian Centre for Cyber Security roadmap for non‑classified Government of Canada IT systems states milestones including: initial departmental PQC migration plan in April 2026, annual progress reporting starting April 2026, high‑priority completion by end of 2031, and remaining systems by end of 2035. citeturn10view2turn3search0

Canada’s related policy notice further specifies By April 1, 2026 for developing a high-level departmental plan and beginning annual reporting, plus later-phase system record updates that must include “system architecture and cryptographic details,” vendor lifecycle fields, and migration status—effectively a CBOM/crypto inventory operational requirement in policy form. citeturn18view0turn3search3

United Kingdom and Australia: national roadmaps that shape vendor behavior. Because many enterprises are downstream of global vendors (cloud, browsers, VPNs, HSMs), national timelines influence product roadmaps even outside those jurisdictions. The UK National Cyber Security Centre (content mirrored in PDF form) defines key milestones by 2028 (discovery + initial plans), 2031 (highest-priority migrations), and 2035 (complete migration). citeturn17view7turn17view8

Australia’s government guidance recommends ceasing use of traditional asymmetric cryptography by end of 2030 and sets milestones including having a refined transition plan by end of 2026. citeturn9search2turn9search4

Governance mapping: CSF 2.0 and CSWP 48 as the GRC “translation layer.” NIST CSF 2.0 adds a dedicated Govern function alongside Identify/Protect/Detect/Respond/Recover, which makes it easier to express PQC as governance and supply chain outcomes, not just cryptographic engineering. citeturn5search13turn5search2

NIST’s CSWP 48 is explicit that it maps capabilities from the NCCoE PQC migration project to CSF 2.0 security objectives and SP 800‑53 controls, enabling compliance teams to attach PQC work to familiar audit language rather than treating it as a standalone “crypto project.” citeturn13view0turn13view1

image_group{"layout":"carousel","aspect_ratio":"16:9","query":["NIST post-quantum cryptography standards ML-KEM ML-DSA SLH-DSA diagram","Hybrid TLS 1.3 ECDHE-MLKEM handshake diagram","Cryptographic bill of materials CBOM example template"],"num_per_query":1}

PQC standards and engineering baseline

NIST’s PQC “anchor standards” (2024):

• FIPS 203 (ML‑KEM): NIST standard for a Key Encapsulation Mechanism, with security based on Module Learning With Errors and three parameter sets (ML‑KEM‑512/768/1024). citeturn18view2turn1search0
• FIPS 204 (ML‑DSA): module-lattice-based digital signature standard (primary PQC signature baseline). citeturn1search1turn1search3
• FIPS 205 (SLH‑DSA): stateless hash-based digital signatures; also emphasizes signatures’ role in evidentiary assurance and non‑repudiation—directly relevant for DFIR evidence integrity and long-term verification. citeturn18view3turn1search10 NIST’s PQC standardization program notes these three were published August 13, 2024 and that an additional signature standard based on FALCON is in development as FIPS 206. citeturn1search11turn1search3

Why hybrid is common in 2026: NIST’s IR 8547 explicitly anticipates transitional deployments where systems use hybrid techniques—combining quantum-resistant and quantum-vulnerable algorithms—while standards, products, and validation ecosystems mature. NIST also flags that hybrid adds cost and engineering complexity, leaving the decision to applications, while stating it will accommodate hybrid key-establishment modes and dual signatures in FIPS 140 validation when properly combined with NIST‑approved schemes. citeturn17view5turn15view2turn4search0

Hybrid key exchange in TLS 1.3 (standards trajectory): The IETF draft Post-quantum hybrid ECDHE‑MLKEM key agreement for TLS 1.3 defines hybrid groups (e.g., X25519MLKEM768) that combine ML‑KEM with classical ECDHE; its companion design draft explains hybrid key exchange as combining outputs to remain secure even if only one component remains secure. These drafts are a primary source for how “hybrid TLS” is being standardized in practice. citeturn4search1turn4search9

Threat model clarity for DFIR and GRC: NIST explains that even before a cryptographically relevant quantum computer exists, there is a pressing risk from adversaries “harvesting” encrypted data now for later decryption, and argues that long-lived secrets are a major reason to start migrating and encrypting with PQC techniques early. citeturn10view0turn17view4

Crypto asset discovery, CBOM, and crypto agility

Inventory discovery as a first-order control

The most consistent guidance across major programs is: you cannot migrate what you cannot find. The U.S. federal PQC report emphasizes that a comprehensive cryptographic inventory is a baseline for successful migration and that automated inventory solutions can help but may not find everything, so inventories must be treated as iterative and ongoing. citeturn17view2turn14view1

Similarly, the government factsheet from CISA/NSA/NIST urges organizations to build roadmaps and initiate cryptographic discovery because RSA/ECDH/ECDSA-class public-key mechanisms will need updating or replacement. citeturn17view1turn14view0

CBOM as the auditable artifact

A Cryptographic Bill of Materials (CBOM) conceptually extends an SBOM by explicitly modeling cryptographic assets and dependencies. NIST’s NCCoE PQC migration draft (SP 1800‑38B Volume B) states the project will experiment with CBOM creation, describes CBOM as related to and building upon SBOMs, and notes CBOM models are still developing. citeturn17view3turn14view2

CBOM template you can use in an audit

This template is intentionally practical: it supports GRC reporting, DFIR triage, and engineering migration work. The “Minimum CBOM” fields align with what Canadian policy expects to record (system crypto details, vendor/lifecycle, dependencies) and what U.S. guidance demands for inventorying crypto systems and planning migration. citeturn18view0turn17view0turn17view2

CBOM section	Field	Example	Why it matters
Asset identity	System / service name	“Customer API Gateway”	Enables scope control and ownership assignment (audit-ready). citeturn17view2turn17view0
Ownership	Business owner / technical owner	“Payments Eng / Platform Sec”	Required for remediation accountability and governance workflows. citeturn10view2turn13view1
Environment	Prod / staging / dev	“Prod”	Risk differs materially by environment; migration sequencing depends on this. citeturn13view1turn17view2
Crypto usage	Purpose	“TLS key exchange; cert signing; at-rest envelope”	OMB’s scope includes keys, encrypted connections, signatures. citeturn17view0turn6view0
Algorithm inventory	Algorithm + parameters	“ECDHE P-256; RSA-2048; AES-256-GCM”	Identifies quantum-vulnerable public-key crypto and symmetric primitives. citeturn17view1turn17view0
PQC mapping	Target PQC / hybrid plan	“Hybrid X25519 + ML‑KEM‑768”	Hybrid is a common migration bridge (IETF + NIST IR 8547). citeturn4search1turn17view5
Implementation	Crypto library/module	“OpenSSL 3.x; HSM module X”	Migration feasibility depends on library/HSM support and validation status. citeturn17view2turn13view0
PKI and certs	Certificate profile	“WebPKI server cert; internal mTLS cert”	Certificates and signing are often the longest lead-time dependencies. citeturn17view8turn18view3
Data risk	Data classification	“PII; trade secret; regulated”	Drives HNDL prioritization (“long secrecy lifetime”). citeturn10view0turn17view1
Secrecy horizon	Expected confidentiality lifetime	“10+ years”	Core DFIR/GRC prioritization for “harvest now, decrypt later.” citeturn10view0turn17view4
Dependencies	Upstream/downstream systems	“IdP; HSM; CDN; vendor API”	Migration often fails at integration boundaries and supplier dependencies. citeturn17view8turn18view0
Evidence	Scan source + timestamp	“Passive TLS scan 2026‑02‑01”	Supports auditability and incident forensics. citeturn17view2turn14view2
Migration status	Status + milestones	“Planned / Pilot / Migrating / Complete”	Required for reporting and progress tracking in roadmaps. citeturn10view2turn18view0

Crypto-agility as a maturity discipline

NIST’s CSWP 39 defines crypto agility as the capability to replace/adapt cryptographic algorithms in protocols, applications, software/hardware/firmware, and infrastructures while preserving operations, and frames PQC transition as larger than prior transitions because all public-key algorithms require replacement rather than a single algorithm. citeturn0search12turn6view1

A practical maturity view is CAMM (Crypto‑Agility Maturity Model), which is presented as a five-level stage model on the CAMM project site and in the associated academic work (levels commonly described from “not possible/initial” up to “sophisticated”). citeturn2search0turn2search7

Discovery-to-migration pipeline architecture

flowchart LR
  A[Telem & scans\n(passive TLS, endpoint configs,\ncode + SBOM analysis)] --> B[Normalize findings\ncrypto asset model]
  B --> C[CBOM store\n(versioned + evidence links)]
  C --> D[Risk triage\nHNDL horizon + criticality]
  D --> E[Migration backlog\nowner + milestones]
  E --> F[Implement\nhybrid pilots -> prod rollout]
  F --> G[Validate\ninterop + perf + audit evidence]
  G --> C

This pipeline matches the NCCoE emphasis that discovery tools help create a cryptographic inventory to support a migration roadmap and that inventories must be expanded and maintained over time. citeturn14view2turn17view2

Discovery methods comparison table

Method	Coverage strengths	Weak spots	Typical outputs
Passive network discovery (TLS/SSH scan)	Finds externally visible cipher suites, cert chains, key sizes quickly	Misses internal-only crypto; can’t see app-level signing/encryption; limited to observable protocols	Endpoint list; negotiated groups (e.g., ECDHE) and cert algorithms (e.g., RSA/ECDSA) citeturn17view1turn17view0
Host/endpoint config inspection (agents)	Sees system libraries and local configs	May miss embedded/firmware crypto; deployment friction	Library versions; crypto module footprints citeturn17view2turn14view2
Code + dependency analysis (SAST/SCA + SBOM)	Finds hard-coded crypto calls and library usage; fits CI/CD	Doesn’t confirm runtime paths; false positives in unused code	Algorithm calls; dependency graph; candidate crypto assets for CBOM citeturn14view2turn17view3
Artifact/cert inventory (PKI, keystores, HSMs)	Targets the hardest dependencies (certs, signing, HSM)	Often fragmented across teams and vendors	Certificate profiles, CA chains, key storage locations citeturn18view3turn17view2

DFIR implications and evidence integrity

“Harvest now, decrypt later” changes breach impact analysis

NIST explicitly describes HNDL as a scenario where adversaries capture encrypted data now and hold it until they can break it later, and says it is a key reason to start encrypting with post-quantum techniques early—particularly for secrets that remain valuable for years. citeturn10view0turn17view4

Government guidance similarly frames “catch now, break later / harvest now, decrypt later” as a reason to do early planning and inventory work. citeturn17view1turn14view0

DFIR-ready triage heuristic (practical synthesis): in every breach where encrypted data was exfiltrated, you should add a “quantum horizon” lens:

• Secrecy horizon: will the data still matter in 5–20 years (identity data, medical records, long-lived IP, government procurement/strategy)? (Supported by NIST’s HNDL framing.) citeturn10view0turn17view1
• Crypto exposure: was the data protected by algorithms vulnerable to quantum attacks (RSA/ECDH/ECDSA-class) and thus plausible HNDL targets? citeturn17view1turn17view0
• Forward secrecy reality: NIST IR 8547 distinguishes confidentiality risk (subject to HNDL) from authentication-only use cases, and discusses that key establishment protecting confidentiality must consider HNDL timelines. citeturn15view2turn17view4

Evidence integrity and long-lived signatures

Digital forensics and legal defensibility depend on the ability to show integrity and authenticity of evidence over long periods. NIST’s FIPS 205 explains that digital signatures detect unauthorized modification and that signed data can be used as evidence to a third party (non‑repudiation). That “signature as evidence” framing is directly aligned to DFIR chain-of-custody and long-term validation requirements. citeturn18view3turn1search10

NIST IR 8547 also explicitly discusses code signing as a PQC transition use case and anticipates hybrid/dual signature models as transitional tools. citeturn15view2turn17view5

DFIR implication (operational): evidence integrity programs should treat PQC migration as impacting:

• log signing and log integrity mechanisms,
• code signing verification (tools and agents you trust in IR),
• organizational PKI used for incident artifacts and attestations. citeturn15view2turn17view2turn18view3

Role-aligned research agenda and deliverables

This roadmap is structured to produce portfolio-grade outputs that translate directly into DFIR and GRC credibility, and it is grounded in primary sources used by governments and standards bodies.

Priority reading and why it matters

• NIST CSWP 39: foundation for crypto agility as an operational capability and planning discipline. citeturn0search12turn0search8
• NIST CSWP 48: direct CSF 2.0 / SP 800‑53 mapping for PQC migration capabilities—high leverage for GRC narratives and audit artifacts. citeturn13view0turn13view1
• OMB M‑23‑02: concrete federal inventory and reporting requirements; sets the operational meaning of “cryptographic system” for inventories. citeturn17view0turn6view0
• NIST IR 8547: transition approach and explicit hybrid guidance; describes why HNDL drives urgency and how different use cases change timelines. citeturn10view1turn17view4turn17view5
• NIST FIPS 203/204/205: the standardized algorithms you’ll reference in policy language and technical control testing. citeturn18view2turn1search1turn18view3
• CISA/NSA/NIST Quantum Readiness factsheet (via NSA-hosted PDF): pragmatic migration steps (roadmap, inventory, risk assessment, vendor engagement) and HNDL framing. citeturn17view1turn8search3
• IETF hybrid TLS drafts: how hybrid ML‑KEM + ECDHE is being standardized for TLS 1.3. citeturn4search1turn4search9

Step-by-step research plan with tangible outputs

Discovery and inventory (weeks 1–4): build a “quantum readiness discovery lab” using your own small network + repo testbed. The deliverable is a short report plus an initial CBOM for the lab environment. This aligns directly with NCCoE’s emphasis on discovery tools to build inventories that enable roadmaps. citeturn14view2turn17view3

Crypto agility maturity (weeks 5–8): create a CAMM-style maturity assessment for one environment (e.g., a demo enterprise with PKI + TLS + signing). Your deliverable is a one-page maturity scorecard and a backlog of “crypto-agility upgrades.” citeturn2search0turn0search12

Hybrid pilots (weeks 9–12): document a hybrid transition pathway for TLS and for signing. Focus on the governance decision logic—where hybrid is justified vs where it introduces unnecessary complexity—because NIST notes hybrid adds engineering complexity and is application-dependent. citeturn17view5turn4search1

Timeline view across major roadmaps

gantt
  title PQC migration milestone landscape (selected government timelines)
  dateFormat  YYYY-MM-DD
  axisFormat  %Y

  section Canada non-classified GC systems
  Initial departmental PQC migration plan due :milestone, 2026-04-01, 1d
  High-priority systems migrated (target)     :milestone, 2031-12-31, 1d
  Remaining systems migrated (target)         :milestone, 2035-12-31, 1d

  section US federal civilian agencies (FCEB scope via OMB)
  Annual crypto inventory requirement begins  :milestone, 2023-05-04, 1d
  Annual inventories continue (target horizon):milestone, 2035-12-31, 1d

  section UK NCSC guidance (planning milestones)
  Discovery + initial plan complete           :milestone, 2028-12-31, 1d
  Highest-priority migrations complete        :milestone, 2031-12-31, 1d
  Migration complete (target)                 :milestone, 2035-12-31, 1d

The Canada milestones above come from Canadian government and Cyber Centre publications; the U.S. inventory milestone is directly from OMB M‑23‑02; the UK milestones come from the NCSC guidance mirror PDF. citeturn18view0turn10view2turn17view0turn17view7turn17view8

---

Primary sources highlighted (first mention, for quick reference): entity["organization","National Institute of Standards and Technology","us standards agency"]; entity["organization","Office of Management and Budget","us executive office"]; entity["organization","Cybersecurity and Infrastructure Security Agency","us cybersecurity agency"]; entity["organization","National Security Agency","us signals intelligence"]; entity["organization","Canadian Centre for Cyber Security","canada cyber centre"]; entity["organization","National Cyber Security Centre","uk cybersecurity agency"]