Post-Quantum Code Signing Certificate Guide (2026)

What is post-quantum code signing?

Post-quantum code signing means signing software, drivers and firmware with algorithms that a quantum computer cannot break, in place of RSA or ECDSA. The algorithms are standardized. A publicly trusted certificate that uses them is not something you can buy yet.

That gap shapes this whole guide. The math is settled. The trust system around it is not. So the useful work right now is preparation: knowing what you sign, where your keys live, and which of your verifiers will choke on a bigger signature.

Two dates give the topic weight. Microsoft has said Windows production signing moves to post-quantum by default in 2027 (Microsoft KB5125813). NSA guidance for national security systems expects all software and firmware signing to use its new algorithm suite exclusively by 2030 (atsec summary of CNSA 2.0).

Below, you will find what is at risk, which algorithms apply, what the deadlines really cover, what you can buy today, and a 90-day pilot you can run without touching production.

Why code signing is exposed to quantum risk

RSA and ECDSA rest on math problems that a large enough quantum computer can solve using Shor’s algorithm. Your code signing certificate publishes the public key. With a capable machine, someone could work backward to the private key and sign malware that chains to a trusted CA.

Nobody can put a date on that machine. So the better question is how long the thing you sign has to stay trusted. A web session lasts seconds. A firmware image or a driver can sit in the field for ten years or more.

You may have heard “harvest now, decrypt later.” That phrase is about stolen secrets. Signatures have their own version of the problem. The danger is a forged signature that a device still accepts years from now, and the devices that cannot be updated are the ones that pay for it.

Root keys make this worse. Root certificates commonly live for 20 to 30 years (arXiv survey of post-quantum PKI), and a root key burned into hardware cannot be swapped by a software update.

Not every artifact carries the same exposure. This is my own ranking, based on how easily you can rotate trust after the fact:

What you sign	Typical lifespan in the field	Can you rotate trust later?	Post-quantum priority
Bootloaders and device firmware	10+ years	Rarely	High
Kernel drivers	Life of the OS version	Sometimes	Medium to high
Desktop apps with auto-update	Months to a few years	Yes, ship a new build	Medium
Internal scripts and CI tooling	Short	Yes	Low

If you ship firmware or anything with a hard-coded root of trust, start there. If you ship a desktop app that updates itself, you have more room.

The algorithms: ML-DSA, SLH-DSA, LMS and XMSS

Four signature schemes matter for code signing. NIST finalized ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) in August 2024 (Cloud Security Alliance). LMS and XMSS come from an earlier NIST document, SP 800-208.

Algorithm	Standard	How it works	Signature size	Where it fits
ML-DSA	FIPS 204	Lattice-based, stateless	2,420 bytes (ML-DSA-44), 3,309 (ML-DSA-65), 4,627 (ML-DSA-87)	General software signing and CI/CD pipelines
SLH-DSA	FIPS 205	Hash-based, stateless	7,856 bytes (128s set) up to 17,088 (128f set)	Conservative fallback when you want minimal assumptions
LMS	SP 800-208	Hash-based, stateful	Compact keys, fast verification	Firmware and boot images
XMSS	SP 800-208	Hash-based, stateful	Compact keys, fast verification	Firmware and boot images

For comparison, an Ed25519 signature is 64 bytes. Sizes for the NIST parameter sets come from Utimaco’s summary of the final standards.

LMS and XMSS are the schemes NSA named for software and firmware signing. Their trade-offs are fast verification and slower key generation (Cryptomathic).

Stateless or stateful?

Stateless schemes (ML-DSA, SLH-DSA) behave like the signing you do today. You hold a key and sign as often as you like.

Stateful schemes (LMS, XMSS) do not. Each signature uses up a one-time key inside a tree, and the signer must never reuse one. A restored backup or a cloned virtual machine can repeat a state and quietly break the scheme’s security.

A simple rule works for most teams. Use ML-DSA for build pipelines and general software. Look at LMS or XMSS only for firmware and boot images, or when a compliance program names them, and keep those keys inside hardware that tracks state for you.

One clarification on ML-KEM

ML-KEM (FIPS 203) shows up in many post-quantum articles. It handles key exchange, not signatures. It has no job in code signing, so skip it when you scope a signing project.

Deadlines that matter, and what they actually cover

Several dates get quoted together, and they apply to different people. Read each one for who it binds.

