Windows Code Signing Moves Toward Post Quantum Security in 2027

Microsoft is in the process of shaping major changes to Windows code signing that will have the effect of altering the certificate infrastructure, the cryptographic algorithms, and, in the end, how Windows applications will be protected against future quantum computing threats.

The changes are of particular importance to developers, IT administrators, security teams, and organizations that are using their custom software or security tools that can do their own code signature validation.

The Transition has Three Major Stages:

• Replacing the Windows Production PCA 2011 certificate in 2026
• Moving to advanced signing configurations including RSA-3072 and SHA-384
• Finally planning to move toward post-quantum cryptography (PQC) for Windows Production in 2027.

Windows Production PCA 2011 Certificate to Expire in October 2026

The Windows Production PCA 2011 certificate is one of the initial modifications that will occur. This certificate is set to expire on October 19, 2026.

The company has already begun its efforts to change the authority of the certificate. Regardless, one should not see problems with the majority of Windows applications, as their software is able to determine if the application is valid from both a legal and technical point of view.

Recommended: Google Cloud KMS Adds Generally Available Quantum-Safe Digital Signatures

Nonetheless, compatibility issues may arise with applications that are programmed to assume that certain signing rules have always been in place.

For instance, the application may be written to trust the specific certificate issuing company known as Windows Production PCA 2011, or it may check the specific thumbprint or have other criteria.

Once Microsoft changes its certificate hierarchy, the application may run into something like:

Expected: Old Microsoft certificate

Received: New Microsoft certificate

Old ≠ New

       ↓

Application rejects software

This could cause legitimate Microsoft-signed software to be incorrectly rejected even though Windows itself considers the new certificate valid.

Microsoft’s Windows Code-Signing Timeline

The transition can be summarized as follows:

Period	Change
October 19, 2026	Windows Production PCA 2011 certificate expires
2026	Microsoft moves toward stronger signing configurations, including RSA-3072 and SHA-384
2027	Windows Production signing is planned to move toward post-quantum cryptography by default
Beyond 2027	Continued certificate rotations and cryptographic updates are expected

Hard-Coded Certificate Checks Create Compatibility Risks

The biggest concern for developers is not the certificate replacement itself, but software that has been designed around a specific certificate or signing configuration.

For example, a poorly designed application might effectively perform a check such as:

if certificate_thumbprint == “ABC123…”:

    allow

else:

    reject

This approach is fragile because certificates are expected to expire and be replaced.

A better approach is to use Windows-supported trust-validation mechanisms to determine whether a signature is valid and whether the certificate chain leads to a trusted authority.

The same principle applies to hard-coded values for:

• Certificate thumbprints
• Certificate hashes
• Certificate Authority names
• Certificate issuers
• Certificate subjects
• Specific signing algorithms
• Other fixed signing identifiers

Developers should avoid assuming that Microsoft’s current certificate hierarchy or cryptographic configuration will remain unchanged indefinitely.

Recommended: AWS KMS Embraces the Quantum Era with ML-DSA Digital Signature Support

Microsoft Is Moving Toward Stronger Cryptography

Microsoft is enhancing the cryptographic standards that are used for Windows Production signing.

The target is to use RSA-3072 and SHA-384 configurations through 2026.

RSA-3072 and SHA-384 have different roles in the cryptographic process. The RSA standard is a public-key cryptography system that is intended to generate digital signatures, while SHA-384 is the hash function that is applied during the signing process.

The simplified signing process is presented below:

Software

    │

    ▼

SHA-384 hash

    │

    ▼

Digital signature

    │

    ▼

Certificate

    │

    ▼

Windows verifies signature

The important point for developers is that applications should not unnecessarily depend on one specific algorithm.

For example, an application that assumes:

Signature algorithm = SHA-256

could encounter problems if Microsoft legitimately moves to a stronger configuration.

Software should instead use supported Windows validation mechanisms and remain as algorithm-agnostic as practical.

Post-Quantum Cryptography Is Planned for 2027

Changes in the long run refer to Microsoft’s driving force for post-quantum cryptography.

Public-key cryptography today is based on hard mathematical problems for regular computers. However, a powerful enough quantum computer could threaten some of the public-key encryption algorithms used today.

Post-quantum cryptography refers to cryptography meant to protect against attacks by quantum computers. The transition to Windows production signing will happen in 2027.

However, it does not mean that quantum computers will start to hack Windows in 2027. Microsoft is utilizing the head start in migrating to post-quantum cryptography because it requires a great deal of time to change the crypto systems across a wide ecosystem of software products.

The transition can be viewed as:

2026

 │

 ├── Replace Windows Production PCA 2011

 │

 ├── Stronger signing configurations

 │      ├── RSA-3072

 │      └── SHA-384

 │

 ▼

2027

 │

 └── Post-quantum cryptography

Which Organizations Are Most Likely to Be Affected?

Most ordinary Windows users are unlikely to notice these changes directly.

The greater risk exists in organizations that operate applications or security systems performing their own certificate validation.

These may include:

• Custom internal applications
• Enterprise software
• Software deployment systems
• Application allowlisting solutions
• Security tools
• Endpoint protection products
• Code-signing validation systems
• Custom scripts and automation
• Applications using private trust stores

For example, an organization’s security tool might maintain a private trust store containing Microsoft’s certificates. If that system depends on an old certificate that Microsoft replaces, the organization may need to update its configuration.

What IT Administrators Should Do

Organizations should begin reviewing software and systems that perform custom code-signature validation.

First, IT teams should identify applications and security tools that validate Windows signatures independently rather than relying entirely on the Windows trust infrastructure.

They should then check whether those systems contain dependencies on specific:

• Certificate thumbprints
• Certificate hashes
• Certificate Authorities
• Certificate issuers
• Certificate names
• Signing algorithms

Organisations should reach out to major software providers to ensure that their software is updated according to Microsoft’s new certification and changes in cryptography.

Particular emphasis should be put on private trust stores, as they may have to go through manual procedures in case of a shift on the certificate hierarchy.

Last but not least, companies must start thinking of post-quantum cryptography and integrate it into their long-term plans even if its implementation is not yet required by regulation.

Conclusion

Microsoft’s new Windows code-signing technologies tend to focus less on hindering existing Windows apps, but rather on making it possible for applications to accept changes to security arrangements.

For the majority of Windows customers, the adjustment will likely happen seamlessly. Actually, major compatibility issues may occur if the program or the security tools cannot avoid hardware assumptions about Microsoft’s certificates or encryption algorithms.

It means that the developers should regard only the values of Windows merit-based systems and not the fingerprints of the certificate they might use or their respective signing method.

The IT department should then check their systems with the help of the signing platform and conduct trial runs of the applications that have been developed.

The broader message is straightforward: software should trust a valid and trusted signing chain—not depend on one particular certificate or algorithm forever.

Search