Post Quantum Code Signing

Preparing code signing for post-quantum cryptography

Code signing carries the longest verification horizon of any signing use case. Firmware signed today may be verified for fifteen years or more, and a forged signing key allows an adversary to distribute malicious software that every relying party accepts as genuine. It is the signing function that warrants earliest attention.

Why code signing is different from other digital signing

Three properties separate it from document or transaction signing.

The verification horizon is long. A signed binary distributed in 2026 may still be installed and verified in 2041. An embedded firmware image may be verified for the entire service life of the device, which in industrial and medical estates runs to twenty or thirty years.

The consequence of forgery is immediate and severe. Unlike encrypted data, where compromise produces disclosure, a forged code signing key produces execution. Automatic update mechanisms become remote code execution vectors, and the compromise propagates to every system that trusts the key.

The verifiers are slow-moving and outside the signer's control. Operating system loaders, package managers, container registries and device bootloaders all validate signatures, and each moves on its own schedule. A signer can adopt a new algorithm only when its relying parties can process it.

Which algorithms to use for which artefacts

Signature size, which constrains TLS heavily, matters far less here. An ML-DSA-65 signature of 3,309 bytes is immaterial against a multi-megabyte installer. The constraints that do bind are device-side verification cost, which favours hash-based schemes on constrained hardware, and relying party support.

CNSA 2.0 requires post-quantum software and firmware signing for US national security systems ahead of the general timeline, which makes this the area where regulated organisations encounter the requirement first.

Where the ecosystem has reached

Microsoft added ML-DSA support to Authenticode in Windows 11 24H2 through an updated SignTool release, and code signing work is progressing separately from TLS in the CA/Browser Forum. That separation matters: publicly trusted post-quantum TLS certificates are unavailable, while code signing is moving on its own track.

For internal and firmware signing the position is better still, because the organisation controls both the signing infrastructure and the verifier. Private hierarchies can issue post-quantum code signing certificates now, and hardware security modules have supported LMS and XMSS for several years.

The practical sequencing is therefore the reverse of TLS. Code signing can move earlier because it does not wait on browser root programmes, and it should move earlier because the artefacts have the longest verification horizon.

Timestamping is the control that preserves existing signatures

Migration protects artefacts signed from that point forward. It does nothing for everything already distributed, and that is where trusted timestamping applies.

A timestamp under RFC 3161 attests that a signature existed at a given moment. Applied at signing, it allows a verifier to establish that the signature predates any subsequent compromise of the key, which preserves its evidential value after the algorithm weakens. It also extends validity beyond certificate expiry, which is why timestamping is already standard practice in code signing.

Two conditions apply. The timestamp must be applied at signing, since one applied after a key becomes derivable proves nothing. And the timestamp authority's own algorithms must be migrated in turn, with archival re-timestamping applied before they weaken, as covered in what quantum computing does to digital signature validity.

An organisation that signs without timestamping has no mechanism to preserve the validity of its existing software estate, and that gap should be closed before any algorithm decision is taken.

A practical sequence

Inventory the signing keys

Establish every key used to sign software, firmware, drivers, packages, container images and scripts, including keys held by build systems, third-party developers and outsourced manufacturers. Signing keys sprawl more than certificate estates, because build pipelines accumulate them.

Bring keys into hardware

Any signing key not held in a hardware security module is a candidate for theft today, independent of quantum considerations. Consolidating signing into HSM-backed infrastructure is a prerequisite for post-quantum signing and a current-risk reduction in its own right.

Apply timestamping universally

Confirm that every signing operation applies a trusted timestamp. This is usually a build pipeline configuration change and it protects the existing estate rather than only future artefacts.

Stand up a post-quantum signing hierarchy

A new hierarchy is required, since existing certificate authorities cannot be converted. For firmware, this means LMS or XMSS with rigorous state management in the HSM. For general software, ML-DSA.

Plan re-signing for long-lived artefacts

Firmware and software with long remaining service life may warrant re-signing under post-quantum algorithms where the verifier can process them. This requires the device or platform to accept the new algorithm, so it depends on the verification side being migrated first.

Manage certificate lifetime changes in parallel

Code signing certificate validity is also reducing, and shorter lifetimes increase issuance volume through the same pipelines. Our note on code signing certificates moving to 460 days covers that change.

How Unsung helps

Unsung is a UK-based, vendor-neutral consultancy specialising exclusively in public key infrastructure and cryptographic systems, working across central government, defence, healthcare, financial services, nuclear and transport.

We inventory signing keys and pipelines through our PKI health check and cryptographic bill of materials services, then design signing infrastructure that supports post-quantum algorithms, trusted timestamping and, where firmware signing requires stateful schemes, the hardware security module configuration and operational procedures needed to guarantee state uniqueness. We deliver the hierarchy itself through our PKI design and build practice.

‍