NIST’s Post-Quantum Cryptography Roadmap: What to Do Now (2025–2035) CyberDudeBivash Authority Brief • Date: September 20, 2025 (IST)

-

 


Executive summary

NIST has moved from research to deployment mode on post-quantum cryptography (PQC). Three PQC standards are already finalized—FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA)—and NIST selected HQC in March 2025 as a backup KEM to diversify against single-family risk. NIST+3NIST Computer Security Resource Center+3NIST Computer Security Resource Center+3

For migration guidance, NIST published an expected transition approach (IR 8547) and an NCCoE Migration to PQC practice guide (SP 1800-38 draft), while the U.S. government mandated crypto inventories via OMB M-23-02. Outside the U.S., timelines (e.g., UK NCSC guidance) converge on finishing migrations by ~2035, with many U.S. national-security systems targeting 2030–2033 milestones under CNSA 2.0. Net: the window to plan, pilot, and phase-in is now. U.S. Department of War+4NIST Computer Security Resource Center+4nccoe.nist.gov+4

Why this matters (quick context)

  • Harvest-now, decrypt-later risk is real: data stolen today may be decrypted once large-scale quantum machines arrive. Government and industry roadmaps therefore push early migration and crypto-agility. TechRadar

  • Standards are here: FIPS 203/204/205 took effect Aug 14, 2024 (Fed. Register)—this is not hypothetical R&D anymore. Federal Register

  • Diversity by design: NIST chose HQC as an additional KEM (different math than ML-KEM) to reduce correlated risk. Draft standard is planned before finalization in 2027. NIST+1

The algorithms you’ll deploy 

PurposePrimaryBackup / Notes
Key establishment (KEM)ML-KEM (FIPS 203)HQC (selected 2025; draft ~2026, final ~2027) for mathematical diversity. NIST Computer Security Resource Center+1
Digital signatures (primary)ML-DSA (FIPS 204)High performance; intended as the main signature standard. NIST Computer Security Resource Center
Digital signatures (backup)SLH-DSA (FIPS 205)Hash-based; conservative fallback with different assumptions. NIST Computer Security Resource Center

The official migration signals you should act on

  • NIST IR 8547 (Transition plan): describes the expected approach from classical to PQC for signatures and key establishment. Treat it as the technical “north star” for standards alignment. NIST Computer Security Resource Center

  • NCCoE SP 1800-38 (Migration to PQC): a practical, modular playbook (prelim. drafts) for crypto-inventory, testing, and staged cut-over. nccoe.nist.gov+1

  • OMB M-23-02 (Federal): mandates cryptographic inventories and migration planning across U.S. agencies; a strong template for any large enterprise. The White House

  • CNSA 2.0 (NSA): sets aggressive adoption timelines (browser/cloud support by 2025, exclusive use by 2033; networking gear by 2030; OS by 2033). Even if you’re not NSS, these dates shape vendor roadmaps. U.S. Department of War

  • UK NCSC (2035 target): public guidance to complete major migrations by 2035 with interim milestones (identify by 2028, overhaul critical by 2031). The Guardian

A pragmatic 6-phase migration plan (do this now)

Phase 0 — Program setup (Q4 2025)
Create an executive-backed Quantum Risk Program. Assign owners for inventory, engineering, procurement, legal, and comms. Align success metrics to NIST IR 8547 and OMB M-23-02. NIST Computer Security Resource Center+1

Phase 1 — Cryptographic inventory & CBOM (Q4 2025–Q1 2026)
Build a Cryptography Bill of Materials (CBOM): enumerate protocols (TLS/IPsec/SSH), libraries (OpenSSL/BoringSSL/WolfSSL), KMS/HSM, PKI, devices, firmware, and third-party SaaS that terminate crypto for you. Map data shelf-life (how long must secrets stay secure). Use SP 1800-38 as your checklist. nccoe.nist.gov

Phase 2 — Prioritize systems (Q1–Q2 2026)
Rank by sensitivity × shelf-life × exposure. Anything with ≥10-year confidentiality needs early PQC. Prioritize internet-facing endpoints, VPNs, machine-to-machine APIs, and code-signing chains. Cross-check with CNSA 2.0 dates to anticipate vendor support. U.S. Department of War

Phase 3 — Pilot hybrids (Q2–Q4 2026)
Stand up hybrid key exchange (classical + ML-KEM) and dual-signing pilots in test environments. Validate performance, certificate sizes, MTU issues, and log/visibility. Use PQC-enabled stacks consistent with FIPS 203/204/205. NIST Computer Security Resource Center+2NIST Computer Security Resource Center+2

Phase 4 — Production rollout (2027–2029)
Move high-risk flows first: external TLS termination, SSO/OIDC/OAuth token services, PKI issuance, software-update signing. Adopt ML-DSA as your default signature, retain SLH-DSA for strategic fallback. Track HQC standardization to introduce as a second KEM once standardized. NIST Computer Security Resource Center+2NIST Computer Security Resource Center+2

Phase 5 — Decommission classical (2030–2033)
Following CNSA 2.0 cadence, phase out RSA/ECC in prioritized domains, keep exceptions gated behind crypto-agility controls, and enforce PQC-only in new deployments. Aim to finish well before 2035. U.S. Department of War+1

Engineering guardrails 

1) Crypto-agility by default
Abstract algorithms behind policy. Your apps should switch KEM/DSA via configuration, not rebuilds. Use CBOM to track what’s in production. (NCCoE SP 1800-38) nccoe.nist.gov

