Business News

Microsoft Changes NuGet Signing in 2026: What .NET Developers Need to Do Now

Microsoft is changing the certificate it uses to author sign its NuGet packages.

The change began on September 23, 2026, and most .NET developers will not need to make any changes. However, development teams that use strict NuGet package trust policies or explicitly verify Microsoft's signing certificates need to update their configuration.

For teams using enterprise CI/CD pipelines, package security policies, or controlled software supply chains, overlooking this change could result in NuGet package installation or restore failures.

Here is what .NET developers and development teams need to know.

What Is Changing in NuGet?

NuGet packages can be digitally signed using X.509 certificates. These signatures allow package consumers to verify the authenticity and integrity of packages.

Microsoft uses author signing certificates for its NuGet packages.

Starting September 23, 2026, Microsoft is transitioning to a new author signing certificate for newly signed NuGet packages. Packages that were already signed with Microsoft's previous certificates will keep their existing signatures.

The new Microsoft certificate has this SHA 256 fingerprint:

9A1B131BEE0605433056A4EA3815478A8E177961A968C6C0027C1093D1FEB630

The previous certificate has this fingerprint:

566A31882BE208BE4422F7CFD66ED09F5D4524A5994F50CCC8B05EC0528C1353

Microsoft recommends keeping the older certificates in your configuration while adding the new certificate. This allows your environment to continue trusting both existing packages and newly signed packages.

Who Is Actually Affected?

This is the important part.

Most .NET developers do not need to do anything.

If your application simply restores packages from NuGet using the standard configuration, Microsoft says the certificate transition should not affect you.

The teams that need to pay attention are primarily those using custom package security policies.

You may be affected if your organization:

1. Uses trustedSigners in nuget.config
2. Enforces package signature validation
3. Uses dotnet nuget verify
4. Explicitly validates Microsoft's certificate fingerprints
5. Has CI/CD pipelines that allow only specific NuGet signing certificates

NuGet's trustedSigners configuration allows organizations to define which package authors or repositories are trusted.

For example, an organization might configure NuGet to accept packages only from specific trusted signers.

That provides stronger control over the software supply chain, but it also means certificate changes need to be managed carefully.

What Happens If You Do Nothing?

If your environment uses a strict trusted signer policy and the new Microsoft certificate has not been added, a newly signed Microsoft package can fail validation.

Microsoft specifically warns that installing a package signed with the new certificate without updating the trusted signer configuration can result in an NU3034 error.

This can become particularly inconvenient when the failure happens during:

dotnet restore

or inside an automated CI/CD pipeline.

A developer might see the problem as a package restore issue, while the underlying cause is actually the organization's certificate trust configuration.

How to Check Your Project

The first thing development teams should do is check whether their environment uses custom NuGet trust settings.

Look for:

nuget.config
trustedSigners
signatureValidationMode
dotnet nuget verify
certificate-fingerprint

Remember that nuget.config can exist at different configuration levels, so checking only the project directory may not be enough.

You should also check your CI/CD configuration because certificate verification may be configured in build scripts rather than directly inside the project.

Updating Trusted Signers

If your organization uses a NuGet trusted signer policy for Microsoft packages, Microsoft recommends adding the new certificate while retaining the existing certificates.

For .NET 6 SDK and later, you can use:

dotnet nuget trust author Microsoft 9A1B131BEE0605433056A4EA3815478A8E177961A968C6C0027C1093D1FEB630 --algorithm SHA256

This updates the applicable nuget.config file. You can also specify a particular configuration file using the --configfile option.

Your configuration should continue to contain the older Microsoft certificates as well.

A simplified example looks like this:

<trustedSigners>
    <author name="Microsoft">
        <certificate
            fingerprint="566A31882BE208BE4422F7CFD66ED09F5D4524A5994F50CCC8B05EC0528C1353"
            hashAlgorithm="SHA256"
            allowUntrustedRoot="false" />

        <certificate
            fingerprint="9A1B131BEE0605433056A4EA3815478A8E177961A968C6C0027C1093D1FEB630"
            hashAlgorithm="SHA256"
            allowUntrustedRoot="false" />
    </author>
