Post-Quantum Code Signing and PKI: Migrating to ML-DSA

The firmware you sign this quarter may still be verifying update packages in 2040, on a device you can no longer reach. That, not encryption, is why code-signing PKI is the part of your estate that has to go post-quantum first.

Most post-quantum writing is about confidentiality: the harvest-now-decrypt-later attacker who records your encrypted traffic today and reads it once a large quantum computer exists. Code signing has a different, quieter problem, and it is worse in one specific way. A signature does not leak a secret. But a device that trusts an RSA or ECDSA signing key today will keep trusting it for its whole service life, and if that key’s algorithm is broken while the device is still fielded, an attacker can forge an update the device will happily install. The exposure is not the signature you captured; it is the verifier you cannot patch.

The threat model for signatures is not the one for encryption

Getting this distinction right changes what you migrate first. For data in transit, you prioritise the long-lived secrets an adversary would want to keep. For signing, you prioritise by verifier lifespan and root-of-trust reachability. A build server that signs artefacts consumed and discarded within days is a low-urgency case; you can rotate its keys whenever you like. A hardware root of trust burned into silicon on a device with a fifteen-year life, or a firmware image that a fleet in the field will validate against a pinned public key long after your current signing ceremony is a memory, is the urgent case. The question is not “is this encrypted”, it is “how long will something out there keep believing this key, and can I reach it to change its mind”.

Why code signing is the awkward one

Three properties make code signing harder to migrate than most of your cryptography. First, verification is often embedded where you cannot update it: bootloaders, secure elements, trust anchors written into a manufacturing image. Second, the asymmetry runs against you. You control the signer, which you can upgrade; you do not control every verifier, and many of them will never see a firmware update that teaches them a new algorithm. Third, signatures live inside formats and protocols with fixed field sizes and tight flash budgets, and post-quantum signatures are large. You are changing the most constrained, least reachable part of the stack.

This is where an honest cryptographic inventory earns its keep. You cannot sequence a migration you cannot see. Before any of this, you need to know every place your organisation issues, embeds or verifies a signature, and which of those verifiers you can reach. If that inventory does not exist yet, it is the first deliverable, not an afterthought.

What ML-DSA is, and what it costs you

ML-DSA is the Module-Lattice-Based Digital Signature Algorithm, standardised by NIST as FIPS 204 and effective from 14 August 2024. It descends from the CRYSTALS-Dilithium submission and comes in three parameter sets: ML-DSA-44, ML-DSA-65 and ML-DSA-87, mapping to NIST security categories 2, 3 and 5 respectively. It is the general-purpose post-quantum signature you will reach for in a PKI.

The cost is size. An ML-DSA-87 public key is 2,592 bytes and its signatures run to roughly 4.6 KB, against a 64-byte public key and a 64-to-72-byte signature for ECDSA P-256. That is not a rounding error on a constrained device or in a protocol with a fixed signature field. Plan for it explicitly: check that your certificate transport, your update manifest format, your flash layout and your verification timing all tolerate signatures two orders of magnitude larger. For firmware specifically, the stateful hash-based schemes LMS and XMSS are also permitted and have had validated implementations available earlier, at the cost of careful state management to avoid one-time-key reuse. ML-DSA is the safer default where you cannot guarantee that state discipline.

Hybrid first, then pure

You cannot flip a fleet you cannot update all at once, so the transition is dual-signature. Each artefact carries both a classical signature and an ML-DSA signature. Legacy verifiers check the classical one and ignore what they do not understand; post-quantum-aware verifiers prefer the ML-DSA one. A verifier accepts the artefact if a signature it trusts and understands validates. This buys you the thing you actually need: the ability to ship new-root-aware devices and updated verifiers gradually while the old fleet keeps working, then retire the classical signature once the last verifier that needs it is gone.

# OpenSSL 3.5+ ships native ML-DSA (FIPS 204) support.

# 1. Generate an ML-DSA-87 signing key and a self-signed signing certificate.
openssl genpkey -algorithm ML-DSA-87 -out mldsa87-signing.key
openssl req -new -x509 -key mldsa87-signing.key 
    -subj "/CN=Firmware Signing 2026 (ML-DSA-87)" 
    -days 3650 -out mldsa87-signing.crt
openssl pkey -in mldsa87-signing.key -pubout -out mldsa87-pub.key

# 2. Dual-sign the artefact during the transition: keep the classical
#    signature so today's fielded fleet still verifies, and add the PQC
#    signature so devices trusting the new root verify quantum-safely.
openssl dgst -sha384 -sign ecdsa-p384.key 
    -out firmware.bin.ecdsa.sig firmware.bin
openssl pkeyutl -sign -rawin -in firmware.bin 
    -inkey mldsa87-signing.key -out firmware.bin.mldsa.sig

# 3. A verifier accepts the artefact if EITHER trusted signature is valid.
#    Legacy devices check only .ecdsa.sig; PQC-aware devices prefer .mldsa.sig.
openssl pkeyutl -verify -rawin -in firmware.bin 
    -pubin -inkey mldsa87-pub.key -sigfile firmware.bin.mldsa.sig

The design point in that snippet is the OR, not the algorithm. Two independent signatures, each verifiable alone, so the two halves of your fleet never have to be at the same stage at the same time. Composite certificate formats that bind a classical and an ML-DSA key into one credential are being standardised too; they are cleaner where both endpoints understand them, but the loosely coupled dual-signature approach is what survives contact with a fleet you cannot fully control.

The clock you are actually working to

For anyone selling into US national security systems, the NSA’s CNSA 2.0 guidance is the operative deadline, and software and firmware signing is deliberately at the front of it: support and prefer CNSA 2.0 algorithms by 2025, and use them exclusively by 2030. ML-DSA-87 is the specified signature algorithm, with LMS and XMSS permitted for firmware and software signing. Even outside that scope, 2030 is a reasonable planning horizon, because the binding constraint is not the signer, it is the service life of what you ship now. A device sold in 2027 with a ten-year life is still verifying in 2037. The relevant NIST and CNSA 2.0 timeline is really a statement about the products you are designing today.

None of this is a rip-and-replace. It is a sequencing problem: inventory the verifiers, introduce an ML-DSA root, dual-sign through the overlap, and retire the classical leg device class by device class as the fleet ages out. Do it as a one-off and you will do it again for the next algorithm; build it as an abstraction so the signing algorithm is a configuration choice rather than a rewrite, and the next migration is a parameter change. That is the same discipline that makes crypto-agility pay for itself against more than one regulatory driver, and it is worth reading alongside the board-level view of what post-quantum actually asks of the organisation before you commit budget.

The trap is treating this as a cryptography project. It is a fleet-management project with a cryptographic core: the hard part is not generating an ML-DSA key, it is knowing which of the things in the field will still be listening in 2035, and reaching them before someone else forges the update they are waiting for.