Most post-quantum planning starts with TLS. It is the wrong place to start. The signatures that need to survive a quantum computer longest are not on network connections that live for milliseconds, they are on the firmware, drivers, and software packages that ship today and remain trusted for ten, fifteen, or twenty years.
A code signature is a promise that outlives the connection that delivered it. When you sign a firmware image with RSA-3072 and ship it into a medical device, an industrial controller, or a car, that signature must verify correctly for the entire operational life of the hardware. If a quantum computer can forge that signature before the device is retired, an attacker can push malicious firmware that the device accepts as genuine. That is a different and more durable exposure than a decrypted TLS session.
This post explains why code signing is the most time-sensitive post-quantum migration, what the NIST signature standards mean for it, and how to prepare a signing estate that will not need re-signing in a panic later.
PQC Migration Trajectory (CNSA 2.0 Timeline)
Projected algorithm distribution across enterprise infrastructure
⚠️ Organizations that haven't started inventory by 2026 will miss CNSA 2.0 network equipment deadline (2030) — migration typically takes 3-5 years.
The Signature Lifetime Problem
The quantum threat to signatures is forgery, not decryption. A quantum computer running Shor’s algorithm can derive a private key from a public RSA or ECDSA key, and once it has the private key it can forge signatures that verify perfectly. For a signature, the dangerous window is the entire period during which anyone still trusts it.
Compare the relevant lifetimes:
| Signed Artifact | Typical Trust Lifetime | Quantum Exposure |
|---|---|---|
| TLS handshake signature | Milliseconds to minutes | Effectively none (session is long over) |
| Software package signature | Months to a few years | Moderate |
| Driver / OS component signature | 5-10 years | High |
| Firmware signature (embedded, industrial, medical, automotive) | 10-20+ years | Severe |
| Root / intermediate signing certificate | 10-25 years | Severe |
TLS is near the bottom of this list for signature urgency, because the signature authenticating a handshake is worthless to an attacker the moment the handshake ends. Firmware is at the top. A signature applied to a device shipping in 2026 that stays in the field until 2041 must resist a quantum computer that may well exist within that window.
This inverts the usual migration order. For key exchange, TLS is urgent because of harvest-now-decrypt-later. For signatures, long-lived signing is urgent because the artifact itself carries the trust forward in time.
The NIST Signature Standards for Code Signing
The post-quantum signature options come from two finalized NIST standards, and the choice between them matters more for code signing than for most uses.
| Standard | Algorithm | Basis | Signature Size | Best Fit for Signing |
|---|---|---|---|---|
| FIPS 204 | ML-DSA (Dilithium) | Module lattices | ~2,400-4,600 bytes | General-purpose code and document signing |
| FIPS 205 | SLH-DSA (SPHINCS+) | Hash functions | ~7,800-49,000 bytes | Long-lived, high-assurance firmware where conservative security matters most |
ML-DSA is the efficient default: reasonable signature sizes and fast verification. SLH-DSA is the conservative fallback. Its security rests only on the strength of hash functions, which are far better understood than lattice problems and not threatened by any known quantum attack beyond Grover’s modest speedup. The cost is large signatures.
For firmware with a twenty-year horizon and no tolerance for a future cryptanalytic surprise, the conservatism of SLH-DSA is often worth its size penalty. For routine software distribution, ML-DSA is the practical choice. Many mature signing programs will use both: ML-DSA broadly, SLH-DSA for the small set of artifacts where longevity and assurance dominate every other concern.
Why This Is Harder Than Rotating a TLS Certificate
Migrating code signing to post-quantum algorithms is operationally harder than migrating TLS, for reasons that have nothing to do with the cryptography itself.
The verifier is often fixed. A TLS client updates frequently. A device in the field verifying firmware signatures may never update its verification logic, or may update it only through the very signing process you are trying to migrate. If the bootloader only understands RSA, you cannot ship it an ML-DSA-signed update until the bootloader itself can verify ML-DSA, a chicken-and-egg problem that must be designed around years in advance.
Signatures are embedded in long supply chains. Firmware is signed by a vendor, integrated by an OEM, and deployed by an operator. Migrating the algorithm requires coordination across every party in that chain, each on their own timeline. This is the supply-chain dependency that makes code signing migration a multi-year, multi-organization effort.
Hardware signing roots are slow to change. Code signing keys usually live in HSMs, and the HSM must support the new algorithm before you can sign with it. Hardware refresh cycles are measured in years, which means your signing infrastructure’s quantum readiness is gated by your hardware vendor’s roadmap.
Size breaks assumptions. A bootloader that allocated a fixed 256-byte field for an RSA signature cannot hold a 3,300-byte ML-DSA signature, let alone a 40,000-byte SLH-DSA one. Firmware formats, update packages, and verification buffers were often designed around small signatures, and those assumptions are now constraints.
Preparing a Signing Estate for Post-Quantum
The work divides into inventory, design, and sequencing, the same program discipline as any post-quantum migration, applied to signing specifically.
Inventory Every Signing Operation
You cannot migrate signing you have not mapped. Build an inventory that answers, for every signing operation:
- What algorithm and key size is used, and where is the private key stored (HSM, software, cloud KMS)?
- What artifact is signed, and how long must that signature remain trusted?
- What verifies the signature, and can that verifier be updated?
- Who owns the signing operation, and who are the downstream integrators?
The longest-trust-lifetime, hardest-to-update verifiers are your migration priorities. A firmware image for a device that cannot be field-updated and stays deployed for fifteen years outranks a software package re-signed every release.
Design for Dual-Signature Transition
The practical migration path for code signing is dual signing: sign artifacts with both a classical algorithm and a post-quantum algorithm during the transition. Verifiers that understand only the classical algorithm continue to work; verifiers updated to understand the post-quantum algorithm prefer it.
This requires verifiers that can ignore a signature they do not understand rather than reject the whole artifact, a property that must be built into verification logic before the transition, not during it. Programs that design for dual signing early migrate smoothly. Programs that did not often cannot migrate at all without first shipping an update through the old signing scheme to teach the verifier the new one.
Sequence by Verifier Updatability, Not Convenience
Order the migration by how hard the verifier is to change:
- Cloud and server-side verification you fully control, update first to prove the mechanics.
- Frequently-updated software (applications, packages) where the verifier rides along with normal releases.
- OS and driver signing, coordinated with platform vendors.
- Field firmware with updatable verifiers, migrated through the dual-signature path.
- Field firmware with fixed verifiers, the hardest cases, which may require hardware refresh or acceptance of residual risk documented and owned.
The Cost of Treating Code Signing as a Later Problem
An organization that migrates TLS, declares post-quantum progress, and leaves code signing for later discovers the problem has a time dimension it cannot recover. Every firmware image signed with a classical algorithm in the intervening years is another artifact that will need re-signing, or will carry quantum-forgeable trust for its entire field life.
Unlike a TLS certificate, which you simply replace at renewal, a signature already shipped into a deployed device cannot be quietly swapped. Either the device supports re-verification of a new signature, or the original classical signature remains the trust anchor until the device dies. The signing decisions you make this year determine how much re-signing, or residual exposure, you carry for the next fifteen.
That is why, for signatures, the honest migration order puts long-lived code signing near the front, not the back.
FAQ
Q: Why is code signing more time-sensitive for post-quantum than TLS? Because a code signature must stay trusted for the entire lifetime of the artifact it protects, often ten to twenty years for firmware, while a TLS handshake signature is worthless to an attacker the moment the connection ends. The signature carries trust forward in time, so it is exposed to a future quantum computer in a way an ephemeral handshake is not.
Q: Should I use ML-DSA or SLH-DSA for code signing? ML-DSA (FIPS 204) is the efficient general-purpose default with reasonable signature sizes. SLH-DSA (FIPS 205) is the conservative, hash-based choice for the longest-lived, highest-assurance firmware, at the cost of much larger signatures. Many programs use ML-DSA broadly and reserve SLH-DSA for artifacts where longevity and assurance outweigh size.
Q: What is dual signing and why does it matter? Dual signing applies both a classical and a post-quantum signature to an artifact during the transition. Old verifiers use the classical signature; updated verifiers prefer the post-quantum one. It is the practical path to migrating signing without breaking verifiers that have not yet been updated, but verifiers must be designed to tolerate unknown signatures first.
Q: Why can’t I just re-sign everything when quantum computers arrive? Signatures already shipped into deployed devices cannot be swapped unless the device supports verifying a new signature. For field hardware with fixed verifiers, the original classical signature remains the trust anchor for the device’s life. Re-signing later is impossible for exactly the artifacts that need it most.
Q: What gates my signing infrastructure’s quantum readiness? Usually the HSM. Signing keys live in hardware, and the HSM must support ML-DSA or SLH-DSA before you can sign with them. Hardware refresh cycles are measured in years, so your signing readiness depends on your HSM vendor’s post-quantum roadmap as much as your own planning.
About QCecuring
QCecuring helps enterprises bring code signing into their post-quantum program instead of leaving it until last. Our platform inventories every signing operation, maps signature lifetimes against verifier updatability, and supports dual-signature transition workflows, so the firmware and software you sign today does not become the quantum exposure you cannot fix tomorrow.
Map your code signing for post-quantum readiness
Tags: Post-Quantum Cryptography, PQC, Code Signing, Firmware Signing, ML-DSA, SLH-DSA, FIPS 204, FIPS 205, Software Supply Chain, HSM, Dual Signing, Quantum Risk, Secure Boot, Crypto-Agility