Post Quantum Code Signing: A Guide to Quantum Safe Signatures

Home » Post-Quantum Code Signing: What Developers Need to Know for the Quantum Era

Key Takeaways

Short is a universal fault of RSA, DSA, and ECDSA. Hashes and AES are not the emergency code-signing issue.
The code signing date is early because signatures have a lifespan beyond the one that created them.
To NIST’s 2030 window for deprecating/rejecting outdated APIs, firms that sell into government/critical infrastructure have a window for deprecating/rejecting outdated firmware and software.
The usual default option is ML-DSA-65. For root diversity and firmware diversity, use SLH-DSA or LMS/XMSS, respectively.
AWS KMS is already signed with NIST PQC as well as Private CA and Google Cloud KMS. Microsoft’s headings are toward CNG and AD CS, and a bit towards Azure Key Vault.
Begin with inventory, dual signing, and private PQC roots. Continue purchasing new code-signing certificates (with maturity periods for public PQC products).

There is a hard deadline for post-quantum code signing: You sign a certificate in 2026 that may still be needed to check the certificate on a device in 2035 that you can’t re-flash.

This post covers what PQC signatures are, why RSA/DSA/ECDSA doesn’t work against a CRQC, how code signing is different from SSL, and what AWS, Google, and MS shipped. Inventory paths. Select an algorithm class. Test dual-sign. Follow cert and KMS roadmaps.

What is a Post-Quantum Digital Signature?

Authenticity, integrity, and non-repudiation can still be achieved by using a digital signature. The private key is used for signing something. The public key is valid.

The term “post-quantum”, however, does not actually imply it is running on a quantum computer. The math is still difficult for classical machines and a future CRQC. It is still able to be executed today with modern CPUs.

In August 2024, NIST finalised ML-DSA (FIPS 204, Dilithium) as the general default, and SLH-DSA (FIPS 205, SPHINCS+) as a conservative hash-based fallback. Compact, and also a draft, FN-DSA (FIPS 206, Falcon).

Firmware is already provided for LMS and XMSS (SP 800-208) in case you don’t ever reuse state. Algorithms, keys, certs, and verifiers are all changed via the change. You do NOT turn a Flag around.

Encryption faces harvest-now-decrypt-later. Signatures face forge-later. Signatures, etc.: Code Signing is a Signature Problem.

What is the Difference between Signatures and Encryption?

Social

Harvest now, Decrypt later: An attacker stores ciphertext today and decrypts it later.

Signatures are forged later: An attacker might forge a signature after the CRQC. Code signing is a type of signature.

How’s Everybody’s Digital Signature Story?

The majority of production signing still rests on three families of classical algorithms.

RSA is based on the factoring of integers. Teams still pick 2048-, 3072-, or 4096-bit keys. The RSA-2048 signature is close to 256 bytes. It is still the most popular method for the majority of public CAs, Authenticode pipelines, and Java/JAR signers.

DSA is based on the finite-field discrete logarithm problem. It was phased out of use by newer designs. If the quantum computer can break RSA, then it can break DSA. Same threat class.

ECDSA and EdDSA are based on the elliptic curve discrete logarithm problem. The size of keys and signatures remains small—around 64 bytes for P-256. This size is what they control in modern TLS, mobile apps, and even many code-signing profiles.

There’s one thing they all share: The math problems are still too difficult. This is only true for classical computers.

These algorithms are already available in a few scenarios: Authenticode, JAR signing, APK signing, Cosign for containers, firmware Secure Boot, NuGet/npm/maven packages, CI flows calling KMS Sign via OIDC.

Which Timeline should Developers use to develop Quantum-Safe Signatures?

Schedule for written NIST and CNSA dates. Avoid waiting for a CRQC.

August 2024: FIPS 203, 204, and 205 are final. Both ML-DSA and SLH-DSA are “now” technologies.
November 2024: The planning baseline is IR 8547 (still a draft). The classical public-key crypto will be deprecated after 2030 and disallowed after 2035.
CNSA 2.0: Signing of firmware and software begins now; going for PQC by 2025; going all-in on NSS by 2030.
2025–2026: Lands are supported by Cloud KMS and CA.
2033–2035: A CRQC-risk planning window is a risk date, rather than a certainty.

