Microsoft’s 2026 NuGet Certificate Update and What It Means for Software Security

The significance of software supply chain security is on the rise in today’s software development practices. Organizations around the world are increasingly depending upon third-party software libraries, package managers, CI/CD pipelines, and automation for dependency management. Therefore, verifying the authenticity and integrity of software is critical.

Starting September 23, 2026, Microsoft will adopt a new certificate for author-signing NuGet packages. Microsoft is making this change to the certificate used for author-signing all new NuGet packages.

For most .NET developers, this change will not be of concern, but organizations that require compliance with strict NuGet package signing practices may require further configuration to avoid installation issues or failures in verifying packages.

What Is Changing?

Microsoft employs the use of the digital certificate X.509 in order to author-sign their NuGet packages. The use of the digital signature allows consumers to verify the package and make sure that it was signed by a publisher introducing the expected publisher and the fact that the signed content has not been changed.

Microsoft has announced the following certificate transition:

Current Microsoft author-signing certificate:

566A31882BE208BE4422F7CFD66ED09F5D4524A5994F50CCC8B05EC0528C1353

New Microsoft author-signing certificate:

9A1B131BEE0605433056A4EA3815478A8E177961A968C6C0027C1093D1FEB630

What matters is that packages that were signed with the old Microsoft certificates will be unaffected. From now on, the new certificate will apply only to the new packages that Microsoft will sign. This is not a change to the way NuGet works, but just a certificate rollover process.

Who Could Be Affected?

The update for certificates is essential, especially for any organization that uses a strict package signing policy.

There are two major scenarios:

NuGet Trusted Signers

Organizations can set up NuGet such that only packages from specifically trusted publishers and certificates are accepted.

For example:

<config>
    <add key="signatureValidationMode" value="require" />
</config>
<trustedSigners>
    <author name="Microsoft">
        <certificate
fingerprint="566A31882BE208BE4422F7CFD66ED09F5D4524A5994F50CCC8B05EC0528C1353"
            hashAlgorithm="SHA256"
            allowUntrustedRoot="false" />
    </author>
</trustedSigners>

This gives more control over the signed packages that can access the development environment of the organization.

However, it has to be noted that if Microsoft starts signing the new packages with the new certificate, a policy that only has the old fingerprint can reject those new packages. According to Microsoft, this might cause an NU3034 error.

dotnet nuget verify

Some organizations explicitly verify NuGet packages before allowing them into their build process.

For Example:

dotnet nuget verify package.nupkg \
  --certificate-fingerprint 566A31882BE208BE4422F7CFD66ED09F5D4524A5994F50CCC8B05EC0528C1353

If the verification process only recognizes the old certificate, newly signed Microsoft packages may not pass verification. Therefore, include the new fingerprint while keeping the original fingerprints intact.

The Correct Way to Handle Certificate Rotation

Certificate rotation must be approached as a process in terms of planning for both security and operations. Instead of replacing the old Microsoft certificate with a new one, organizations must operate both in parallel.

The trusted-signers configuration can include the new certificate along with the current ones:

<trustedSigners>
    <author name="Microsoft">
        <certificate
            fingerprint="3F9001EA83C560D712C24CF213C3D312CB3BFF51EE89435D3430BD06B5D0EECE"
            hashAlgorithm="SHA256"
            allowUntrustedRoot="false" />
        <certificate
            fingerprint="AA12DA22A49BCE7D5C1AE64CC1F3D892F150DA76140F210ABD2CBFFCA2C18A27"
            hashAlgorithm="SHA256"
            allowUntrustedRoot="false" />
        <certificate
            fingerprint="566A31882BE208BE4422F7CFD66ED09F5D4524A5994F50CCC8B05EC0528C1353"
            hashAlgorithm="SHA256"
 allowUntrustedRoot="false" />
        <certificate
            fingerprint="9A1B131BEE0605433056A4EA3815478A8E177961A968C6C0027C1093D1FEB630"
            hashAlgorithm="SHA256"
            allowUntrustedRoot="false" />
    </author>
</trustedSigners>

Microsoft also provides a CLI-based approach:

dotnet nuget trust author Microsoft \
9A1B131BEE0605433056A4EA3815478A8E177961A968C6C0027C1093D1FEB630 \
--algorithm SHA256

Why Code Signing Matters for Software Supply-Chain Security?

The concept of switching certificates by Microsoft brings forth a more important aspect of security in software systems. It entails the requirement of having a publishing identity that can be verified and also having an integrity mechanism in place.

Take the example of a Typical Software Delivery System:

Developer -> Source Code -> Build Pipeline -> Software Artifact -> Code Signing -> Distribution -> Customer

If integrity is not imposed, an attacker may have the opportunity to change the software once he gets access to an artifact repository, a distribution server, or a build environment.

Digital signatures provide another layer of verification. If the software has been altered since signing, the signature verification will determine whether or not the signed content is still the same as the original piece of software.

Code Signing and Certificate Trust

A code signing certificate provides a cryptographic identity associated with the signer. Organizations can establish trust policies around:

• Trusted certificate authorities
• Trusted publishers
• Certificate fingerprints
• Signing certificates
• Signature validity
• Artifact integrity
• Certificate expiration and renewal
• Certificate rotation

This becomes especially important in enterprise environments where software is distributed across thousands of systems.

Certificate Rotation Is Part of Certificate Lifecycle Management

The Microsoft example also demonstrates why certificate lifecycle management needs to be part of DevSecOps processes.

A Certificate can eventually require replacement because of:

• Certificate expiration
• Key rotation
• Changes in cryptographic requirements
• Organizational security policies
• Certificate authority lifecycle changes
• Operational security requirements

A mature software signing process should therefore account for certificate rotation before it becomes an operational problem.

A Useful Lifecycle Looks like:

Certificate Procurement -> Identity Validation -> Software Signing -> Certificate Monitoring -> Renewal / Rotation -> Trust Policy Update -> Continued Verification

What DevSecOps Teams Should Check?

Organizations should then test:

• Normal NuGet package installation
• Package signature validation
• CI/CD dependency restoration
• Build pipelines
• Internal package repositories
• Developer workstations using centralized NuGet configuration.
• Automated package verification processes.

This helps ensure that certificate rotation doesn’t unexpectedly break the software delivery pipeline.

Conclusion

In order to set up a reliable code-signing procedure, companies may consider obtaining a CA code-signing certificate from SignMyCode, which can be incorporated into the development process, software deployment, and DevSecOps process.

By signing the software ahead of its distribution and ensuring the ongoing provision of the trusted certificate, companies may offer their customers and enterprises a better way to verify the authenticity of the software.

Search