Date	What happens	Who it affects
March 1, 2026	Publicly trusted code signing certificates capped at 460 days	Every publisher who renews or reissues
October 19, 2026	Microsoft Windows Production PCA 2011 expires	Software that pins or checks Microsoft’s certificate chain
Later in 2026	Windows production signing moves to RSA-3072 and SHA-384	Apps that hard-code expected signing settings
2027	Windows production signing moves to post-quantum by default	Mostly legacy systems and hard-coded validators
2030	NSA expects exclusive use of its quantum-resistant suite for software and firmware signing	National security systems and their vendors

Microsoft’s dates come from its own guidance, KB5125813, published August 20, 2026. The 460-day cap is covered in our Windows code signing changes article.

Read the Microsoft plan carefully

The 2027 change covers Windows production signing. That is how Microsoft signs Windows components itself. The guidance I reviewed does not tell third-party publishers to re-sign their software with a new algorithm.

The risk for you is indirect. Microsoft warns that applications which hard-code expected signing settings can fail even when Windows considers the file valid and trusted. It also says future signing might use new algorithms and hybrid constructions, and might change quickly.

Microsoft has not named the algorithm. If you have a tool that checks signers, pins a Microsoft certificate, or keeps its own trust store, test it now.

What is not required yet

I could not find a CA/Browser Forum rule that requires post-quantum algorithms in publicly trusted code signing certificates. The Forum has also not approved ML-DSA for publicly trusted TLS certificates as of October 2026 (Quantum Zeitgeist, citing Forum minutes). Your current RSA-based certificate stays valid for its term.

The 2030 NSA date is a federal requirement for national security systems. It becomes yours if you sell into that market, or if a customer’s contract flows it down to you.

Hybrid signing in a build pipeline

Hybrid signing means an artifact carries two signatures: one classical, one post-quantum. Old verifiers check the classical one and ignore the rest. Updated verifiers can check both. Nothing breaks on day one.

There are two ways to build it. Composite signatures pack both algorithms into a single signature. Dual signatures keep them separate and independent. Composite formats are still maturing, so most pipelines today use the dual approach.

Here is a pattern that works without waiting on the operating system:

1. Sign the binary with your normal code signing certificate, exactly as you do now.
2. Generate a post-quantum signature over the same release hash, using ML-DSA, and store it as a detached signature file or inside your update manifest.
3. Publish both together.
4. Teach your own updater, installer or verification script to check the post-quantum signature as well.

Be clear about what this gives you. The post-quantum signature is verified by your code, not by Windows. It does not change how SmartScreen or Authenticode treat the file.

That is still useful. It lets you test signature size, signing time and key handling long before any platform requires them, and it protects update channels you control.

Can you buy a post-quantum code signing certificate today?

Not a publicly trusted one. Public trust depends on root programs and the CA/Browser Forum accepting new algorithms, and that has not happened for ML-DSA. DigiCert states that its public certificate platform does not currently issue public certificates with post-quantum algorithms, while its private CA does support ML-DSA (DigiCert documentation).

The standard for encoding ML-DSA inside X.509 certificates is already published as RFC 9881. So the format exists. The public trust layer is what is missing.

What to buy now

Keep buying standard code signing certificates and protect the keys properly. Choose a strong key size, store the key in a hardware module or a managed cloud HSM, and keep your signing records tidy.

Because publicly trusted code signing certificates now top out at 460 days, whatever you buy today gets replaced within about 15 months. Waiting for a post-quantum option costs you nothing, since you cannot buy one yet.

What to build in a private PKI

Where you control both signing and verification, you can use post-quantum certificates today. Internal tools, device fleets and firmware you verify yourself are the obvious candidates.

Several options already issue ML-DSA certificates for private use: Active Directory Certificate Services on Windows Server 2025 after the May 2026 update, cloud private CA services, and open-source PKI software. Cloud key services such as AWS KMS can also hold ML-DSA keys (AWS Security Blog).

Questions to ask your CA

• Do you plan to issue post-quantum code signing certificates, and what is the earliest realistic date?
• Which algorithm will you support first, and will it be hybrid or ML-DSA only?
• Does your timestamping service have a post-quantum plan?
• Will existing customers get a reissue path inside their current term?

A CA that gives a vague answer to the first question is telling you something.

HSM and key management readiness

The algorithm is the easy part. Keys, hardware and process are where projects slow down. Run through this checklist before you pick a pilot.