2) Certificates & PKI
Stand up a PQC-capable intermediate CA. Issue ML-DSA end-entity certs and support hybrid/alt-chains during transition. Expect larger keys and signatures—update MTU, CT logs, OCSP/CRLs.

3) Protocols to hit first

  • TLS: front-door for users/APIs; evaluate hybrid key exchange with ML-KEM.

  • VPN/IPsec: high-value; move to PQC-ready suites early.

  • Code-signing & update: switch signing to ML-DSA (keep SLH-DSA contingency). (FIPS 204/205) NIST Computer Security Resource Center+1

4) Vendor & SaaS contracts
Add PQC support clauses with milestone dates aligned to CNSA 2.0 and NCSC 2035 endpoints. Require disclosure of algorithms, libraries, and FIPS conformance. U.S. Department of War+1

5) Telemetry & testing
Benchmark handshake latency, memory, and throughput under ML-KEM/ML-DSA. Capture failure modes (oversized cert chains, middleware limits). Use blue/green cut-overs.

Leadership & policy cues to watch

  • NIST news & FIPS errata: NIST has posted planning notes/errata for PQC FIPS; follow updates to avoid drift. NIST Computer Security Resource Center+1

  • HQC standard track: NIST aims for a draft within ~a year of selection (final by ~2027). Plan internal support now to ease adoption. NIST

  • White House & OMB: continued reporting against M-23-02; buyer’s guides (e.g., GSA PQC Buyer’s Guide) help procurement. The White House+1

Risk framing for boards 

  • Threat: “Harvest-now, decrypt-later” could retroactively expose regulated data.

  • Standards: PQC FIPS in force; HQC selected; government deadlines compress vendor roadmaps. Federal Register+1

  • Exposure: Long-life secrets (PHI, PII, trade secrets, auth tokens).

  • Mitigation: Fund CBOM, crypto-agility, PQC pilots in 2026; enforce vendor roadmaps; target substantial classical deprecation by 2030–2033. U.S. Department of War

FAQs

Are today’s quantum machines breaking RSA/ECC?
No—leading labs indicate we’re not there yet, but migration takes years. Start now. The Verge

Which signature should we use?
NIST intends ML-DSA as primary; keep SLH-DSA as a conservative fallback. NIST Computer Security Resource Center+1

Why add HQC if we have ML-KEM?
Diversity. HQC is code-based (different math) and provides resilience if a lattice vulnerability appears. NIST

Sources 

Comments

Post a Comment

Popular posts from this blog

CyberDudeBivash Rapid Advisory — WordPress Plugin: Social-Login Authentication Bypass (Threat Summary & Emergency Playbook)

-
Image
  TL;DR: A class of vulnerabilities in WordPress social-login / OAuth plugins can let attackers bypass normal authentication flows and obtain an administrative session (or create admin users) by manipulating OAuth callback parameters, reusing stale tokens, or exploiting improper validation of the identity assertions returned by providers. If you run a site that accepts social logins (Google, Facebook, Apple, GitHub, etc.), treat this as high priority : audit, patch, or temporarily disable social login until you confirm your plugin is safe. This advisory gives you immediate actions, detection steps, mitigation, and recovery guidance. Why this matters (short) Social-login plugins often accept externally-issued assertions (OAuth ID tokens, authorization codes, user info). If the plugin fails to validate provider signatures, nonce/state values, redirect URIs, or maps identities to local accounts incorrectly , attackers can craft requests that the site accepts as authenticated. ...
Read more

Hackers Injecting Malicious Code into GitHub Actions to Steal PyPI Tokens CyberDudeBivash — Threat Brief & Defensive Playbook

-
Image
  SUMMARY  Attackers are modifying GitHub Actions workflows (via compromised accounts, malicious PRs, or forged commits) to add steps that exfiltrate PyPI (or other package registry) publishing tokens. With those tokens they publish backdoored packages or download private packages — a supply-chain multiplier. Defend by eliminating long-lived secrets, switching to OIDC/ephemeral credentials, hardening workflow controls, monitoring workflow changes and secret usage, and rotating tokens immediately if you suspect compromise. How attackers typically operate  Gain write access to repo or CI/CD config (via compromised developer account, stolen token, privilege abuse, or merge of malicious PR). Modify or add a workflow file that runs in the repo’s runner context (self-hosted or GitHub-hosted). Add steps that read repository secrets (e.g., PYPI_TOKEN ) or create credentials files ( ~/.pypirc ), then send the token to attacker-controlled endpoints or push a malicious p...
Read more

Exchange Hybrid Warning: CVE-2025-53786 can cascade into domain compromise (on-prem ↔ M365) By CyberDudeBivash — Cybersecurity & AI

-
Image
  Executive summary CVE-2025-53786 is a post-authentication elevation of privilege in Microsoft Exchange hybrid deployments . If an attacker first gains admin on an on-prem Exchange server , they can abuse the legacy “shared service principal” trust used by Hybrid Configuration to escalate into Exchange Online —potentially leading to full cloud+on-prem domain compromise . CISA issued Emergency Directive ED-25-02 with a deadline of 9:00 a.m. EDT on August 11, 2025 for U.S. federal agencies; Microsoft urges all hybrid customers to take the same steps: apply the April 2025 Hotfix Updates , migrate to the dedicated Exchange Hybrid app , and reset/clean up service principal credentials . cisa.gov +1 TECHCOMMUNITY.MICROSOFT.COM +1 Why this is dangerous: actions initiated from the on-prem Exchange side may not show up as obviously malicious in M365 audit trails, making cloud abuse harder to spot if you’ve not modernized the trust. TechRadar What is actually vulnerable? (trust...
Read more