PQC for Code Signing: Protecting Long-Lived Software and Firmware

Quick answer: Code signing carries a distinct long-lived risk that most PQC planning underweights: a signed installer, firmware image, or update package stays in circulation for years or decades after signing, so a classical signature applied today is exposed for the artifact’s entire lifespan, not just until a quantum computer arrives. Protecting that risk means getting five things right together: choosing the right algorithm, timestamping every signature so it survives certificate expiration, confirming your HSM and timestamp authority actually support post-quantum operations, making sure the verification ecosystem consuming your signatures can check them, and running a parallel signing pilot before any production cutover. This guide covers all five.

Our PQC code signing architecture guide covers algorithm selection and phased migration planning in depth. This guide focuses on what happens after an algorithm is chosen: keeping a signature verifiable for as long as the artifact it protects remains in use, through certificate expiration, TSA and HSM readiness gaps, and an eventual algorithm transition.

Key Takeaways

• Signed software and firmware remain in circulation for years or decades, so the risk window for a classical signature is the artifact’s entire lifespan, not just the time until a quantum computer exists.
• An RFC 3161 timestamp proves a signature was created at a specific time, which is what allows verification to keep succeeding after the signing certificate itself has expired.
• Most public timestamp authorities have not yet shipped post-quantum signing support, and most legacy FIPS 140-2 HSMs lack native PQC algorithm support, two separate readiness gaps that both need checking before a pilot counts as fully post-quantum.
• Firmware with decade-plus deployment lifecycles faces a distinct problem: it cannot be re-signed after deployment, so the signature applied at build time has to remain verifiable for the device’s entire operational life.
• A parallel signing pilot, applying both a classical and a post-quantum signature to the same artifact, lets an organization validate post-quantum tooling without breaking verification for systems that are not yet post-quantum capable.

The Long-Lived Signature Risk

Most quantum risk discussions center on harvest-now-decrypt-later, an attacker capturing encrypted traffic today to decrypt once a quantum computer exists. Code signing carries a related but distinct risk: an attacker who can forge classical signatures once a cryptographically relevant quantum computer arrives can retroactively produce malicious artifacts that appear indistinguishable from legitimate, historically signed software. A signed installer, firmware image, or update package that stays in circulation for years means the exposure window is not the moment a quantum computer appears, it is the entire remaining service life of every classically signed artifact still active at that point. This is why code signing migration planning has to account for artifact lifespan specifically, not just a general migration deadline.

What Timestamping Actually Does

A code-signing certificate has a validity window, typically 460 days under current CA/Browser Forum requirements. Without a timestamp, a signature’s verification depends on checking it against a certificate that has to still be within that validity window at verification time, which becomes a problem the moment the certificate expires, since verifying software signed years ago would otherwise fail.

An RFC 3161 timestamp authority solves this by cryptographically binding a hash of the signature to a trusted, independently verifiable point in time, using its own signing key held in an HSM. A verifier checking a timestamped signature after certificate expiration asks a different question: was the certificate valid at the moment the timestamp proves the signature was created, rather than whether the certificate is valid right now. This is why timestamping every production code-signing operation is treated as mandatory practice, not an optional extra.

Timestamp Authority Post-Quantum Readiness

This is the gap most PQC code signing plans overlook. A timestamp token is itself a digital signature, produced by the TSA’s own key, and that key needs to be post-quantum capable for the timestamp itself to resist future cryptanalysis. As of this guide’s publication, post-quantum timestamping support is still emerging across the TSA ecosystem rather than broadly available, meaning an organization piloting ML-DSA code signing today may find its timestamps are still being issued by a classical RSA or ECDSA TSA key.

