Migrating code signing to ML-DSA: a practical plan

Code signing runs on a different clock from TLS. Recorded traffic is protected only by the key exchange, which is why hybrid ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism) comes first there. A signature only has to resist forgery while its trust anchor is live, but the verifier that checks it can sit in a bootloader for a decade, and you cannot patch a verifier with an update that verifier cannot verify. That lead time, not threat urgency, is why the official timelines put software and firmware signing early: NSA CNSA 2.0 (Commercial National Security Algorithm Suite 2.0) requires exclusive use of ML-DSA-87 or LMS/XMSS for software and firmware signing by the end of 2030 for US National Security Systems, three years ahead of browsers, servers, cloud services and operating systems.

Why signing deadlines land before key exchange deadlines

Harvest now, decrypt later does not apply to signatures. Nobody can record a signature today and forge a new one from it later. The exposure is different: a quantum-capable attacker who can recover a signing private key from its public key could sign firmware that your installed base still trusts. The mitigation is to get a post-quantum verifier into that installed base long before the key becomes forgeable, and installed bases move slowly.

Three properties make signing the long pole. First, verifiers are everywhere and often immutable: ROM boot stages, secure elements, air-gapped provisioning tools, customer appliances, offline installers. Second, trust anchors are embedded, so changing an algorithm means distributing new public keys through a channel that is itself signed. Third, the last update a device accepts under the old algorithm is the one that must teach it the new one, so a device retired from your update pipeline before that point stays classical forever. Plan that end-of-life decision explicitly rather than discovering it in 2030.

None of this requires a prediction about when a cryptographically relevant quantum computer exists. The dates below come from published policy and guidance, and they are what your release engineering roadmap has to meet.

ML-DSA, SLH-DSA, LMS and XMSS: picking per use case

NIST published FIPS 204 (ML-DSA, Module-Lattice-Based Digital Signature Algorithm) and FIPS 205 (SLH-DSA, Stateless Hash-Based Digital Signature Algorithm) as final standards on 2024-08-13 (FIPS 204, FIPS 205). The stateful hash-based schemes LMS and XMSS are approved under NIST SP 800-208. CNSA 2.0 names ML-DSA-87 and LMS/XMSS for software and firmware signing, with SHA-384 or SHA-512 for hashing.

For most release pipelines ML-DSA is the default, because it is stateless and therefore safe to run in a distributed CI system with multiple signers. Stateful schemes are attractive for constrained bootloaders, but the operational rule is unforgiving: the signer state must never be duplicated, which rules out ordinary virtual machine snapshots, warm standby clones and restore-from-backup of a signing host. If you cannot guarantee that in your environment, choose a stateless scheme.

Size matters in a way it did not with ECDSA. Post-quantum public keys and signatures are substantially larger, and SLH-DSA signatures are larger again. Read the parameter tables in FIPS 204 and FIPS 205 before you size a signature field in a firmware header, a flash partition, a manifest schema or an over-the-air update budget. A fixed-width signature field in an existing image format is a common blocker, and it is a format change, not a cryptography change.

Verifier first: the update order you cannot reorder

The sequence below is the whole plan. Steps 2 and 3 must complete across the fleet before step 5 begins.

1. Inventory verifiers, not just signers. List every place a signature is checked: bootloaders, secure elements, package managers, installer frameworks, update agents, admission controllers, provisioning tools, partner validation scripts. Record which ones you can update, by what channel, and which are frozen.
2. Add post-quantum verification while still accepting the classical algorithm. The new verifier must be tolerant: accept old signatures, accept new ones, and record which it saw.
3. Ship that verifier through the existing classically signed path, then distribute the new trust anchors. Measure coverage with real telemetry, by device and by version, not by assumption.
4. Enrol signing keys in hardware and run a parallel, non-production signing pipeline end to end, including revocation and timestamping.
5. Start dual signing production artifacts once the tolerant verifier is the overwhelming majority.
6. Require post-quantum signatures only when telemetry shows the old verifiers are gone, with a written decision for the stragglers: extended support, field replacement, or documented end of life.
7. Drop the classical signature last, and keep the ability to re-sign archived artifacts so old releases stay verifiable under the new scheme.

