TL;DR
The National Institute of Standards and Technology (NIST) has standardised three post-quantum building blocks: ML-KEM (key establishment), ML-DSA (signatures) and SLH-DSA (hash-based signatures). HQC (a backup KEM) and FN-DSA (Falcon-based signatures) are still being written into standards, and NIST’s final transition plan (NIST IR 8547, October 2026) deprecates today’s quantum-vulnerable public-key algorithms after 2030 and disallows them after 2035. The biggest impact falls on TLS, code and firmware signing and PKI/certificates. The safest near-term path is usually hybrid (classical + PQC). So begin with a CBOM, press vendor roadmaps, pilot migration at the edge, and fund PKI automation.
NIST PQC Standards
Post-Quantum Cryptography (PQC) is no longer theoretical. NIST published its first three quantum-resistant algorithm standards on 13 August 2024 and, in October 2026, finalised the timetable for retiring the algorithms they replace. As a result, regulators, boards and vendors all have something concrete to work toward.
In practical terms, this means three things for leadership teams to plan and execute:
You will be expected to plan, not just observe.
Your systems will need to support “hybrid” crypto.
Your crypto inventory (CBOM) becomes a governance asset, not an engineering spreadsheet.
Let’s walk through what that means, step by step.
The standards at a glance
To begin with, NIST finalised three core algorithm standards for the post-quantum world on 13 August 2024: ML-KEM (FIPS 203), ML-DSA (FIPS 204) and SLH-DSA (FIPS 205).
ML-KEM (FIPS 203)
Key Establishment
This is used to agree on shared secrets between two parties (for example, in TLS handshakes).
In classical crypto, RSA and (EC)DH do this job. Going forward, ML-KEM is the quantum-resistant replacement, and NIST recommends ML-KEM-768 as the default parameter set.
In reality, most organisations will start with hybrid key exchange, where classical and PQC run together.
ML-DSA (FIPS 204)
Digital Signatures
This covers signing and verifying (for example, software packages, documents, certificates).
It is positioned as the successor to RSA/ECDSA for most signing workflows.
SLH-DSA (FIPS 205)
Hash-Based Digital Signatures
This is another signature family, whose security rests only on well-understood hash functions.
Public keys are small, but signatures are large (roughly 8 KB to 50 KB) and signing is slower than ML-DSA. In return, the security assumptions are very conservative.
You will likely see this in use cases where long-term trust is critical, such as firmware validation and root-of-trust signing.
Beyond the first three: what else is in the pipeline?
- HQC (backup KEM): selected on 11 March 2025 as a code-based alternative to ML-KEM. A FIPS for HQC-KEM is under development; NIST has said it expects to finalise it in 2027. As of late October 2026 no public draft has been issued.
- FN-DSA (FIPS 206, derived from FALCON): a compact lattice-based signature standard that NIST is still developing. As of late October 2026 it has not been published, even in draft, so do not plan on it for near-term deployments.
- Stateful hash-based signatures (SP 800-208, October 2020): LMS/HSS and XMSS are already approved and quantum-resistant. Because the signer must track state so a one-time key is never reused, NIST positions them for specific uses such as software and firmware signing, not general use.
- KEM guidance (SP 800-227, final September 2025): NIST’s recommendations for using key-encapsulation mechanisms securely, including how to combine keys in hybrid schemes.
- Additional signatures: NIST’s separate search for more signature schemes moved to a third round on 14 May 2026, with nine candidates (NIST IR 8610). None is a standard yet.
The transition timeline: NIST IR 8547 is now final
On 27 October 2026 NIST published the final NIST IR 8547, Transition to Post-Quantum Cryptography Standards. It sets the dates every CISO should now be planning against:
- After 2030: quantum-vulnerable public-key algorithms (RSA, ECDSA, EdDSA, Diffie-Hellman/ECDH and MQV) are deprecated. They may still be used, but you accept the risk.
- After 2035: they are disallowed under NIST standards and guidelines.
Note the change from the November 2024 draft, which deprecated only 112-bit-strength parameters (such as RSA-2048) after 2030 and moved stronger parameters straight to disallowed after 2035. The final version deprecates all quantum-vulnerable public-key algorithms after 2030, regardless of key size. For US federal agencies, the earlier deadlines in OMB Memorandum M-26-15 (24 June 2026) still apply: high value assets and high impact systems must use PQC for key establishment by 31 December 2030 and for digital signatures by 31 December 2031.
What it means for leadership
From a leadership perspective, NIST’s work removes ambiguity. Until now, many organisations could say “we’re waiting for standards.” That is no longer credible.
Here’s why this now sits at CEO and CISO level:
- First, it is a business risk. If an attacker can decrypt historical customer data (for example, mortgage books or high-value transactions), that becomes a regulatory, contractual and reputational event, not just a technical one.
- Second, it is an operating model change. You cannot “bolt on PQC” in one weekend. Instead, you are looking at a phased crypto-modernisation programme that touches networks, systems, code-signing pipelines, PKI and vendors.
- Third, it is an evidence problem. Boards, auditors and regulators will start asking, “Show us your plan. Where are you still exposed, and what’s the migration path?” That proof point is your CBOM.
A pragmatic, phased approach
To move from “awareness” to “governance”, you can structure your next steps in three phases.
Phase 1 (0–3 months): Visibility and Ownership
Build your Cryptographic Bill of Materials (CBOM) for your top 20 high-value services.
For each one, record: algorithms, key sizes/parameters, crypto libraries, protocols, certificate and trust store details, and signing flows.
At the same time, identify systems tied to long-lived data.
Finally, send a standard PQC readiness questionnaire to strategic vendors.
Phase 2 (3–6 months): Controlled Pilots
Stand up a hybrid TLS pilot at a controlled edge (for example, an API gateway or an external-facing web application).
In parallel, begin testing post-quantum signature schemes (ML-DSA, SLH-DSA, or LMS/XMSS where state can be managed) for software and firmware signing in a non-production environment.
Measure latency, CPU, handshake size and integration impact.
Summarise those findings into a board-facing heatmap (Impact vs Effort).
Phase 3 (6–12 months): Operationalisation
Expand hybrid support to additional gateways or partner links where feasible.
Update PKI and certificate issuance/rotation policies to include PQC-capable profiles and automated renewal.
Embed crypto-agility requirements into internal standards and third-party contracts.
Report status to the executive team as a tracked programme, not an experiment.
For the organisation, this will be the beginning of a controlled modernisation of trust, identity and encryption lifecycles.
Building the Governance Layer
Finally, you will need to update the organisation’s policies and processes. As you move, make sure your governance covers:
Crypto Standards: Add ML-KEM, ML-DSA and SLH-DSA as approved building blocks (plus LMS/XMSS for signing use cases that can manage state), with guidance on when to use hybrid. Plan to add HQC and FN-DSA once NIST publishes them.
PKI and Certificate Policy: Update certificate profiles, validity periods, trust anchors, HSM (Hardware Security Module) and KMS (Key Management Service) usage.
Secure build and release: Update code-signing requirements in CI/CD and firmware pipelines; ensure signatures remain verifiable long-term.
Third-Party Risk: Bake PQC milestones (and reporting dates) into supplier contracts, aligned to the 2030 and 2035 dates in NIST IR 8547.
Reporting: Define KPIs that leadership will actually track.
Leader takeaway
NIST’s PQC standards define where you’re heading. Your PQC programme defines how you’ll get there.
Start with visibility (CBOM), move to hybrid pilots where it matters most, and anchor vendors to dated commitments. If your data must remain confidential for years, your PQC journey begins now.
Our Post-Quantum Readiness Series
This article is Part 3 of our Post-Quantum Cyber Readiness Series, where we break down complex concepts into practical steps.
In this series, we covered:
- Part 1: Introduction to Post-Quantum Cryptography
Part 2: Understanding Quantum Threats and “Harvest Now, Decrypt Later” Attacks
Each article will equip CEOs, CISOs, IT leaders and architects with the knowledge and tools to navigate the quantum transition confidently.