</trustedSigners>

Microsoft's documentation includes additional historical Microsoft certificates that organizations may already have in their configuration.

What If You Use dotnet nuget verify?

Some development teams explicitly verify NuGet packages before allowing them into their applications or build pipelines.

The dotnet nuget verify command can verify a package's signature and can also be configured to accept specific SHA 256 certificate fingerprints.

For example:

dotnet nuget verify PackageName.nupkg \
  --certificate-fingerprint 566A31882BE208BE4422F7CFD66ED09F5D4524A5994F50CCC8B05EC0528C1353 \
  --certificate-fingerprint 9A1B131BEE0605433056A4EA3815478A8E177961A968C6C0027C1093D1FEB630

The important point is to add the new fingerprint rather than replacing the existing one.

That allows your verification process to accept packages signed using both the previous and new Microsoft certificates.

Why Does NuGet Package Signing Matter?

Modern applications rarely consist entirely of code written by the development team.

A typical .NET application can depend on dozens or hundreds of external packages.

Those dependencies can provide:

Authentication
Database access
Logging
API integrations
Cloud services
Testing frameworks
UI components
Development utilities

That makes dependency security an important part of application security.

NuGet package signatures provide a mechanism for verifying package authenticity and integrity. When signature verification is enabled, NuGet can verify signed packages during package restore.

This is especially relevant for organizations with strict security requirements.

What About CI/CD Pipelines?

This is where development teams should pay particular attention.

A local developer environment might successfully restore packages while a production build fails because the CI/CD environment has additional security restrictions.

For example, your pipeline may contain:

Package restore
        ↓
Signature verification
        ↓
Trusted certificate validation
        ↓
Build
        ↓
Testing
        ↓
Deployment

If the certificate isn't included in the trusted list, the pipeline can stop during package restoration or verification.

Teams should therefore check:

GitHub Actions

Azure DevOps

GitLab CI/CD

Jenkins

Self hosted build servers

Enterprise build environments

Any scripts that explicitly verify NuGet package certificates should also be reviewed.

A Simple Checklist for .NET Teams

If your organization manages NuGet package security, use this checklist:

1. Check your nuget.config files

Search for trustedSigners and signatureValidationMode.

2. Check your build pipelines

Look for dotnet nuget verify and certificate fingerprint parameters.

3. Add Microsoft's new certificate

Use the new SHA 256 fingerprint:

9A1B131BEE0605433056A4EA3815478A8E177961A968C6C0027C1093D1FEB630

4. Keep existing certificates

Do not remove older Microsoft certificates that are still needed for previously signed packages.

5. Test package restoration

Run your normal restore and build process.

6. Test CI/CD

Make sure automated builds can restore and verify the required packages.

Do You Need to Change Your Application Code?

No.

This certificate transition is not a change to your application's .NET code.

You do not need to rewrite your application, change your C# code, or update your application's business logic because of this certificate change.

The required changes, when applicable, are related to NuGet trust and package verification configuration.

The Bigger Lesson for Development Teams

Certificate rotation may sound like a small infrastructure change, but it highlights a larger issue in modern software development.

Your application's security does not stop at your own source code.

Third party packages, build systems, dependency management, signing certificates and CI/CD infrastructure are all part of the software supply chain.

For teams using strict security controls, those systems need to be maintained just as carefully as the application itself.

Microsoft's NuGet certificate update is a good example.

The developers who don't use custom package verification may never notice the transition.

For teams that do enforce certificate based trust, however, a small configuration change can determine whether the next dotnet restore succeeds or fails.

Final Takeaway

Microsoft's NuGet author signing certificate update does not require every .NET developer to change their projects.

The main impact is on organizations that explicitly trust Microsoft through certificate fingerprints or enforce NuGet package signature policies.

If your team uses these security controls, check your nuget.config, CI/CD pipelines and package verification scripts now.

Adding the new certificate while retaining the existing certificates can help prevent package restore and verification failures during the transition.

In modern software development, dependency security is part of application security.

And sometimes, a certificate change is all it takes to expose whether your software supply chain is properly maintained.