Dual signing: the two modes, and the trap

Dual signing means attaching two independent signatures (one classical, one post-quantum) to the same artifact, usually in a container format that supports multiple signature slots. Check whether yours does before designing anything else: some formats allow several signers natively, others require an out-of-band detached signature or a format revision.

The design decision that matters is the verification policy. In permissive mode a verifier accepts the artifact if either signature validates, which keeps old clients working but means your effective security is the weaker of the two algorithms. In strict mode the verifier requires both, which raises security but creates an availability risk: a single mistake in either pipeline blocks every release. The usual path is permissive during rollout, strict once the fleet is ready, then post-quantum only. Write the policy down per verifier class and per artifact type, and make the transition dates explicit; this is exactly the kind of planned algorithm change that crypto-agility is supposed to make routine.

HSM, PKI and toolchain support: what to verify, not assume

Support for post-quantum signatures is moving quickly across hardware security modules, certificate authorities and signing tools, and version requirements differ between products and even between firmware branches of the same product. Do not take a vendor blog post as a commitment. Ask for the release notes and the validation record, and test in staging. The items below are the questions to put in writing:

• Does the HSM firmware implement ML-DSA, at which parameter sets, and is there a FIPS 140-3 validated version or a dated roadmap to one? If CNSA 2.0 applies to you, ML-DSA-87 is the relevant parameter set.
• Is it reachable through the interface your pipeline uses (PKCS#11 mechanism, KMIP object types, cloud KMS API, vendor SDK), and can keys be generated in hardware and never exported?
• For LMS or XMSS: is key generation and state advance performed inside the cryptographic module, with no mechanism that could duplicate state, as SP 800-208 requires?
• Can your certificate authority issue certificates with post-quantum subject keys, and can it sign revocation data your verifiers will accept? Hierarchies may need a parallel post-quantum chain rather than an in-place change.
• Does your timestamp authority support the new algorithm, so signatures remain verifiable after certificate expiry?
• Do your artifact signing and transparency tools, package build systems and verification libraries support it in the exact versions you deploy? OpenSSL, for example, requires 3.5 or later for the ML-KEM TLS groups; for signature support check the release notes of the specific version you ship, in both the signing and verifying environments.
• Throughput and latency: larger signatures and new code paths change signing time per artifact and download size. Benchmark with your real release volume.

The dates to plan against

The following is information, not legal advice. Status matters as much as the date: a draft is not a standard, and guidance to Member States is not an obligation on companies.

Primary sources: OMB M-26-15, the EU Coordinated Implementation Roadmap, the ANSSI PQC FAQ, UK NCSC migration timelines and NIST IR 8547 ipd. For CNSA 2.0 the published sources are the CNSA 2.0 FAQ v2.1 (December 2024) and the CNSA 2.0 Algorithms advisory (2025-05-30).

Product makers should also note that the Cyber Resilience Act, Regulation (EU) 2024/2847, Annex I, Part I (2)(e) requires protecting confidentiality by state-of-the-art mechanisms and does not name post-quantum algorithms; its reporting obligations apply from 2026-09-11 and it applies fully from 2027-12-11 (EUR-Lex). Treat secure update and signature verification as part of that state-of-the-art argument, and keep the signing key inventory in the same register as the rest of your cryptography.

Start with what you can measure today

Signing migration is a multi-year fleet programme, so begin with the two cheap things: a list of every verifier you own with its update channel, and a staging signing pipeline that produces a dual-signed artifact end to end. In parallel, confirm the transport side is already on hybrid key exchange, since that is where recorded traffic is at stake and where the fix is a configuration change rather than a fleet rollout. You can scan your domain with PQC Status to see whether your release, update and artifact hosts negotiate X25519MLKEM768, which TLS versions and cipher suites they offer, and what their certificate chain looks like. The scan describes the externally visible TLS configuration only: it is not a certification, and it does not inspect your code signing pipeline, so pair it with the verifier inventory above.