Code signing is your first post-quantum deadline

A firmware signing key generated in 2019 for a product with a fifteen-year field life has to verify in 2034. If that verification depends on ECDSA P-256, the trust anchor outlives the algorithm’s approved life by design, and no amount of TLS migration changes it. The device in the field cannot renegotiate; it can only check the signature your pipeline produced years earlier.

That is why code signing, not TLS, is the first post-quantum deadline most organizations will actually miss. Key exchange fails visibly and can be retried. A signature that cannot be verified on a device you cannot reach is a recall.

Why signatures move before key exchange

Three properties make signatures harder, and all three are structural.

Lifetime. A signature is an assertion about a specific byte sequence at a specific time. Software artifacts are re-signed constantly, but firmware images, document archives, and certificate hierarchies are not. A signature made in 2028 may need to verify in 2040.

Location. The verifier is often code you shipped years ago: a bootloader in ROM, a secure element with fixed firmware, an update agent on a device with no field service path. You control the signer. You do not control the verifier’s algorithm support.

Irreversibility. Re-signing an artifact that has left the building means re-issuing it, re-qualifying it, and shipping it again. For a medical device or an industrial controller, that is a regulated change, not a build step.

A TLS session key, by contrast, is discarded in seconds and can be replaced on your schedule. That asymmetry is the whole argument for starting with signing keys.

What CNSA 2.0 actually requires

CNSA 2.0 version 2.1, published in December 2024, is more prescriptive than the NIST standards alone suggest. It approves ML-KEM and ML-DSA, requires LMS or XMSS per NIST SP 800-208 for software and firmware signing, and does not approve SLH-DSA for national security systems.

Artifact class	CNSA 2.0 requirement	Operational note
Firmware signing	LMS or XMSS (SP 800-208)	Stateful; the hard part is state
Software signing	LMS or XMSS (SP 800-208)	Pipeline integration and state custody
General signatures	ML-DSA, ML-DSA-87 at the CNSA 2.0 level	Stateless, larger signatures
Key establishment	ML-KEM, ML-KEM-1024 at the CNSA 2.0 level	Separate migration track
SLH-DSA	Not approved for national security systems	Valid elsewhere, not a safe default

The last row catches teams who assume FIPS 205 is a universal fallback. It is not on the list for national security systems, and if you sell into that market your evidence will name LMS or XMSS.

The dates attached to this are fixed. New national security system acquisitions are expected to be CNSA 2.0-compliant by default from January 1, 2027, and CNSA 2.0 algorithms are mandated by December 31, 2031. Executive Order 14412 sets the same 2031 date for digital signatures on high-value assets and high-impact systems.

Stateful hash-based signatures are an operational problem

LMS and XMSS are stateful. Each one-time key is consumed in sequence, and the signer must never reuse an index. Reuse does not weaken the signature; it breaks the scheme, and two signatures under the same one-time key are enough to forge.

That produces requirements your signing pipeline probably does not meet.

State lives in an HSM or a transactional store with a single writer, never in a file on the build agent.
No restoring the signing host from a VM snapshot, and no failing over to a replica with stale state. A snapshot rollback can silently reuse indices.
Multi-region signing requires reserved index ranges, not a shared counter read at signing time.
Capacity is finite and planned. Tree height determines how many signatures the key can produce, and running out is a migration event with a lead time.
Audit logs must record the index consumed for each signature, because that log is your proof that no reuse occurred.

This is where teams get it wrong and where audits find the gap. The mathematics is sound; the operations around a stateful key are not.

Key custody, and the validation queue you cannot skip

Post-quantum signing means new keys, which means new modules, which means FIPS validation. Two facts set the timeline: FIPS 140-2 certificates moved to the CMVP historical list on September 21, 2026, and the FIPS 140-3 queue has averaged roughly 18 months, with 18 to 30 months a realistic planning range.

If the HSM firmware supporting ML-DSA-87 or LMS is not validated on your timeline, your signature migration slips regardless of your code. Ask vendors for the certificate number and the exact firmware version it covers. Treat “supports ML-DSA” without a certificate as a roadmap item, not a capability you can deploy.

Custody has a less obvious requirement too: the classical public key must stay available to verify artifacts signed before the migration. Retiring a signing key and deleting its public key are different operations, and the second one breaks your archive.

Firmware and software pipelines fail differently

Dimension	Firmware	Software
Verifier	Bootloader or ROM, fixed at manufacture	OS or agent, updatable
Artifact lifetime	Ten to twenty years	Weeks to months
Re-issuable	Rarely, and only with field update capability	Yes, on the next build
Failure mode	Bricked device or recall	Blocked deployment
First fix	Dual-signature support in the verifier	Signing service and verification policy

Firmware’s binding constraint is the verifier you already shipped. Before you can move to LMS or ML-DSA, the device has to check both the old and new signatures, which means a hardware generation carrying both verification paths, designed now to be in the field before 2031.

Software’s constraint is policy spread. One artifact is verified in the build system, in the registry, in admission control, and sometimes by the customer, each with its own trust store and its own tolerance for a larger signature.

A sequence that survives audit

Inventory signing keys and what they sign. Key identifier, algorithm, artifact class, expiry, custodian, and every verifier that trusts it.
Choose an algorithm per artifact class. Not one algorithm for everything. ML-DSA-87 where stateless signing is supported, LMS or XMSS where CNSA 2.0 or long-lived firmware demands it, dual signatures during the transition.
Stand up a parallel pipeline. New key, new signer, dual-sign, publish both. Do not convert the existing pipeline in place; you need the old path working while you debug the new one.
Ship verifier support before you need it. The consuming device or agent must accept the new signature type before you can retire the old one. This has the longest lead time and is the step most often skipped.
Re-sign the backlog for everything still in support, in dependency order, and record which artifacts remain on the old scheme.
Rotate and retire only after the last verifier that requires the classical signature is gone. Keep the old public keys for archive verification, and destroy the private keys on a documented schedule.

The sequencing matters more than the algorithm choice. A team that picks ML-DSA correctly but converts its pipeline in place will spend a quarter unable to sign anything, a worse outcome than a slower, correct migration.

The dates to put on the plan

Choose the validated module by 2027, so validation completes before you need to deploy. Pilot dual signing in 2027 and 2028, while the verifier generation ships. Re-sign the backlog by 2030. Retire classical signing keys by December 31, 2031, when Executive Order 14412 and CNSA 2.0 converge on signatures.

If your product has a fifteen-year field life, the binding date is not 2031. It is the last date you can change the verifier, set by your hardware roadmap rather than by regulation.