Microsoft begins rotating its NuGet author-signing certificate on 2026-09-23

What happened on 2026-09-23

On 2026-09-23, the NuGet team posted on the .NET blog that Microsoft was replacing the X.509 certificate it uses to author-sign NuGet packages. From 2026-09-23 the new certificate becomes the default. Packages already signed with older certificates keep their signatures, and after the transition the current certificate will no longer sign new packages. The post lists SHA-256 fingerprints for both the current and the new certificate. It says only two groups are affected. The first is users whose NuGet client policy sets signatureValidationMode to require and whose trusted-signer allow list includes Microsoft. They must add the new fingerprint to the Microsoft entry in nuget.config while keeping the older ones, or installing a package signed with the new certificate fails with error NU3034. The second is users who run dotnet nuget verify to check Microsoft author signatures; they need to pass the new fingerprint as well. The post gives a dotnet nuget trust author example that requires the .NET 6 SDK or later.

What it means for app integrity

Protecting a .NET app is not only about protecting the code you write. It also means confirming that the dependencies you ship really come from the expected publishers. Enforced signature validation with an allow list is one of the few mechanisms that can stop an unexpected package at restore time. During a certificate rotation the most common risk is not an attack but the reflex of 'the build broke, turn validation off for now', and once validation is off it rarely gets turned back on. The limits matter too. An author signature shows who signed a package and that it has not changed since; it does not show the code is safe. It is also unrelated to your app's own Authenticode signature, obfuscation or Native AOT. Check any fingerprint copied from a forum or a third-party post against the official article, because trust lists are themselves a target.

Checks you can put in place

First, search every repository and CI image for nuget.config files and check whether signatureValidationMode is set to require and whether a Microsoft trusted-signer entry exists. Second, if it is enabled, add the new fingerprint as the official article describes and keep the older ones, taking the fingerprint values from the official article only. Third, update any CI scripts that call dotnet nuget verify so they include the new fingerprint. Fourth, run a full restore in a clean build environment to confirm there are no NU3034 errors, and log the change in your build-configuration history so it can be audited later.

Your checklist

• Search nuget.config files for require mode and Microsoft trusted signers
• Add the new fingerprint from the official post and keep older ones
• Run a clean restore and confirm there are no NU3034 errors