NIST finalized its first three post-quantum cryptography standards in August 2024: FIPS 203 (ML-KEM, derived from Kyber) for key encapsulation, FIPS 204 (ML-DSA, derived from Dilithium) for digital signatures, and FIPS 205 (SLH-DSA, derived from SPHINCS+) as a hash-based signature alternative. A fourth, FN-DSA (derived from Falcon), is scheduled for 2025-2026. Meanwhile CNSA 2.0, published by the NSA in 2022 and updated in 2024, requires post-quantum algorithms for U.S. national security systems by 2030, with software signing specifically required to transition by 2030 and exclusive PQC use by 2033.
For software supply chains this is not abstract. Package signatures, container signatures, Sigstore's transparency log entries, TLS certificates used to pull from registries, and HSMs holding CI signing keys all need migration plans. Here's what that looks like in practice.
What did NIST actually standardize in 2024?
Three algorithms, each answering a different question. ML-KEM (FIPS 203) replaces RSA-OAEP and ECDH for key exchange — the thing that protects your TLS session-key negotiation and any hybrid encryption scheme. ML-DSA (FIPS 204) replaces RSA-PSS and ECDSA for digital signatures — the thing that signs your package release, your container image, and your git tag. SLH-DSA (FIPS 205) is a conservative hash-based alternative to ML-DSA, slower and with larger signatures, intended for long-lived roots of trust where the newer lattice-based assumptions in ML-DSA might worry a standards body.
Concrete sizes matter for supply chain use. ML-DSA-65 (the "Category 3" security level, comparable to RSA-3072) produces ~3,293-byte signatures and ~1,952-byte public keys. SLH-DSA-SHA2-192s produces ~16,224-byte signatures with ~48-byte public keys. ECDSA-P256, by comparison, produces ~64-byte signatures with ~64-byte keys. Every signature on every package release is about to get fifty to two hundred times larger. For Sigstore's transparency log, which currently holds tens of millions of entries, that is a substantial storage and bandwidth shift.
What is "harvest now, decrypt later" and does it apply to signing?
Harvest-now-decrypt-later (HNDL) is the attack where an adversary records encrypted traffic today and decrypts it once a cryptographically relevant quantum computer exists. For confidentiality, HNDL is a clear threat — anything encrypted with RSA or ECDH today and worth decrypting in 10-15 years needs to migrate now.
For signing, the threat is different and in many ways worse. An attacker who eventually forges an old signature can create a plausible historical artifact — a "release" that appears to have been signed by a trusted maintainer in 2024 — and insert it into a supply chain that still accepts pre-quantum signatures. This is why NIST and NSA explicitly call out signing migration rather than treating it as "less urgent than confidentiality." Any package registry, code-signing CA, or transparency log that retains verification capability for legacy RSA or ECDSA signatures past the quantum threshold extends that forgery window. Transparency logs like Sigstore's Rekor are the mitigation here — a signature forged retroactively won't have a valid log entry, so verifiers that require log inclusion are protected even against a future quantum attacker.
How is Sigstore planning the migration?
Sigstore's Rekor v2 and Fulcio roadmap have been tracking PQC since 2023, with concrete hybrid-mode work in 2024-2025. The plan is staged. First, Fulcio issues short-lived certificates, which means the signing key itself has a lifetime measured in minutes — a quantum attacker would need to break ECDSA within the certificate validity window, which is a much harder problem than offline forgery. Second, hybrid signatures (ECDSA + ML-DSA in the same signing operation, both required to verify) give a migration path that stays compatible with older verifiers while protecting new verifiers against ECDSA compromise. Third, Rekor's hash tree itself uses SHA-256, which is still considered quantum-resistant against Grover's algorithm at the 128-bit security level — no structural change needed, just migration of the leaf signatures.
The practical cutover for Sigstore users is likely 2026-2028. Verifier implementations will need to accept hybrid signatures without breaking; policy engines (cosign verify and equivalents) will need to express "require PQC component"; and the root-of-trust update mechanism — the root.json TUF metadata — will itself need PQC signatures, which is a chicken-and-egg problem Sigstore is addressing via offline ceremonies with SLH-DSA backup keys.
What about TLS certificates for registries?
TLS is further along than code signing, and dragging it forward. Cloudflare and Google deployed X25519Kyber768 hybrid key agreement in Chrome 124 and Firefox 132 during 2024, and by late 2025 a majority of Chrome connections to major edge networks were using hybrid KEMs. That protects the session-key negotiation. The server certificate is a separate problem — issuing ML-DSA certificates requires PQC support in the CA, the ACME protocol, the TLS library, and the web server, and as of early 2026, public CAs are running pilots but not yet issuing production PQC certificates at scale.
For registries specifically — npm, PyPI, Docker Hub, Artifactory, Nexus — the migration is gated on the upstream TLS stack. Teams running their own registries on Nginx or Envoy will get PQC TLS "for free" when OpenSSL 3.5 and BoringSSL ship it as defaults, currently expected through 2025-2026. Teams relying on managed registries will inherit the provider's timeline.
What does HSM and signing-key migration look like?
Slow, expensive, and the single biggest operational lift in the PQC transition. Thales, Entrust, Utimaco, and AWS CloudHSM all announced ML-DSA support in 2024-2025, but firmware upgrades require downtime, key ceremonies, and in some cases physical HSM replacement for devices without PQC-capable secure elements. Organizations with code-signing keys in HSMs — Microsoft, Apple, any Linux distro maintainer signing packages — have been running parallel-key ceremonies since 2024, issuing a new ML-DSA key alongside each RSA or ECDSA key and cross-signing.
The realistic timeline for a mid-size engineering org is two to three years from decision to completion. Inventory of every signing key, classification by criticality and expiration, HSM firmware or vendor upgrade, dual-signing period, verifier-side policy update, and finally legacy-key retirement — none of those steps are fast and none are optional.
Should we migrate now or wait?
Start now, but stage it. For anything with a long verification horizon — root CAs, code-signing certificates with multi-year validity, firmware signing keys in devices that will ship for a decade — the migration needs to be in flight in 2026. For TLS to package registries, the migration will mostly happen transparently via library updates over 2026-2027. For package-level signatures on fast-moving dependencies, where a signature's relevant lifetime is measured in months (until the next release), the urgency is lower and you can ride the ecosystem.
The non-negotiable action item for every team is a cryptographic inventory: every signing key, every certificate, every TLS endpoint, every algorithm. CNSA 2.0 and the EU's equivalent roadmaps require this inventory as a precondition for the 2030-2033 deadlines, and the inventory is also the thing that turns "migrate to PQC" from a paralyzing abstraction into a sequenced engineering project.
How Safeguard.sh Helps
Safeguard.sh's SBOM generation captures cryptographic algorithm inventory alongside package inventory — every RSA, ECDSA, and Ed25519 key usage across dependencies, configs, and signed artifacts — so the cryptographic migration list turns into a concrete, diffable report rather than a six-month audit. Reachability analysis flags which cryptographic primitives are actually called at runtime, so teams can prioritize PQC migration for the 20-30% of crypto code that matters and defer the rest. Griffin AI generates migration pull requests for dependency upgrades as PQC-capable library versions land — OpenSSL 3.5 consumers, Go's crypto/mldsa, Python's cryptography package — and validates compatibility across hybrid-mode test suites. The TPRM module tracks vendor PQC readiness in line with CNSA 2.0 and EU timelines, and container self-healing ensures that any deployment relying on deprecated pre-quantum signature verification is caught before it ships.