• Algorithm support. Does your HSM or cloud key service support ML-DSA, and LMS or XMSS if you need them? Not every module does yet, and some need a firmware update.
• Interface support. Do your signing tools reach the HSM through an interface that can carry the new algorithms? Check your signing client, not only the hardware.
• State handling for LMS and XMSS. Who tracks which one-time key was used last? The module should do it. Never restore a signing key from a backup without a plan for state.
• Signature budget. A stateful key can only sign a fixed number of times, set when the key is generated. Size it for your release volume with room to spare.
• Larger signatures. Check installer headers, update manifests, boot storage and any size-limited field. An ML-DSA-65 signature is 3,309 bytes against 64 for Ed25519.
• Verification on small devices. Time signature checks on your slowest hardware, not your build server.
• Timestamping. A signature is only as durable as its timestamp. Ask your timestamp provider about a post-quantum plan.
• Access control and logging. Keep multi-person approval and audit logs on the new keys, exactly as you do on production keys.
• Crypto agility. Can you change the algorithm through configuration, or is it baked into code in twelve places?

The last item matters most. Microsoft itself says future signing may need rapid changes. A pipeline that takes a quarter to modify is a risk by itself, whichever algorithm you choose.

A 90-day pilot plan

You do not need a budget approval to start. You need one non-production pipeline and a few weeks. Here is a sequence that keeps the scope small.

Days 1 to 14: take inventory.

1. List everything you sign: executables, installers, drivers, scripts, containers, firmware, update manifests.
2. Note where each signing key lives and who can use it.
3. List every tool that verifies those signatures, including ones you did not write.

Days 15 to 45: build the pilot.

1. Pick one pipeline with low business risk.
2. Stand up a private post-quantum CA or a signing service that supports ML-DSA.
3. Add a second, detached ML-DSA signature after your normal signing step.
4. Leave the classical signature untouched.

Days 46 to 75: break it on purpose.

1. Verify the new signature in every consumer you listed.
2. Record signing time, verification time and file size changes.
3. Test what happens when a verifier meets a signature it does not understand.
4. Check any tool that pins Microsoft certificates or hard-codes signing settings, as Microsoft’s guidance advises.

Days 76 to 90: decide and write it down.

1. Report what failed, what slowed down and what needs vendor changes.
2. Decide which artifact types move first. Firmware and long-lived drivers usually lead.
3. Set a review date tied to the next Microsoft and CA/Browser Forum announcements.

A written pilot report is worth more than a finished migration plan. It tells you where your real obstacles are.

Frequently asked questions

What is a post-quantum code signing certificate?

It is a code signing certificate whose key pair and signature use a quantum-resistant algorithm such as ML-DSA, instead of RSA or ECC. Standards for the algorithm and the certificate format exist. Public CAs do not yet issue them for general use.

Is my current code signing certificate going to stop working?

No. It stays valid for its term, and nothing I found requires publicly trusted certificates to change algorithms. Renewal now happens at least every 460 days, so you will have regular chances to adjust.

Should I use ML-DSA or LMS?

Use ML-DSA for general software signing and build pipelines. Consider LMS or XMSS for firmware and boot images, or where a government program names them. Stateful keys need hardware that tracks state.

Does ML-KEM sign code?

No. ML-KEM handles key exchange. Code signing uses signature algorithms: ML-DSA, SLH-DSA, LMS and XMSS.

Will Microsoft’s 2027 change force me to re-sign my software?

The guidance I reviewed covers Windows production signing and does not tell third-party publishers to re-sign. Check KB5125813 for updates. Test any tool that validates signers with hard-coded settings.

When will quantum computers break RSA?

Nobody knows. Planning around a guessed date is a mistake. Plan around how long your signed code has to stay trusted and how fast you can change algorithms.

Should I buy a certificate now or wait?

Buy what you need now. You cannot purchase a publicly trusted post-quantum code signing certificate today, and the 460-day cap means no purchase locks you in for long.

Where to start this week

Open a spreadsheet and list everything your team signs, where each key lives, and which tools check the result. That one list tells you which of your artifacts are exposed and which verifiers might break.

Then pick a single non-production pipeline and add a second, post-quantum signature to it. Keep the rest as it is. Waiting for a public post-quantum certificate is fine. Waiting to learn how your own pipeline reacts is not.

If you need a code signing certificate for production today, or help matching a certificate and key storage option to your build setup, CodeSignCert can walk you through it.