Windows Code Signing Changes 2026-2027: What to Do Now

The short answer

Microsoft is changing how it signs Windows itself, in three steps. The Windows Production PCA 2011 certificate expires on October 19, 2026. Stronger algorithms, RSA-3072 and SHA-384, follow before the end of the year. Post-quantum signing becomes the default in 2027.

These changes apply to Microsoft’s own signing chain. Your publicly trusted code signing certificate is not being revoked or replaced by any of them. What can break is software that assumes Microsoft’s signatures will always look the same.

Three groups should read on: developers who ship installers or drivers, IT teams who allowlist software by signature, and anyone who runs a private trust store.

Here is the full timeline, including two changes that are already live.

Date	What changes	Who feels it
March 1, 2026	Publicly trusted code signing certificates are capped at 460 days	Every publisher who renews or reissues
April 2026 servicing release	Kernel drivers move toward WHCP validation as the default trust path	Driver publishers
May 2026	ML-DSA support arrives in AD CS on Windows Server 2025	Teams building private PKI
October 19, 2026	Windows Production PCA 2011 expires	Software that pins or checks Microsoft’s certificate chain
Later in 2026	Windows Production signing moves to stronger settings, including RSA-3072 and SHA-384	Apps that hard-code expected signing settings
2027	Windows Production signing moves to post-quantum by default	Everyone, legacy systems most

Microsoft has not published a per-build schedule for the late-2026 step. Treat the end of the year as your planning window, not a single Patch Tuesday.

What happens when Windows Production PCA 2011 expires

The Microsoft Windows Production PCA 2011 certificate sits in the chain behind many Microsoft signatures on Windows components, drivers and updates. It reaches its end date on October 19, 2026. Microsoft has already started replacing it with Microsoft Windows Production PCA 2026.

The new chain is already in the field. Release Preview builds 26100.9539 and 26200.9539 are signed with it.

An expiring certificate does not turn every old signed file into a problem. Files signed before expiry stay valid when they carry a trusted timestamp. What breaks is code that treats one specific certificate as the only acceptable answer.

These are the places we would look first:

• Software that compares Microsoft signatures against a fixed thumbprint or issuer name
• Allowlist rules in endpoint security or application control tools that match the old PCA
• Private trust stores that copy Microsoft certificates by hand and have no update process
• Installers that verify bundled Microsoft components with their own custom logic

If your software calls the standard Windows trust APIs and pins nothing, you will probably never notice the change. The trouble comes from custom checks written years ago by someone who has since left the team.

The simplest test is to run your installer, updater and any verification script on a Release Preview machine. If something refuses a Microsoft-signed file, you have found a pinned assumption. Fix it now, while it is a ticket and not an outage.

RSA-3072 and SHA-384: the change after the expiry

Microsoft says Windows is moving toward stronger signing configurations, including RSA-3072 and SHA-384, by the end of 2026. That means longer keys and a longer hash on Microsoft’s side of the chain.

The risk is a quiet one. Some software validates a signature by checking its algorithm against a short hard-coded list. If SHA-384 is not on that list, a perfectly valid Microsoft signature gets rejected.

Older build tools, custom updaters and homegrown verification scripts are the usual culprits. Anything that parses signature data itself, instead of asking Windows, is exposed.

Microsoft’s own advice to developers is direct: stop pinning certificates, ask Windows whether it trusts the signature through the supported trust APIs such as WinVerifyTrust, and stay algorithm-agnostic. The last point matters most, because the 2027 change will test it again.

This step concerns Microsoft’s signing chain, not your certificate. Still, it is a fair moment to confirm your own signing setup uses a modern key size and hash, and to ask your certificate provider what its plans are for 2027.

Post-quantum signing in plain terms

A large enough quantum computer could break RSA and ECDSA, the algorithms behind almost every code signature in use today. Nobody has such a machine yet. The worry is timing: software signed now may need to stay trusted for ten years, and firmware for longer.

Post-quantum signatures swap the underlying math for problems that quantum computers do not solve faster. NIST published ML-DSA as FIPS 204 in August 2024. It grew out of the CRYSTALS-Dilithium research. Hash-based schemes, LMS and XMSS (NIST SP 800-208), are used mostly for firmware.

Microsoft plans to make post-quantum signing the default for Windows production signing in 2027, with attention to older platforms. That is Microsoft’s own signing. Your certificate is a separate matter.

There is already something to try. Since the May 2026 update (KB5087539), Windows Server 2025 lets AD CS build a private ML-DSA certification authority that can issue code signing certificates. Existing CAs cannot be converted. You have to stand up a new, parallel hierarchy.

The practical difference you will feel is size. ML-DSA signatures are far bigger than the ones you use today.

Algorithm	Raw signature size
ECDSA P-256	64 bytes
RSA-3072	384 bytes
ML-DSA-44	2,420 bytes
ML-DSA-65	3,293 bytes
ML-DSA-87	4,595 bytes

That is roughly six to twelve times the size of an RSA-3072 signature. Installers, update manifests and any system with a fixed-size signature field need testing before the switch, not after it.

Hybrid signing: two signatures during the switch

Hybrid signing puts a classical signature (RSA or ECDSA) and a post-quantum signature (ML-DSA) on the same piece of software. Older systems read the classical one. Newer systems check the post-quantum one as well. If either algorithm is ever broken, the other still stands.

