NIST PQC Standards Finalized: What Regulated Enterprises Must Do Now | Quantizant Blog

NIST Has Spoken. Now What?

In August 2024, NIST published FIPS 203, 204, and 205 — the first final post-quantum cryptographic standards. After an eight-year standardization process, the algorithms are no longer experimental. They are the new baseline for federal information security, and regulated industries are expected to follow.

For most enterprise security teams, this creates an immediate problem: they don’t know their cryptographic attack surface. You cannot transition what you cannot find.

This post is a practical guide for CISO teams in regulated sectors — banking, healthcare, defense contractors, and critical infrastructure operators — on what the standards mean, what the regulators are saying, and what to do in the next 90 days.

The Three Final Algorithms

ML-KEM (FIPS 203) — Your New Key Exchange Mechanism

Replace RSA-OAEP and ECDH (including X25519 and P-256) with ML-KEM for key encapsulation. This is the highest-priority transition because TLS key exchange is where HNDL (Harvest Now, Decrypt Later) exposure is greatest.

Immediate action: Enable hybrid X25519MLKEM768 on all public-facing TLS endpoints. This is supported in:

Chrome 124+ / Firefox 128+ (already enabled by default)
OpenSSL 3.3+ (with OQS provider)
BoringSSL (Google’s TLS library — used in Android, Chromium)
AWS, GCP, and Cloudflare load balancers (now in GA)

ML-DSA (FIPS 204) — Your New Signing Algorithm

Replace RSA-PSS and ECDSA with ML-DSA for digital signatures. This affects:

Code signing and software supply chain integrity
Document and contract signing
JWT / JOSE tokens (where signature algorithm matters)
Certificate issuance (your internal CA)
SSH host keys

SLH-DSA (FIPS 205) — Long-Term Signature Assurance

SLH-DSA is the conservative, hash-based option. Its security relies only on the collision-resistance of the underlying hash function — not on lattice problems. Choose SLH-DSA where you need:

Very long-term signature verifiability (10+ years)
Post-quantum security without lattice assumptions (defense-in-depth)
Firmware signing for embedded systems and HSMs

What Regulators Are Saying

United States

The NSA’s Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) sets hard timelines for defense contractors and national security systems:

2025: New systems should support PQC algorithms
2030: Legacy classical-only algorithms must be disabled

CISA has issued joint advisories with NSA and NIST urging critical infrastructure operators to begin transition immediately.

The OMB has required all federal agencies to complete PQC transition inventories and submit plans.

Banking & Financial Services

MAS TRM 2024 (Monetary Authority of Singapore Technology Risk Management guidelines) explicitly references post-quantum cryptography readiness under Section 6 (Cryptography Controls). MAS-regulated financial institutions are expected to:

Maintain a cryptographic asset inventory
Document exposure to quantum-vulnerable algorithms
Have a documented transition roadmap

DORA (EU Digital Operational Resilience Act, enforced January 2025) requires financial entities to maintain ICT risk management frameworks that include cryptographic controls — and the EBA/ESA joint committee has flagged PQC as an emerging systemic risk.

PCI DSS v4.0 has added requirements for cryptographic agility — the ability to swap algorithms without application redesign.

Healthcare

HIPAA requires “reasonable and appropriate” safeguards. Given published HNDL guidance from HHS and CISA, any organization that hasn’t initiated a PQC review may be unable to demonstrate reasonable safeguards by 2027.

Ask any enterprise security team how many cryptographic assets they have. Very few can answer.

A 2025 Ponemon Institute study found:

47% of security teams have no cryptographic asset inventory
68% rely on manual processes (spreadsheets, ad-hoc audits)
The average enterprise has over 10,000 cryptographic assets spread across code, infrastructure, and cloud

Manual crypto discovery doesn’t scale. You need automated tooling that can:

Scan source code across multiple languages for crypto API usage patterns
Analyze dependency trees for embedded crypto libraries
Query cloud KMS for key algorithm metadata
Probe TLS/SSH endpoints for cipher suite and key exchange support
Scan IaC files for crypto misconfigurations

This is exactly what qtz-discovery-cli does — and it outputs a CycloneDX CBOM (Cryptographic Bill of Materials) that gives you an auditable, machine-readable record of every cryptographic asset.

A 90-Day Action Plan

Here is a concrete starting point for any regulated enterprise:

Days 1–30: Discover

# 1. Install the CLI
brew install quantizant/tap/qtz-discovery-cli

# 2. Scan your primary codebase
qtz-discovery-cli scan source ./src \
  --format cbom \
  --output cbom-initial.json \
  --show-score

# 3. Scan public-facing TLS endpoints
qtz-discovery-cli scan network \
  api.yourcompany.com:443 \
  auth.yourcompany.com:443 \
  vpn.yourcompany.com:443

# 4. Inventory AWS KMS
qtz-discovery-cli scan infra --provider aws --region us-east-1

# 5. Scan IaC
qtz-discovery-cli scan iac ./terraform

Output: A complete CBOM and a transition readiness score. This is your baseline for compliance reporting.

Days 31–60: Prioritize

Feed the CBOM into the Quantizant portal for AI risk scoring. The portal generates a prioritized transition roadmap based on:

HNDL exposure (internet-facing endpoints using RSA/ECDH key exchange)
Data sensitivity (which systems handle PHI, PII, financial data)
Remediation complexity (library upgrade vs. algorithmic redesign)
Regulatory deadline alignment

Days 61–90: Begin Hybrid Transition

Start with the highest-HNDL-exposure endpoints:

Enable X25519MLKEM768 hybrid key exchange on all TLS termination points (nginx, Cloudflare, AWS ALB)
Upgrade to OpenSSL 3.3+ or BoringSSL with PQC support
Rotate the highest-risk KMS keys to PQC-capable algorithms where your provider supports it

Cryptographic Agility: The Right Architecture

The organizations that will transition smoothly are those that designed for cryptographic agility — the ability to swap algorithms without touching application code. Key principles:

Abstract crypto operations — Never hardcode algorithm names. Use configuration-driven crypto selection.
Centralize key management — If every service manages its own keys, you have a transition nightmare. Use a central KMS.
Negotiate algorithms at runtime — TLS already does this; apply the same principle to application-level crypto.
Audit logging — Every cryptographic operation should be logged with algorithm metadata. You cannot report compliance on what you cannot observe.

The Quantizant sidecar proxy implements cryptographic agility as infrastructure — a zero-code-change transition path for TLS and application-level crypto.

The Compliance Timeline

Date	Milestone
2024	NIST FIPS 203/204/205 published
2025	NSA CNSA 2.0 adoption deadline for new systems
2025	DORA enforcement begins for EU financial entities
2026	MAS TRM audit cycle includes PQC maturity questions
2027	Expected browser/OS deprecation of classical-only TLS
2028	NIST recommends completing transition of highest-risk systems
2030	NIST deadline: all classical-vulnerable algorithms must be disabled

What To Do Today

Download qtz-discovery-cli and run your first crypto scan — it takes under 10 minutes to get a CBOM and readiness score.
Brief your CISO and board — frame this as a compliance initiative with a hard 2030 regulatory deadline and a live HNDL threat.
Assign a crypto transition owner — this cannot live in a backlog. It needs a named DRI with budget authority.
Get your baseline CBOM into version control — treat it like your SBOMs. Every release should update it.

The organizations that will meet the 2030 deadline without panic are the ones that started their inventory in 2025 and 2026. That window is now.

Start your cryptographic inventory in minutes with qtz-discovery-cli. For enterprise-scale transition planning, sign in to the Quantizant portal.