NIST finalized FIPS 203 (ML-KEM), FIPS 204 (ML-DSA, formerly Dilithium), and FIPS 205 (SLH-DSA, formerly SPHINCS+) in August 2024, and FIPS 206 (FN-DSA, formerly Falcon) is expected to finalize in 2026. For software artifact signing the relevant algorithms are ML-DSA and SLH-DSA; ML-KEM is a KEM, not a signature scheme. The practical question facing teams in 2026 is not "whether" to migrate but "how" to move signing pipelines from ECDSA P-256 and RSA-2048 to post-quantum algorithms without breaking verification across fleets that contain years-old installers, air-gapped systems, and third-party consumers. This post lays out a concrete, staged migration plan grounded in real library versions, real HSM capabilities, and the current state of Sigstore, Notary v2, and CNCF tooling. The goal is hybrid signing today, pure PQ where we can, and a clear deprecation plan for classical-only paths.
Which algorithms should you target, and in what mode?
ML-DSA-65 (Dilithium3) as the primary, with SLH-DSA-SHA2-128s (SPHINCS+) as the conservative backup. ML-DSA-65 offers 192-bit post-quantum security, roughly 1,952-byte public keys and 3,309-byte signatures, and is fast enough for signing pipelines: OpenSSL 3.5 benchmarks show sub-millisecond signing on commodity hardware. SLH-DSA-SHA2-128s gives stateless hash-based signatures that rely only on hash function security, with 32-byte public keys but 7,856-byte signatures and signing times in the hundreds of milliseconds. SLH-DSA is the hedge: even if a break against lattice assumptions emerges, hash-based signatures remain safe. Hybrid modes combining ECDSA P-256 plus ML-DSA-65 are appropriate during the transition period and are supported in OpenSSL 3.5 via the oqsprovider and natively in upcoming 3.6. CNSA 2.0 (NSA, 2022) prescribes a 2030-2033 deadline for national security systems, which is a useful forcing function.
What tooling already supports post-quantum signatures?
The stack is partial but growing. OpenSSL 3.5 (released 2025) includes ML-KEM and ML-DSA via its own providers, not only through oqsprovider. BoringSSL added experimental ML-DSA in late 2024. liboqs 0.12 (Open Quantum Safe) provides reference implementations across all four finalists. Bouncy Castle 1.78+ supports ML-DSA and SLH-DSA in Java. On the signing-infrastructure side: HSMs are uneven. Thales Luna 7 firmware 7.11 added ML-DSA and SLH-DSA in beta; AWS KMS has not yet exposed ML-DSA as a customer-facing signing algorithm as of early 2026, though AWS CloudHSM firmware 5.15 supports it. YubiHSM 2 firmware 2.5 supports SLH-DSA but not ML-DSA as of the 2025 release. Sigstore's cosign 2.5 includes an experimental --key-alg ml-dsa-65 flag behind a feature gate, and Fulcio has a draft RFC for PQ certificate issuance. Notary v2 (ORAS 1.3) relies on COSE signing and can accept PQ via JOSE extensions being tracked in draft-ietf-cose-dilithium.
How do you do this without breaking existing verifiers?
Hybrid signing during the transition, with coordinated deprecation. Attach two signatures to every artifact: one ECDSA P-256 under your current trust root, one ML-DSA-65 under a new trust root, both in the same OCI artifact or adjacent Rekor log entries. Verifiers that do not understand ML-DSA continue to verify the ECDSA signature; verifiers that do can require both or prefer ML-DSA. CNCF's ORAS 1.3 already supports multiple signatures per artifact via the OCI Artifact Manifest spec (image-spec 1.1). For container images specifically, cosign's ability to attach multiple signatures under the sigstore referrer type makes this mechanical. Crypto-agility in the verifier is the hard part: code that hardcodes "P-256, SHA-256" needs refactoring. Plan on a two-year window where both signatures are required, then a one-year window where ECDSA becomes advisory, then deprecation.
What should your migration timeline actually look like?
Twelve to thirty-six months, sequenced by control point. Months 0 to 3: inventory signing surfaces (release signing, container signing, code signing, OS package signing, SBOM attestations, build provenance). Months 3 to 9: implement hybrid signing in the highest-value pipeline (usually container image releases), with ML-DSA-65 alongside ECDSA. Months 6 to 12: extend to Sigstore-backed SBOM attestations using cosign 2.5's experimental PQ mode. Months 12 to 24: move downstream verifiers (admission controllers like Kyverno 1.14, OS package managers, CI/CD verification steps) to understand ML-DSA. Months 24 to 36: enforce PQ-only for new releases, retain hybrid for long-tail artifacts, and plan the ECDSA sunset. This is aggressive but feasible; CNSA 2.0 deadlines and EU NIS2-adjacent guidance are pulling regulated industries onto similar tracks.
What can go wrong, and where are the gotchas?
Signature size, HSM capacity, and unexpected verifier edges. ML-DSA signatures are 10 to 20 times larger than ECDSA P-256 signatures, which blows up storage and bandwidth for pipelines that sign millions of artifacts (think OS package mirrors). SLH-DSA is worse. HSM throughput is another pinch point: older HSMs lack the NTT acceleration ML-DSA benefits from, so signing latency can balloon. Verifier edges lurk in long-tail places: OS-level package managers on LTS distributions (RHEL 8 still ships OpenSSL 1.1.1-class behavior in some paths), air-gapped installers, and vendor-specific signing formats like Microsoft Authenticode, Apple codesign, and various RPM/DEB configurations. Each of these needs a parallel migration track. Finally, do not forget transparency logs: Rekor 1.4 needs PQ-aware entry types to avoid tying the log itself to ECDSA security.
How Safeguard Helps
Safeguard's provenance store accepts both classical and post-quantum signatures on in-toto 1.0 attestations and SLSA v1.0 predicates, and its verification engine can be configured to require hybrid signatures during the transition and PQ-only at a cutover date per tenant or per product. The policy framework supports algorithm-level allow/deny rules so teams can block ECDSA-only artifacts from specific release channels on a schedule. Migration dashboards surface which products still depend on classical-only signing paths, which HSMs in the environment lack PQ support, and where verifier gaps could block rollout. This makes the plan executable rather than aspirational.