You will see two forms. Dual signing carries two separate signatures. Composite signing joins both into a single signature. Windows cryptography APIs are adding support for composite ML-DSA and composite ML-KEM, and Microsoft has said more post-quantum features are planned later this year.

Microsoft also warns that future Windows signing may use hybrid constructions and may need rapid changes. Read that as a hint: build your pipeline so swapping an algorithm is a configuration change, not a rewrite.

The cost is real. Signatures get larger, there are two verification paths to test, and older tools may not understand the second signature. That is why a pilot on a non-production pipeline makes sense before anything ships to customers.

HSM readiness: the part most teams forget

Since June 1, 2023, the private key of a publicly trusted code signing certificate has to live in an HSM or an equivalent device (FIPS 140-2 Level 2 or Common Criteria EAL 4+). Post-quantum adds one more question on top: can that device create and use ML-DSA keys?

As of 2026, not every HSM can. Vendors are adding support on their own timelines, and the tokens shipped with today’s OV and EV certificates were built for RSA and ECDSA.

Before 2027, get written answers from your HSM, token or cloud signing provider on these points:

• Which ML-DSA parameter sets are supported (44, 65, 87)
• Whether a firmware update is enough, or the hardware has to change
• Whether hybrid or composite signing is supported
• What migration costs, and who handles the key ceremony

Do this early. Hardware lead times are the slowest part of any signing change, and they are the part your build team cannot speed up.

Where the 460-day limit fits

This change is already live. Publicly trusted code signing certificates issued on or after March 1, 2026 cannot be valid for more than 460 days, down from 39 months. OV and EV are both covered, and some CAs issue at 459 days to leave room for clock skew.

In practice you will renew more than twice as often. Renewal is also the natural point to generate a fresh key pair, which is the recommended habit anyway.

In our view, this helps with the post-quantum move. A team that already replaces certificates every 15 months has a working routine for changing keys and settings. A team that renewed every three years had to rebuild that routine from memory each time.

One rule matters more than any other here: timestamp every signature with an RFC 3161 time stamp authority. A timestamped signature stays valid after the certificate expires, because it proves the code was signed while the certificate was good. Without one, the signature stops validating on the expiry date.

A note for driver publishers

This one is separate from the dates above. Starting with the April 2026 servicing release, Windows 11 and Windows Server 2025 began moving kernel-mode drivers away from cross-signing and toward Windows Hardware Compatibility Program (WHCP) validation as the default trust path.

On protected systems, only drivers signed through WHCP, or listed on the policy allow list, will load. Blocked drivers show up in the Code Integrity event log.

If you ship a driver signed the older way, test it on a current Windows 11 build. Then open Event Viewer and check Applications and Services Logs, Microsoft, Windows, CodeIntegrity, Operational. That log tells you what was blocked and why, which saves a lot of guessing.

Publisher checklist: ten checks before October 19

1. List every code signing certificate you own, with the product, the pipeline, the expiry date and where the key is stored.
2. Confirm every signing step adds an RFC 3161 timestamp.
3. Search your code and scripts for pinned thumbprints, issuer names or fixed hash lists tied to Microsoft chains.
4. Run installers, updaters and verification scripts on a Windows Release Preview build signed with the new PCA.
5. Review allowlist and application control rules that mention PCA 2011.
6. Update private trust stores and name one person who owns those updates.
7. Ask your HSM, token or cloud signing vendor about ML-DSA and hybrid support, in writing.
8. Check the signature size limits in installers, manifests and update servers.
9. Set renewal reminders well ahead of the 460-day mark, not the week before.
10. Pick one non-production pipeline and run a post-quantum signing test on it.

Frequently asked questions

What happens when the Windows Production PCA 2011 certificate expires?

It reaches its end date on October 19, 2026, and Microsoft is replacing it with Microsoft Windows Production PCA 2026. Files signed earlier with a trusted timestamp stay valid. Software that pins the old certificate or hard-codes Microsoft’s signing settings is what can fail.

Will post-quantum code signing affect my existing code signing certificate?

Not directly. Microsoft’s 2027 plan covers Windows production signing. Your current certificate keeps working until it expires. We have not found a CA/Browser Forum rule that requires post-quantum algorithms for publicly trusted code signing certificates. Ask your CA about its plans at your next renewal.

What is ML-DSA and how is it different from RSA for code signing?

ML-DSA is NIST’s main post-quantum signature standard, published as FIPS 204 in August 2024. RSA depends on factoring large numbers, which a quantum computer could break. ML-DSA depends on lattice problems. Its signatures are much larger: 3,293 bytes at level 65, against 384 for RSA-3072.

What is hybrid code signing?

Hybrid signing attaches a classical signature (RSA or ECDSA) and a post-quantum signature (ML-DSA) to the same software. Older systems verify the classical one, newer systems can verify both. It keeps compatibility during the transition, at the cost of bigger signatures and more testing.

Do I need to replace my code signing certificate before 2027?

We have seen no requirement to do so. Renew on your normal cycle, keep timestamping, and use the time to test your pipeline and ask your HSM vendor about ML-DSA support.

How does the 460-day limit affect timestamps?

It does not shorten how long signed code stays trusted. A signature with an RFC 3161 timestamp remains valid after the certificate expires. Without a timestamp, it stops validating at expiry. Timestamp every build.