A package restore can fail even when the package version has not changed and the package itself is legitimate. One possible reason is a certificate change that an application's package-trust policy does not recognize.
Microsoft began transitioning to a new author-signing certificate for its NuGet packages on September 23, 2026. Existing packages signed with the previous certificate retain their signatures, but newly signed packages use the new certificate.
For .NET developers, the important detail is that a trusted-signer policy can reject a legitimate Microsoft package if the new certificate has not been added to the allowlist.
Teams that rely on NuGet's default package verification may not need to change anything. The update primarily affects developers and organizations that explicitly pin Microsoft author-signing certificate fingerprints or verify packages against a fixed list of accepted certificates.
Understanding this distinction helps teams update their trust configuration without weakening package-security controls.
What Is a NuGet Package-Signing Certificate?
NuGet is the package-management system used by .NET applications to download and manage dependencies. Packages can contain compiled assemblies, source files, build targets, analyzers, and other assets required by an application.
Package signing adds a cryptographic mechanism for checking package integrity and authenticity.
An author signature identifies the publisher that signed a package and helps establish that the package has not been modified since signing. A repository signature provides integrity guarantees associated with the package repository.
These signatures rely on certificates that can change over time. Certificates expire, organizations rotate signing credentials, and security requirements evolve.
Microsoft uses an X.509 certificate to author-sign its NuGet packages. When Microsoft changes that certificate, package consumers that explicitly trust only the previous fingerprint must update their policies to recognize the replacement.
This is not the same as changing a package version. A package can have the expected name and version while carrying a signature made with a different, legitimate certificate.
What Changed in September 2026?
Microsoft announced a new author-signing certificate that became the default for its NuGet packages starting September 23, 2026.
The certificate fingerprints are:
Certificate | SHA-256 fingerprint |
|---|
Previous certificate | 566A31882BE208BE4422F7CFD66ED09F5D4524A5994F50CCC8B05EC0528C1353
|
New certificate | 9A1B131BEE0605433056A4EA3815478A8E177961A968C6C0027C1093D1FEB630
|
A fingerprint is a cryptographic identifier calculated from a certificate. NuGet client policies can use it to identify which signing certificates are trusted.
The previous certificate remains relevant because older package versions retain their original signatures. A policy that accepts only the new certificate could therefore reject older packages, just as a policy that accepts only the previous certificate could reject newly signed packages.
The correct approach is to trust both certificates during the transition rather than replacing the old fingerprint outright.
Who Needs to Take Action?
Not every .NET developer needs to modify their NuGet configuration.
The change is particularly relevant to two groups.
Teams Using Trusted-Signer Policies
NuGet supports policies that require packages to be signed by explicitly trusted authors or repositories.
For example, a repository may contain a nuget.config file with the following settings:
<configuration>
<config>
<add key="signatureValidationMode" value="require" />
</config>
<trustedSigners>
<author name="Microsoft">
<certificate
fingerprint="566A31882BE208BE4422F7CFD66ED09F5D4524A5994F50CCC8B05EC0528C1353"
hashAlgorithm="SHA256"
allowUntrustedRoot="false" />
</author>
</trustedSigners>
</configuration>
This configuration requires signature validation and explicitly trusts the listed Microsoft certificate.
After the certificate transition, a newly signed Microsoft package may fail validation because its signing fingerprint is missing from the policy.
The resulting failure can occur during package restore, which may prevent local builds and CI pipelines from completing.
Teams Using Explicit Certificate Verification
Some organizations run dotnet nuget verify as part of their security checks.
A pipeline may verify that a package was signed using one of a predefined set of Microsoft certificates. If the command includes only older fingerprints, a package signed with the new certificate may fail verification.
These checks are often intentional security controls. They should be updated carefully instead of removed simply to make a build pass.
Teams Using Default NuGet Verification
If your project does not enforce a custom Microsoft signer allowlist or explicitly verify Microsoft author-signing fingerprints, you may not be affected by this particular change.
Do not assume that every package restore failure is related to the certificate rotation. First inspect the actual error and the package-verification configuration.
Step 1: Find Your NuGet Configuration Files
NuGet configuration can exist at several scopes, including the machine, user, and repository levels. A configuration file in one location may affect a build even when the project directory contains no nuget.config.
Inspect the effective configuration:
dotnet nuget list source
This command lists configured package sources. It does not display every trusted-signer setting, so also inspect the relevant nuget.config files directly.
Search your repository for the following settings:
<add key="signatureValidationMode" value="require" />
And:
<trustedSigners>
On PowerShell, you can search project files with:
Get-ChildItem -Recurse -Filter nuget.config |
Select-String -Pattern "signatureValidationMode|trustedSigners|566A3188"
This is a repository-level search. Machine-wide and user-level configuration files may be outside the current directory, so inspect those locations when investigating a developer workstation or build agent.
Also check scripts that invoke dotnet nuget verify. The fingerprints may be stored in pipeline variables or shared build templates rather than in nuget.config.
Step 2: Add the New Microsoft Certificate
The recommended approach is to add the new fingerprint while retaining the existing Microsoft certificates.
With the .NET 6 SDK or later, use the NuGet trust command:
dotnet nuget trust author Microsoft 9A1B131BEE0605433056A4EA3815478A8E177961A968C6C0027C1093D1FEB630 --algorithm SHA256
This updates the applicable NuGet configuration. If you need to change a specific configuration file, use the supported --configfile option.
For example:
dotnet nuget trust author Microsoft 9A1B131BEE0605433056A4EA3815478A8E177961A968C6C0027C1093D1FEB630 --algorithm SHA256 --configfile ./nuget.config
Check the resulting file to confirm that the new fingerprint was added to the intended Microsoft author entry and that existing trusted certificates remain present.
If your installed tooling does not support this command, you can edit the trustedSigners section manually.
The updated configuration should contain both fingerprints:
<configuration>
<config>
<add key="signatureValidationMode" value="require" />
</config>
<trustedSigners>
<author name="Microsoft">
<certificate
fingerprint="566A31882BE208BE4422F7CFD66ED09F5D4524A5994F50CCC8B05EC0528C1353"
hashAlgorithm="SHA256"
allowUntrustedRoot="false" />
<certificate
fingerprint="9A1B131BEE0605433056A4EA3815478A8E177961A968C6C0027C1093D1FEB630"
hashAlgorithm="SHA256"
allowUntrustedRoot="false" />
</author>
</trustedSigners>
</configuration>
This is a simplified example. If your current policy includes other trusted Microsoft certificates, preserve them as well.
Do not change allowUntrustedRoot to true merely to bypass a validation failure. That setting affects certificate-chain trust and is not a substitute for correctly updating the trusted certificate list.
Step 3: Update Explicit Package-Verification Commands
If your pipeline verifies Microsoft package signatures directly, update the accepted fingerprint list.
For example:
dotnet nuget verify Microsoft.Package.nupkg \
--certificate-fingerprint 3F9001EA83C560D712C24CF213C3D312CB3BFF51EE89435D3430BD06B5D0EECE \
--certificate-fingerprint AA12DA22A49BCE7D5C1AE64CC1F3D892F150DA76140F210ABD2CBFFCA2C18A27 \
--certificate-fingerprint 566A31882BE208BE4422F7CFD66ED09F5D4524A5994F50CCC8B05EC0528C1353 \
--certificate-fingerprint 9A1B131BEE0605433056A4EA3815478A8E177961A968C6C0027C1093D1FEB630
Replace Microsoft.Package.nupkg with the actual package path. The example retains older Microsoft fingerprints and adds the new one.
Each --certificate-fingerprint option adds an accepted certificate fingerprint. This allows the verification step to recognize packages signed with the accepted certificates.
Use this configuration only when the policy is intended to validate Microsoft author signatures against these fingerprints. If your pipeline checks other publishers, maintain their independent trust policies.
Also verify that the command's exit code is handled correctly. A pipeline should fail when signature verification genuinely fails, not ignore the failure to keep a deployment moving.
Step 4: Test Package Restore in CI/CD
After updating the configuration, validate it in the same environment that builds your application.
Start with a restore:
dotnet restore
Then build and test:
dotnet build --no-restore
dotnet test --no-build
These commands help confirm that package restore and the application's normal validation steps work with the updated policy.
For a stronger test, include a package signed with the new Microsoft certificate and, where relevant, an existing package signed with an older accepted certificate.
Run the test in a clean or isolated environment to avoid relying on packages already present in the local cache. A cached package may conceal a restore problem that appears on a fresh build agent.
Remember that a successful restore is not proof that every package in the repository has been verified against the intended publisher policy. Review the verification steps and their logs to ensure the expected checks actually ran.
Step 5: Update Shared Build Infrastructure
If several repositories use the same NuGet configuration or CI template, update the shared policy instead of fixing each project independently.
Check:
- Centralized
nuget.config files. - CI/CD templates and reusable workflows.
- Container images used by build agents.
- Internal package verification scripts.
- Developer environment setup documentation.
- Build images and caches that may contain older configuration files.
Avoid copying a local developer's configuration into every repository without reviewing its scope. A machine-level policy and a repository-level policy can serve different purposes.
Document the accepted Microsoft certificate fingerprints and establish a process for future certificate rotations. Otherwise, the same issue can recur when the next legitimate signing certificate is introduced.
Common Mistakes to Avoid
Replacing the Old Certificate Instead of Adding the New One
Older packages retain their original signatures. Removing the previous fingerprint can break restores or verification for packages that are still required by your application.
Disabling Signature Validation
Turning off a required-signature policy may hide the immediate error, but it also removes a security control. Update the trust policy rather than disabling verification.
Updating Only One Configuration File
NuGet configuration can come from multiple scopes. A repository change may not resolve a failure caused by a user-level or machine-level policy.
Assuming a Package Version Change Is Required
The certificate transition concerns package signatures, not necessarily package contents or versions. You generally do not need to upgrade every Microsoft dependency just to accommodate the new certificate.
Ignoring Cached Packages
A developer workstation may already have the required packages cached. Always test restore behavior in a clean environment or on a fresh CI agent.
Summary
Microsoft's September 2026 NuGet author-signing certificate transition affects developers who explicitly trust Microsoft signing fingerprints or verify package signatures against a fixed certificate list.
The main task is to add the new fingerprint while retaining the older accepted certificates, update explicit verification commands, and validate the configuration in CI/CD. Teams using NuGet's default verification behavior without a custom Microsoft signer policy may not need any changes for this transition.
The broader engineering lesson is that certificate rotation is a normal part of secure software delivery. Explicit trust policies provide useful protection, but they also need a maintenance process that allows legitimate certificate changes without weakening signature verification.
Join the conversation! Your thoughts help the community grow.