This year’s binary you sign will last a lifetime beyond any classical default.

From 2030 onwards, the default key to use is a new RSA/ECDSA signing key. Classical signatures are not a NIST-approved long-term trust root for environments that are aligned with NIST. The hybrid is not the end goal; it’s the stepping stone.

Why Does Shor’s Break RSA, DSA, and ECDSA?

It was published in 1994 by Peter Shor. If a large quantum computer were available, we could solve the integer factoring problem and discrete log problem in polynomial time. Factoring is used to protect RSA’s private key. The discrete log-based cryptographic schemes – DSA, ECDSA, and EdDSA – conceal them behind Discrete Logs.

If you can recover the private key from a published public key, you can create signatures that are accepted by any active verifier. This is sufficient for the check to pass. The signatory no longer works for the vendor.

This is not the Main Story: Grover’s. It accelerates brute force, hence the larger margin of AES-256 and SHA-384 to keep their approvals. It is not Grover, but Shor, who signs up.

This is a planning problem – you don’t need to deal with a CRQC today! This means that even firmware from year 2026 can be in the field when a CRQC is available.

If a person can steal a TLS session key, they can read one conversation. When you mint a key, let the world know it’s an update to a trusted Windows or IoT; a trusted shipper can send code that every device trusts as yours.

Why Code Signing Needs PQC?

Long-lived parts of the root of trust are code and firmware signatures. Understandably, software and firmware signing has been the earliest clock, implemented by NSA’s CNSA 2.0, since software certs last for years, even in the absence of TLS sessions.

The verifier is often not able to be rotated. Secure Boot keys, industrial PLCs, and auto ECUs and medical devices continue to verify the same public key long after your CI has left.

A forged signature is a forged update. That’s not a leaked chat; that’s part of the supply chain. It is malware treated as yours by the OS, bootloader, or app store.

Your pipeline is faster than the public CA, Authenticode, app stores, or OS trust stores. Jump from private roots you control. Dual-sign first. Forget about public PKI.

The risk has the shape of an engineering constraint, rather than a white paper. Artefact size limits, timestamp counter signatures, catalogue files, detached signatures versus attached signatures, and the fact that your HSM’s Sign API could simply continue to ignore the new algorithm all play a role in whether or not the migration ships.

What is the Rationale for Dual-Signing the Default Transition?

Send a classical and a PQC (bearer) certificate for the same artefact, or use a composite or hybrid certificate when dealing with a stack. RSA and ECDSA are still being used by old verifiers. The post-quantum half is for new verifiers. It provides compatibility without any risk to the fleet on the algorithm family.

How Do RSA and ECDSA Compare to Post-Quantum Signatures?

Size changes. The duty of the verifier is not. Look at these as planning-grade figures and validate before a freeze.

Scheme	Hard problem	Typical sig size	Keys	Quantum status	Fit
RSA-2048	Factoring	~256 B	Large	Breaks under Shor	Legacy only
ECDSA P-256	ECDLP	~64 B	Small	Breaks under Shor	Legacy / hybrid half
ML-DSA-65	Module lattices	~3,309 B	~2 KB pub	NIST primary	General code signing
ML-DSA-87	Module lattices	~4,627 B	Larger	Higher assurance	Long-lived / CNSA-class
SLH-DSA-SHA2-128s	Hash / Merkle	~7.8 KB	Tiny pub	Conservative backup	Roots, firmware
LMS / XMSS	Stateful hash	Often smaller than SLH	State	Already in firmware	Only with HSM-enforced state

Signatures will be approximately 10×-50× larger than ECDSA. Assess Installer, Packet, and Firmware header sizes. To use stateless ML-DSA in CI. One of the states keeps burning the key for reuse in reused LMS/XMSS. Verification is cheap. I’m key management, and verifiers are not.

Which PQC Code-Signing Integrations are Hurriedly Making Their Way to Market?

The first two, Cloud KMS and private CA, are important. That’s where CI already uses Sign.

What Has AWS Shipped?

June 13, 2025: KMS GA for ML-DSA (`ML_DSA_44` / `65` / `87`, `ML_DSA_SHAKE_256`, same CreateKey / Sign / Verify). Firmware and long-lived signatures were flagged by AWS.