That gap matters specifically for long-lived artifacts. A software artifact signed with ML-DSA but timestamped with a classical key inherits a weak link: the timestamp proving when the post-quantum signature was created is itself vulnerable to the same future cryptanalytic risk the post-quantum signature was meant to avoid. Confirm your TSA’s specific post-quantum roadmap and algorithm support before treating a code-signing pilot as fully post-quantum end to end, and re-timestamp critical long-lived artifacts once post-quantum timestamping becomes available from your provider.

HSM Support: The Other Readiness Gap

Timestamp authority readiness is only half the infrastructure question; the HSM holding your actual signing keys is the other half, and CA/Browser Forum requirements mandate that code-signing private keys live in FIPS-validated hardware, not software. Most legacy FIPS 140-2 certified HSMs were built before NIST finalized ML-DSA and SLH-DSA and lack native support for either. Organizations running older HSM firmware need to either upgrade to FIPS 140-3 capable firmware with post-quantum support or run a deliberate dual-stack approach, classical signing continuing on existing hardware while post-quantum signing runs on updated or newly procured HSMs, during the transition window.

Verify your specific HSM model and firmware version against its vendor’s actual shipped post-quantum support, not a roadmap announcement, before committing a production signing pipeline to it. FIPS 140-3 certification for PQC-capable HSM firmware has been progressing across major vendors, but shipped support varies by model and firmware version, and the gap between “the vendor announced PQC support” and “our specific deployed hardware has validated PQC firmware” is exactly where signing pipelines stall.

Long-Term Validation: Beyond a Single Timestamp

Long-term validation (LTV) extends signature verifiability further by embedding revocation-status evidence, such as an OCSP response or CRL, gathered at or near signing time, alongside the timestamp. Together, a trustworthy time source and proof that the signing certificate was not revoked at that time let a signature remain verifiable for extended periods, sometimes cited at up to twenty years for document signing use cases, without requiring the verifier to reach out to a live revocation service that may no longer exist by the time verification happens.

For artifacts with especially long verification requirements, a second timestamp can be applied before the first one’s own trust anchor becomes questionable, effectively re-anchoring the signature’s provable timeline further into the future. This layered approach, not a single timestamp alone, is what genuinely long-lived signature validity depends on.

Firmware: A Distinct Long-Lived Signature Problem

Firmware carries a version of the long-lived signature problem that software updates generally do not: once deployed to a device, it frequently cannot be re-signed or replaced, particularly on embedded or industrial hardware with multi-decade service lives. The signature applied at build time is the only signature that artifact will ever have, which makes the choice of signing algorithm, and the timestamping and long-term validation strategy behind it, a decision with consequences that extend to the device’s entire operational lifetime, not just its initial deployment window.

This is also why hash-based signature schemes like LMS and XMSS, alongside ML-DSA, see specific interest for firmware signing: their security rests on hash function properties rather than newer lattice assumptions, a conservative choice that matters more for an artifact that cannot be re-signed than for one that can be reissued on a normal update cycle.

Verification Ecosystems: The Multi-Year Synchronization Problem

A signature is only useful if the systems checking it can actually validate it, and every operating system, browser, security tool, and installation platform that verifies signed artifacts needs to recognize post-quantum algorithms before it can validate one correctly. This is a genuinely multi-year ecosystem synchronization challenge, not a one-time update: an organization that starts signing with ML-DSA today will produce artifacts that fail validation on any verification system that has not yet been updated to recognize that algorithm, which is precisely the compatibility risk a parallel signing pilot is designed to manage.

Map your actual verification ecosystem before rollout, not just the signing side: which operating system versions, security tools, and installers your customers or internal users actually run, and which of those already recognize post-quantum signatures. A signing pipeline that is technically ready is not the same as a deployment that will actually validate for your real user base.

Running a Parallel Signing Pilot

The practical way to validate post-quantum code signing tooling without risking production verification is to apply both a classical and a post-quantum signature to the same artifact, a detached dual-signature pattern rather than a single hybrid signature. Systems that already validate the classical signature continue working unchanged; systems updated to check for the post-quantum signature can verify it independently. This lets an organization exercise its ML-DSA signing infrastructure, HSM support, timestamping, and CI/CD integration in production conditions while every existing verifier keeps working exactly as it did before the pilot began.

