Post-quantum code signing, also called quantum-safe code signing, is code signing for software, firmware, scripts, and container images with digital signature algorithms that a cryptographically relevant quantum computer (CRQC) cannot forge. The standardized options are the Module-Lattice-Based Digital Signature Algorithm (ML-DSA) in Federal Information Processing Standard (FIPS) 204, the Stateless Hash-Based Digital Signature Algorithm (SLH-DSA) in FIPS 205, and two stateful hash-based schemes, Leighton-Micali Signature (LMS) and the eXtended Merkle Signature Scheme (XMSS). Adopting it changes four things in a signing pipeline: the key algorithm in the hardware security module (HSM), the certificate chain, signature size, and which verifiers can check the result.
Put firmware first in your post-quantum cryptography (PQC) readiness program. The National Security Agency (NSA) notes in its FAQ on the Commercial National Security Algorithm Suite (CNSA) 2.0 that firmware often keeps its signature verification algorithm for a device’s whole service life. A quantum-resistant root of trust therefore has to ship years before the rest of the system upgrades. Teams that start now make one algorithm change at the signing service, re-sign long-lived artifacts once, and clear the January 2027 CNSA 2.0 acquisition rule for sales to national security systems.
Key takeaways
- Post-quantum code signing starts with an inventory of signing keys and the verifiers that trust them, followed by an ML-DSA pilot on internal software and LMS or ML-DSA-87 for new firmware. Public releases keep RSA or Elliptic Curve Digital Signature Algorithm (ECDSA) signatures until certificate authorities (CAs) can issue post-quantum code signing certificates.
- Plan flash and package budgets for signature blocks about 7x larger than RSA-3072 once a full certificate chain moves to ML-DSA-65.
- Publicly trusted post-quantum code signing is not available yet: CA/Browser Forum requirements still allow only RSA, ECDSA, and DSA keys.
- Set your deadline by customer: 2030 for software and firmware used in national security systems, December 31, 2031 for signatures on federal high-value assets (HVAs) and high-impact systems, and 2035 for everyone else.
Post-quantum code signing swaps the keys in your workflow
A post-quantum signing pipeline runs the same steps as a classical one. A build job hashes the artifact, an HSM signs a structure containing that hash, and a verifier checks the signature against a trusted chain. Because a Request for Comments (RFC) 3161 timestamp is also a signature, the timestamp authority’s key needs a post-quantum algorithm too.
Signature risk begins the day a CRQC exists. Its operator could run Shor’s algorithm to derive a private key from a published RSA or ECDSA public key and sign malware with it. Every verifier that still trusts the matching public key would accept the forged signature. Exposure lasts as long as verifiers keep trusting classical keys. A May 2025 estimate put RSA-2048 factoring at under a week on fewer than one million noisy qubits.
Teams add a post-quantum signature with one of these patterns while older verifiers stay in service:
- Parallel signatures attach a classical signature and a post-quantum signature to the same artifact, and each verifier checks the signature it supports.
- Composite signatures combine ML-DSA with RSA or ECDSA in one object that is valid only when both parts are verified. The Internet Engineering Task Force (IETF) specification is still a draft at revision 19, dated April 2026.
- Post-quantum-only signatures carry a single post-quantum signature and fit firmware and internal software where you control every verifier.
ML-DSA, SLH-DSA, LMS, or XMSS: Which fits which job
ML-DSA is the general-purpose option. It keeps no state, its keys and signatures are moderate in size, and NSA approves ML-DSA-87 for any signing use, including software and firmware. LMS and XMSS are stateful. Each key holds a fixed number of one-time signatures, and reusing one breaks security. SLH-DSA needs no state tracking and produces larger signatures than ML-DSA. For national security systems, CNSA 2.0 approves ML-DSA-87, LMS, and XMSS.
Table 1. Post-quantum signature options for code signing
| Algorithm (standard) | Public key | Signature | State | Best code signing fit |
| ML-DSA-65 (FIPS 204) | 1,952 B | 3,309 B | None | High-volume app, package, and container signing |
| ML-DSA-87 (FIPS 204) | 2,592 B | 4,627 B | None | National security systems, long-lived software |
| SLH-DSA-SHA2-128s (FIPS 205) | 32 B | 7,856 B | None | Root keys, rarely signed artifacts |
| LMS, SHA-256/192, tree height 20 | 48 B | 1,740 B (calculated) | 1,048,576 signatures per key | Firmware and boot images |
| RSA-3072 (baseline) | 384 B | 384 B | None | Public releases today, quantum-vulnerable |
LMS sizes use the National Institute of Standards and Technology (NIST) SP 800-208 parameter set LMOTS_SHA256_N24_W4: 4 + (4 + 24 + 51 × 24) + 4 + (20 × 24) = 1,740 bytes. RSA key size counts the modulus.
A fully post-quantum chain runs about 7x larger than RSA
Every copy of an artifact carries its signature block, usually with a certificate chain and timestamp token. Take a hypothetical Authenticode-style Public-Key Cryptography Standards (PKCS) #7 block: a signature over the artifact, a signer certificate, an issuing CA certificate, and an RFC 3161 timestamp with its own certificate. Its five signatures and three public keys take their sizes from FIPS 204 and FIPS 205. Names and extensions add similar overhead to every option.
Table 2. Keys and signatures in one signed artifact (hypothetical)
| Algorithm across the chain | Bytes of keys and signatures | Versus RSA-3072 |
| ECDSA P-256 | 512 | 0.17x |
| RSA-3072 | 3,072 | 1x |
| ML-DSA-44 | 16,036 | 5.2x |
| ML-DSA-65 | 22,401 | 7.3x |
| ML-DSA-87 | 30,911 | 10.1x |
| SLH-DSA-SHA2-128s | 39,376 | 12.8x |
| RSA-3072 and ML-DSA-65 in parallel | 25,473 | 8.3x |
On a 100 MB installer, the ML-DSA-65 block adds 0.02%. In a fixed 512 KiB flash slot, the same block takes 4.3% of the space. Reserve that space in the partition layout before devices ship. Formats that verify a raw signature against a key hash in read-only memory (ROM) carry no certificate chain, and an LMS signature in those formats keeps its Table 1 size. To size your own chain, issue post-quantum test certificates from the free AppViewX PQC Test Center and measure them.
Your code signing deadline depends on who you sell to
Teams that sell to the government face the earliest dates. Teams without government customers can plan against the 2035 row.
Table 3. Dated milestones for code signing teams
| Date | Milestone | What it means for code signing |
| June 1, 2023 | Public code signing keys must live in hardware crypto modules (CA/Browser Forum Code Signing Baseline Requirements v3.11.0) | Confirm your HSM model and firmware can hold post-quantum keys |
| 2025 | Software and firmware signing supports and prefers CNSA 2.0 (NSA CNSA 2.0 advisory) | Stand up a CNSA 2.0 signing path for national security releases |
| March 1, 2026 | Code signing certificates capped at 460 days (Ballot CSC-31) | Automate renewals now |
| January 1, 2027 | New national security system acquisitions must meet CNSA 2.0 (NSA FAQ) | Show CNSA 2.0 signing support in each new national security bid |
| 2030 | Exclusive CNSA 2.0 software and firmware signing, EU high-risk systems migrated (EU roadmap), and Executive Order (EO) 14412 directs the Federal Acquisition Regulation (FAR) Council to propose a rule requiring covered contractors to meet PQC FIPS by December 31, 2030 (Federal Register text) | Run post-quantum signing in production for government releases |
| December 31, 2031 | Federal HVAs and high impact systems use PQC digital signatures (EO 14412 deadlines explained). CNSA 2.0 mandated for national security systems (NSA FAQ) | Expect federal agency customers to ask for your signature migration plan |
| 2035 | The NIST draft disallows RSA and ECDSA (NIST IR 8547). UK migration complete (National Cyber Security Centre (NCSC)) | Finish moving every signing key off RSA and ECDSA |
Internal software can carry post-quantum signatures today
Who issues the certificate decides what you can sign with a post-quantum key today.
Sign internal builds with ML-DSA
Use OpenSSL 3.5, a long-term support release from April 2025, to sign and verify with ML-DSA and SLH-DSA. On Windows 11 and Windows Server 2025, use the ML-DSA support that the November 2025 update added to the Cryptography API: Next Generation (CNG). Microsoft supports ML-DSA only through CNG providers. Issue the certificates from an internal CA prepared for post-quantum algorithms, and follow RFC 9881 for ML-DSA keys in X.509 certificates.”
Keep public releases on RSA or ECDSA
Version 3.11.0 of the CA/Browser Forum code signing requirements, dated June 16, 2026, allows RSA (3,072 bits minimum), ECDSA, and DSA keys. Until a ballot adds ML-DSA, public software keeps a classical signature, with any post-quantum signature riding alongside for verifiers you control.
Sign public releases with RSA or ECDSA until a CA/Browser Forum ballot adds a post-quantum algorithm. Version 3.11.0 of the forum’s code signing requirements, dated June 16, 2026, allows RSA keys of at least 3,072 bits, ECDSA keys, and Digital Signature Algorithm (DSA) keys.
How to prepare a code signing pipeline
Code signing keys are machine identities. Preparing them for post-quantum algorithms starts the way any machine identity program starts, with a complete inventory.
Inventory keys, verifiers, and artifact lifetimes
List each code signing key with its algorithm, what it signs, the verifiers that trust it, and how long those artifacts live. Rank the list by how hard each verifier is to update. Firmware roots of trust, long-lived installers, drivers, and hard-to-reach devices go first, and short-lived artifacts checked only by continuously patched systems, such as intermediate continuous integration (CI) outputs, go last. AVX Code Signing, available today as a hosted service or on-premises, logs the certificate, key, signing time, and timestamp for every signed file. Those records give you the dependency list for any RSA key.
Route signing through one service
When pipelines call a central signing service through PKCS #11, CNG, or native tools, you change the algorithm once, at the service and its HSM. AVX Code Signing provides PKCS #11 and Cryptographic Service Provider (CSP) interfaces for SignTool, jarsigner, and APK Signer, with integrations for GitHub, GitLab, Jenkins, Bitbucket, and Azure DevOps. Without a central service, build one on an HSM’s PKCS #11 interface.
Confirm HSM support, including LMS state
Ask each HSM vendor for the exact algorithms and parameter sets its production firmware supports today, and for the firmware version that added each one. NSA recommends keeping LMS and XMSS signing and state tracking inside the HSM. For either scheme, confirm that the HSM tracks state internally, and that backup and failover cannot reuse a one-time key.
Pilot a parallel signature on internal software
Issue ML-DSA code signing certificates from a test CA, add a second signature to one internal artifact type, and log whether each verifier ignores, warns on, or rejects it, plus any size limits in update servers and registries. AVX PKI, generally available today, issues post-quantum-only certificates with ML-DSA and SLH-DSA keys for internal use. Its Summer 2026 release added hybrid composite certificates that pair ML-DSA with an RSA or elliptic curve key across root, intermediate, and end-entity tiers.
Write the target algorithm into policy
Assign an algorithm per artifact class: LMS or ML-DSA-87 for each new firmware line, ML-DSA-65 alongside RSA for internal packages, and RSA-3072 for public releases. The AVX Code Signing policy engine already enforces key size and algorithm rules. Use it to block new RSA-2048 keys now.
Signing tools need crypto-agility before ML-DSA support
Ask vendors to demonstrate each capability with a test, and treat any capability they cannot demonstrate as missing.
Table 4. Signing tool requirements by priority
| Capability | Priority | Test to run on the vendor |
| HSM-backed keys in validated modules | Must-have | Ask for the FIPS 140 certificate number of the HSM holding your keys |
| One signing service via PKCS #11, CNG, or native tools | Must-have | Sign from two pipelines and confirm both requests reach one service and key |
| Inventory linking keys to signed artifacts | Must-have | Pick one key and ask for every artifact it signed in the last 90 days |
| Per-project policy on algorithm and key size | Must-have | Create a rule that blocks RSA-2048, then try to sign with an RSA-2048 key |
| Windows signing through CNG | Must-have | On Windows, have the vendor sign a test file with an ML-DSA key through CNG |
| ML-DSA signing in production HSM firmware | Nice-to-have | Ask which firmware version adds ML-DSA and when it ships. National security suppliers need it by 2030 |
| Private CA issuance of ML-DSA code signing certificates | Nice-to-have | Request one ML-DSA code signing certificate and confirm your signing tool loads it |
| Composite signatures in production | Premature | Moves up when the IETF draft becomes an RFC, and your verifiers accept composites |
| LMS or XMSS for high-volume app signing | Overkill | Compare yearly signing volume with the per-key limit in Table 1 |
AVX Code Signing replaces the manual inventory with its signing logs. The AppViewX PQC Test Center removes the CA setup step for your pilot, and AVX PKI issues the internal post-quantum certificates once the pilot moves to production.
Frequently asked questions
Is code signing vulnerable to quantum computers?
Yes, a CRQC could forge today’s RSA and ECDSA code signatures, and no such computer exists yet.
Can public CAs issue post-quantum code signing certificates?
Public CAs will issue them after the CA/Browser Forum’s code signing requirements allow a post-quantum algorithm. In the meantime, sign public releases with RSA or ECDSA and watch the forum’s code signing ballots.
Does ML-KEM play a role in code signing?
No. The Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) in FIPS 203 sets up shared keys for protocols such as TLS. Code signing uses the signature algorithms in Table 1. ML-KEM appears in a signing pipeline only where it protects connections, such as traffic between build agents and a remote signing service.
Do already-signed binaries need to be re-signed?
Re-sign or re-timestamp any artifact that stays in use past your migration date once its verifiers accept post-quantum algorithms.
Disclaimer: Sources and product capabilities cited here were checked on October 15, 2026. Confirm current requirements with your CA, HSM vendor, and platform documentation before changing production signing.
Sources
- NIST, FIPS 204 data, August 13, 2024: https://csrc.nist.gov/pubs/fips/204/final
- NIST, FIPS 205 data, August 13, 2024: https://csrc.nist.gov/pubs/fips/205/final
- NSA, CNSA 2.0 and Quantum Computing FAQ, version 2.1, December 2024: https://media.defense.gov/2022/Sep/07/2003071836/-1/-1/0/CSI_CNSA_2.0_FAQ_.PDF
- NSA, CNSA 2.0 announcement, updated May 30, 2025: https://media.defense.gov/2025/May/30/2003728741/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS.PDF
- NIST, IR 8547 draft, November 12, 2024: https://csrc.nist.gov/pubs/ir/8547/ipd
- Federal Register, Executive Order 14412, signed June 22, published June 25, 2026: https://www.federalregister.gov/documents/2026/06/25/2026-12909/securing-the-nation-against-advanced-cryptographic-attacks
- CA/Browser Forum, Code Signing Baseline Requirements v3.11.0, June 16, 2026: https://cabforum.org/working-groups/code-signing/requirements/
- CA/Browser Forum, Ballot CSC-31: Maximum Validity Reduction, adopted November 17, 2025: https://cabforum.org/2025/11/17/ballot-csc-31-maximum-validity-reduction/
- Microsoft, PQC API availability announcement, November 2025: https://techcommunity.microsoft.com/blog/microsoft-security-blog/post-quantum-cryptography-apis-now-generally-available-on-microsoft-platforms/4469093
- Microsoft Learn, Configure certificate templates for ML-DSA, 2026: https://learn.microsoft.com/en-us/windows-server/identity/ad-cs/configure-ml-dsa-certificate-templates
- OpenSSL Library, OpenSSL 3.5 release notes, April 8, 2025: https://openssl-library.org/post/2025-04-08-openssl-35-final-release
- IETF, RFC 9881 data, October 2025: https://datatracker.ietf.org/doc/rfc9881/
- IETF, Composite ML-DSA use data, revision 19, April 21, 2026: https://datatracker.ietf.org/doc/draft-ietf-lamps-pq-composite-sigs/
- IETF, RFC 9708 data, January 2025: https://www.rfc-editor.org/rfc/rfc9708
- Craig Gidney, 2048-bit RSA integer factorization, May 2025: https://arxiv.org/abs/2505.15917
- European Commission, Coordinated Implementation Roadmap for the Transition to PQC, June 23, 2025: https://digital-strategy.ec.europa.eu/en/library/coordinated-implementation-roadmap-transition-post-quantum-cryptography
- UK NCSC, Migrations to post-quantum cryptography timelines, March 20, 2025: https://www.ncsc.gov.uk/guidance/pqc-migration-timelines
Tags
About the Author
