NIST PQC Signature Standards: What Enterprises Must Do Now
The post-quantum conversation has shifted. For years it centered on key exchange and the "harvest now, decrypt later" risk to encrypted traffic. With NIST's signature standards now finalized — ML-DSA (FIPS 204), SLH-DSA (FIPS 205), and the on-ramp FN-DSA — the urgent question for enterprise security teams is no longer whether to plan for PQC, but how fast their signature-bearing systems can move.
Signatures sit at the foundation of nearly every trust decision an enterprise makes: TLS certificates, code signing, document signing, SAML assertions, JWTs, firmware updates, container images, and machine-to-machine authentication. Unlike encrypted traffic, a forged signature is an active compromise: a quantum-capable attacker doesn't need a stockpile — they need a signing key.
Why signatures became the priority
Encryption can tolerate a phased migration because confidentiality is backward-looking. Signatures cannot. The moment a cryptographically relevant quantum computer (CRQC) exists, every signing key still in production becomes an existential risk for the relying parties that trust it. Recent industry guidance — including CISA's PQC roadmap and the NSA's CNSA 2.0 timeline — now treats signature migration as the first milestone, not the last.
This reordering matters operationally. Most enterprises have built their PKI around RSA-2048 and ECDSA P-256 with assumed 10–25 year root CA lifetimes. A root signed today with classical algorithms must remain trustworthy through the entire CRQC threat window. That math no longer works.
The three standards and where each fits
NIST's signature suite is deliberately diverse — not because one algorithm is "best," but because enterprises need options matched to different constraints.
- ML-DSA (FIPS 204, derived from CRYSTALS-Dilithium). The general-purpose workhorse. Lattice-based, fast verification, reasonable signature sizes (~2.4 KB at level 2). This will be the default for TLS, document signing, and most certificate chains.
- SLH-DSA (FIPS 205, derived from SPHINCS+). Stateless hash-based. Conservative security assumptions — its security reduces to the underlying hash function, not to a structured math problem. Slow and bulky (~7–30 KB signatures), but ideal for long-lived root CAs and code-signing roots where signature size matters less than algorithmic diversity.
- FN-DSA (derived from Falcon). Smaller signatures than ML-DSA but harder to implement safely (floating-point hazards). A reasonable choice for constrained devices and high-volume use cases once vetted libraries mature.
The practical pattern emerging in enterprise deployments: SLH-DSA for roots, ML-DSA for issuing CAs and leaf certificates, hybrid chains during the transition.
What changes in your PKI
Most ADCS, EJBCA, and managed-CA deployments cannot issue PQC certificates today. Microsoft has begun previewing post-quantum support in ADCS, and the public WebPKI is running hybrid certificate experiments, but production issuance at scale is still 12–24 months out for most enterprises.
Three concrete impacts to plan for:
- Certificate size and chain inflation. A hybrid X.509 chain carrying both classical and PQC signatures can be 5–10× larger than today's. TLS handshakes, OCSP responses, and embedded firmware verifiers all need headroom.
- HSM and signing-service capacity. PQC signing operations are CPU-heavier than ECDSA. Network HSMs sized for current throughput will hit ceilings — especially for high-volume code-signing and document-signing services.
- Protocol and library support. TLS 1.3, X.509, CMS, JWT, and SAML all need updates. OpenSSL 3.5+, BoringSSL, and the major JCA providers ship PQC primitives; production-grade integration into application stacks lags by 12–18 months.
A pragmatic enterprise sequence
You do not need a rip-and-replace. You need a sequenced program that keeps classical PKI healthy while building PQC capability alongside it.
1. Build a cryptographic inventory you trust
You cannot migrate what you cannot see. Most enterprises discover, on first inventory, that 30–50% of their certificates are unknown to their issuing CA — self-signed services, embedded device certs, forgotten code-signing keys. A modern certificate lifecycle management (CLM) program is the prerequisite, not the outcome, of PQC readiness.
2. Classify by signature lifetime
Group every signing use case by how long its signatures must remain verifiable:
- Short-lived (days to months): TLS, OCSP, short JWTs. Lowest urgency — these naturally rotate out.
- Medium-lived (1–5 years): Document signatures, SBOM attestations, container image signatures.
- Long-lived (5–25 years): Root CAs, code-signing roots, firmware-signing keys, archived signed documents under regulatory retention.
Long-lived signers move first.
3. Pilot hybrid before pure PQC
Hybrid certificates — carrying both a classical and a PQC signature — let relying parties that don't yet understand PQC continue to function. This is the migration pattern the WebPKI itself is using. Pilot it in a low-risk internal CA before touching production roots.
4. Negotiate PQC into vendor contracts now
Any HSM, CA, CLM, signing-service, or IdP contract you sign this year should include explicit PQC algorithm support as a contractual deliverable on a dated roadmap. Vendors who cannot commit are a 2030 problem masquerading as a 2026 procurement decision.
What "done" looks like
A PQC-ready enterprise has: a complete cryptographic inventory; a CLM platform that can issue, renew, and revoke PQC and hybrid certificates; HSMs capable of PQC signing at production throughput; application stacks updated to verify PQC signatures; and a written policy mapping every signing use case to a target algorithm and migration date.
None of that is a product purchase. It is a 24–36 month program of inventory, governance, and disciplined modernization — the same discipline that handles the 47-day TLS lifetime mandate, the same discipline that retired SHA-1. The enterprises that treat PQC as just another cryptographic transition, sequenced and engineered, will spend the next decade quietly compliant. The ones waiting for a single-vendor "PQC platform" will spend it firefighting.