What We’d Actually Recommend

Confirm both your timestamp authority’s and your HSM’s specific post-quantum algorithm support before treating any ML-DSA signing pilot as fully quantum-resistant end to end; the signature, the timestamp, and the hardware behind both need to be post-quantum for the artifact to actually be protected. Run parallel classical and post-quantum signing on production artifacts now, rather than waiting for a full cutover, to validate the tooling with real production conditions and zero verification risk. For firmware and other artifacts that cannot be re-signed after deployment, treat the signing algorithm and timestamping strategy as a decision with consequences lasting the device’s entire operational life, and weight that decision accordingly. Map your verification ecosystem in parallel with your signing infrastructure, since a technically complete signing pipeline still fails in production if the systems checking those signatures have not caught up.

How Encryption Consulting Can Help

CodeSign Secure, Encryption Consulting’s enterprise code signing platform, is built specifically for the risk this guide describes: it supports ML-DSA and SLH-DSA signing with detachable signatures, holds keys inside FIPS-validated HSMs, and enforces RFC 3161 timestamping as a policy-controlled step in every signing workflow, so the timestamp and HSM readiness gaps covered above are addressed at the platform level rather than left to individual pipeline configuration. Firmware and IoT signing is supported through LMS (NIST SP 800-208), the hash-based scheme this guide flags for artifacts that cannot be re-signed after deployment.

Our PQC Advisory Services build the TSA readiness evaluation, verification ecosystem mapping, and parallel signing pilot covered in this guide into a structured migration plan, sequenced against the broader architecture roadmap in our companion guide.

The Signature Is Only as Strong as Its Weakest Link

Protecting a long-lived signed artifact takes more than choosing a post-quantum algorithm. The timestamp proving when it was signed, the HSM holding the key that signed it, and the verification ecosystem checking it years later all need to be post-quantum ready together, since a gap in any one of them undermines the protection the algorithm choice was meant to provide. Confirming TSA and HSM readiness explicitly, layering long-term validation evidence, treating firmware’s cannot-be-re-signed constraint as a first-class design input, and mapping the verification ecosystem alongside the signing pipeline are what actually determine whether a signature applied today still means something in twenty years.

Frequently Asked Questions

Why does timestamping matter more during a post-quantum transition?

Timestamping proves a signature was created at a specific point in time, which is exactly the evidence needed to prove a signature was made before a classical algorithm was deprecated, protecting it against retroactive forgery claims once quantum computers can break that algorithm.

Are timestamp authorities and HSMs post-quantum ready today?

Support is still emerging across both ecosystems rather than broadly available. Most legacy FIPS 140-2 HSMs lack native ML-DSA or SLH-DSA support, and most public TSAs have not shipped post-quantum signing either. Confirm your specific vendor’s shipped, not announced, support before treating a pilot as fully post-quantum.

Why is firmware signing different from regular software signing for PQC purposes?

Firmware, particularly on embedded and industrial hardware, often cannot be re-signed once deployed. The signature applied at build time has to remain verifiable for the device’s entire operational life, which can span decades, making the initial algorithm and timestamping decision far higher-stakes than for software that receives regular updates.

What is a parallel signing pilot?

Applying both a classical and a post-quantum signature to the same artifact as two separate, detached signatures. Existing verifiers keep validating the classical signature unchanged while updated verifiers can check the post-quantum signature independently, letting an organization test post-quantum signing infrastructure with zero risk to current verification.

How long can a properly timestamped signature remain verifiable?

With long-term validation combining a timestamp and embedded revocation-status evidence, verification periods of up to twenty years are cited for document signing use cases. Re-timestamping before the original timestamp’s trust anchor becomes questionable can extend that further for especially long-lived artifacts.