Code Signing in the Post-Quantum Era

Why Code Signing Is Different

Transport encryption can often be upgraded at the edge. Code signing is harder because signed artefacts move through build systems, repositories, update clients, operating systems, devices and audit processes. Every verifier must understand the signature format and policy.

NIST's transition guidance calls out code signing as a specific use case because some devices cannot update the code that verifies signatures after manufacturing. If those devices remain in use after cryptographically relevant quantum computers arrive, the verification design has to account for quantum-resistant signatures much earlier.

That makes code signing a lifecycle problem. The signing service, the verifier, the firmware or package format, the rollback policy and the supplier roadmap all need to be visible in the migration plan.

Inventory These Code-Signing Surfaces

Build and release pipelines

-CI/CD signing keys
-release artefact signatures
-container image signing
-package repository metadata

Client and server software

-desktop installers
-mobile app distribution
-server binaries
-plugin and extension signing

Firmware and devices

-bootloader verification
-over-the-air updates
-device recovery images
-factory provisioning

Supplier trust

-third-party packages
-managed updater services
-HSM or KMS providers
-certificate authorities

Migration Roadmap

1. Inventory every signer and verifier. Record what signs code, what verifies code, which algorithms are used, where keys live and which supplier controls each dependency.
2. Classify artefact lifetime. Separate short-lived deployment artefacts from firmware, offline installers, embedded software and regulated evidence that may be verified for years.
3. Test ML-DSA first, then SLH-DSA where justified. ML-DSA is the practical first pilot for most workflows; SLH-DSA is useful where a conservative hash-based option is worth the size and speed trade-offs.
4. Plan dual-signature periods. Use classical signatures for current compatibility while adding post-quantum signatures where verifiers and policy engines can process them.
5. Update release policy and evidence. Document approved algorithms, key custody, verifier support, signing timestamps, revocation handling, rollback handling and supplier commitments.

Choosing ML-DSA or SLH-DSA for Code Signing

ML-DSA is the practical starting point for most code-signing pilots because it is the primary NIST post-quantum signature standard. Test it first where your release tooling, HSM or KMS, artefact store and verifier can all be updated together.

SLH-DSA is attractive where a hash-based assurance story matters more than signature size or throughput. Firmware signing, emergency recovery images and low-frequency high-assurance releases are examples to evaluate, not automatic defaults.

Do not assume the cryptographic algorithm is the only blocker. Package formats, timestamp services, certificate chains, manifest size limits, old update clients and offline verification paths often decide the actual migration sequence.

Questions for Suppliers

-Which NIST-standardised post-quantum signature algorithms are supported today?
-Can the toolchain produce and verify dual signatures or multiple detached signatures?
-How are signature size increases handled in package metadata, manifests and update protocols?
-Which HSM, KMS, timestamping and certificate services support ML-DSA or SLH-DSA?
-What is the migration date for managed updater clients and offline verifiers?

Primary References

FAQ

Why is code signing a post-quantum priority?

Code signing protects software distribution by proving origin and integrity. If long-lived verifiers cannot be updated before quantum attacks become practical, forged signatures become a supply-chain risk.

Should code signing use ML-DSA or SLH-DSA?

Most teams should test ML-DSA first because it is the primary NIST post-quantum digital signature standard. SLH-DSA is a conservative hash-based option for selected workflows where its larger signatures and performance profile are acceptable.

Can a website scanner prove code-signing readiness?

No. A public website scan helps with external TLS evidence. Code-signing readiness requires an internal inventory of signers, verifiers, release artefacts, keys, HSMs, package managers and updater clients.

What is the safest first code-signing pilot?

Start with an internal release workflow where the signing service, artefact store and verifier are all under your control. Measure compatibility before exposing post-quantum signatures to customer or device fleets.

Build the Code-Signing Inventory

Start by collecting external TLS evidence, then extend the inventory to release pipelines, signing keys, package formats, verifier fleets, suppliers and device lifetimes.