The private code-signing roots will be certified by Private CA plus KMS ML-DSA on 17th Nov. 2025. Hybrid PQ-TLS to KMS (ML-KEM) protects the channel (signature is protected by bypass)

What Has Google Cloud Shipped?

February 20, 2025: Cloud KMS preview of ML-DSA-65 and SLH-DSA-SHA2-128s.

July 28, 2026: External-μ variants for large payloads for both SLH-DSA and GA for ML-DSA-44/65/87. 2028-2029 seems to be the time frame of discussion for org-level talk; the roadmap has firmware keys, and CAS follows this trajectory.

What’s Microsoft’s Stance?

SymCrypt announced ML-KEM/ML-DSA at the end of 2024. The May 2025 is the May edition of the release features the release of insiders, CNG, and Linux SymCrypt-OpenSSL versions.

Late 2025: CNG/cert APIs on Server 2025 and Win11.

May 2026: AD CS issues ML-DSA certs (KB5087539). Azure Key Vault/Managed HSM PQC types are on the fly—pilot as SKUs.

Sept 2026: The Trusted Root pilots test PQC TLS, NOT production Web PKI.

What is Ready Around the KMS?

OpenSSL 3.5+. To see more, check out. NET 10 ships ML-DSA; Go is adding it. The use of Cosign, Sigstore, and public CAs is still lagging. Private pathways are available to prototype. Trails of public code-signing certs.

What should Developers do for Post-quantum Code Signing?

Inventory all signs/verify paths: Authenticode, App Stores, JAR/APK, Container, SBOM Attestation, Firmware/Secure Boot, IDE Plugins, Registries, Timestamp Servers.
Record: algorithm, key length, HSM/KMS, cert profile, lifetime.
Rank by lifetime. Firms and roots first: The last things that are archived weekly are the CI artefacts.
Make crypto-agile: Be sure to abstract Sign() under an interface. Avoid embedding the name of the hash function into scripts.
Run 4 Pilot runs of ML-DSA-65 (on AWS or GCP now; Azure, as SKU arrives). Use dimensions, latency, and verifier support.
Run 2 copies of a release train: Wait for verifiers to catch up with RSA/ECDSA.
Fix key custody first: PQC keys still need HSM/KMS, dual control, audit, and no LMS/XMSS state reuse.

Request CA product date, timestamping, OS library version (OpenSSL), CA signatures, and Authenticode/OS trust from vendors in writing. Javasoft/JDK (including NET, signtool, jarsigner, and cosign).
Set up a private PQC root for internal artifacts: Take no time to wait for the public to regain its trust.
Budget large catalogues, slower air-gapped verification, and old IoT parsers with fixed buffers.

What Not To Do?

Not minting a 10-year RSA code sign in 2026 and declaring the problem solved is not quite as satisfactory. Never use multiregion CI for stateful LMS or XMSS without using SSOS for them. Do not use PQ-TLS as a PQC code signature on the KMS endpoint.

What the Code Signing Future holds for Anyone

The default is changed from ECDSA and RSA to ML-DSA. Roots and firmware understand the importance of SLH-DSA or LMS/XMSS in the context of diversity and long life.

The team is sending composite/hybrid certificates. PQC-only follows verifiers/trust stores.

Signatures will be reduced in size later in FN-DSA. Wait for 2026–2028 work – don’t block it.

Public CAs or the public chain are the long pole, as are trust stores and/or app stores. But if you sign early, you will not have to re-sign any historical builds.

Conclusion

Post-quantum code signing is a migration programme and not a switch for a flag on a weekend. Both the algorithm, key, certificate, and verifier are modified simultaneously.

See NIST and CNSA release notes and dates, plus your CA date. Try to change the old classical certificates as quickly as possible with a short leash. Request your CA to provide you with a PQC/hybrid code-signing implementation plan. Prototype ML-DSA in CI this Quarter.

Secure the most recent code-signing certificates and a crypto-agile issuance roadmap to be able to include PQC if your CA and verifiers do so.

Buy Code Signing Certificate

Increase your Software Downloads and Verify its Integrity by Digitally Sign Software and Executables using Trusted Code Signing Certs.

Price Starts at $215.99 Per Year

Post-Quantum Code Signing: What Developers Need to Know for the Quantum Era