NuGet packages are part of almost every modern .NET application. Whether you are building an ASP.NET Core API, a Blazor application, a background service, or a large enterprise system, your project probably depends on dozens of packages.

Most developers think about package management in terms of package versions, compatibility, and restore performance. Security is often less visible.

NuGet package signing adds another layer of protection by allowing developers and organizations to verify the authenticity and integrity of packages. For teams that enforce strict package trust policies, however, a certificate change can become a build or deployment issue if the new certificate is not recognized.

This became particularly relevant in September 2026, when Microsoft began transitioning to a new author-signing certificate for its NuGet packages.

The change does not affect every .NET developer. But if your organization explicitly trusts Microsoft package-signing certificates, or your build pipeline verifies Microsoft packages against specific certificate fingerprints, you may need to update your configuration.

This article explains what is changing, why it matters, how NuGet package signing works, and what .NET developers should check in their projects and CI/CD pipelines.

What Is NuGet Package Signing?

A NuGet package can contain a digital signature that helps establish its authenticity and protects against package content being modified after signing.

NuGet uses X.509 certificates for package signing. An author signature is associated with the package publisher, while repository signatures provide information associated with the package repository.

For an application developer, the important question is simple:

Can I verify that this package was signed by a trusted publisher and that its contents have not been altered?

Package signing helps answer that question.

For example, an organization might decide that packages published by certain internal teams or trusted vendors are allowed, while packages from unknown publishers should not be accepted during restore.

This becomes particularly useful in enterprise environments where software supply-chain security is an important part of the development process.

Why Is Microsoft Changing Its NuGet Signing Certificate?

Microsoft uses an X.509 certificate to author-sign its NuGet packages.

Starting September 23, 2026, Microsoft began using a new certificate as the default author-signing certificate for new NuGet packages.

Existing packages signed with older certificates do not suddenly become unsigned. Their existing signatures remain intact.

The important distinction is between:

• Packages that already exist and were signed with an older certificate
• New packages signed using Microsoft’s new certificate
• Your application’s rules for deciding which certificates are trusted

If your NuGet configuration accepts Microsoft’s packages without restricting certificates, you may not notice anything.

If your organization has explicitly configured Microsoft’s certificate fingerprints as trusted signers, however, the new certificate needs to be added. (Microsoft Developer Blogs)

Who Needs to Pay Attention?

Not every .NET developer needs to change anything.

You should investigate your setup if you use either of these approaches:

1. A NuGet client policy with trustedSigners
2. dotnet nuget verify with Microsoft’s certificate fingerprints

For example, a strict configuration may contain:

<config>

  <add key="signatureValidationMode" value="require" />

</config>

along with a trustedSigners section.

Another possibility is a CI/CD script that verifies packages using:

dotnet nuget verify package.nupkg \

  --certificate-fingerprint <fingerprint>

If your pipeline explicitly checks certificate fingerprints, it needs to recognize the new Microsoft certificate.

Microsoft states that environments using neither trusted-signer policies nor certificate fingerprint verification are generally unaffected by this particular certificate update. (Microsoft Developer Blogs)

Microsoft’s Current NuGet Certificate Fingerprints

The certificate transition is the most important technical detail in this update.

Microsoft identifies the current and new certificates using SHA-256 fingerprints.

The current certificate fingerprint is:

566A31882BE208BE4422F7CFD66ED09F5D4524A5994F50CCC8B05EC0528C1353

The new certificate fingerprint is:

9A1B131BEE0605433056A4EA3815478A8E177961A968C6C0027C1093D1FEB630

Microsoft’s trusted-signer example also includes two older Microsoft certificates:

3F9001EA83C560D712C24CF213C3D312CB3BFF51EE89435D3430BD06B5D0EECE

and:

AA12DA22A49BCE7D5C1AE64CC1F3D892F150DA76140F210ABD2CBFFCA2C18A27

These values should be treated as security-sensitive configuration data. Always verify certificate fingerprints against Microsoft’s current official documentation before applying them to a production environment. (Microsoft Developer Blogs)

How to Check Your NuGet Configuration

The first step is to find out whether your project actually uses trusted-signing rules.

Look for a nuget.config file in your repository or in the configuration hierarchy used by your development environment and CI system.

You may find something similar to:

<configuration>

  <config>

    <add key="signatureValidationMode" value="require" />

  </config>

  <trustedSigners>

    <author name="Microsoft">

      <certificate

        fingerprint="566A31882BE208BE4422F7CFD66ED09F5D4524A5994F50CCC8B05EC0528C1353"

        hashAlgorithm="SHA256"

        allowUntrustedRoot="false" />

    </author>

  </trustedSigners>

</configuration>

Keep in mind that nuget.config files can exist at different scopes. A repository-level configuration, user-level configuration, or machine-level configuration can all affect package behavior.

Adding the New Microsoft Certificate

If you use a NuGet client policy with trusted signers, Microsoft recommends adding the new certificate while keeping the older Microsoft certificates.

The .NET CLI provides the dotnet nuget trust command for managing trusted signers.

For Microsoft’s new certificate, use:

dotnet nuget trust author Microsoft 9A1B131BEE0605433056A4EA3815478A8E177961A968C6C0027C1093D1FEB630 --algorithm SHA256

If you maintain a specific nuget.config, you can specify it explicitly:

dotnet nuget trust author Microsoft 9A1B131BEE0605433056A4EA3815478A8E177961A968C6C0027C1093D1FEB630 --algorithm SHA256 --configfile ./nuget.config

According to Microsoft, dotnet nuget trust is available in the .NET 6 SDK and later. (Microsoft Developer Blogs)

Updating

nuget.config

Manually

You can also update the XML configuration directly.

For the Microsoft author signer, the resulting configuration should retain the existing certificates and add the new certificate:

<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>

This is important because replacing the older certificates instead of adding the new one can prevent existing packages signed with those certificates from passing your trusted-signer policy. (Microsoft Developer Blogs)

What Happens If You Don’t Update It?

If your environment requires signed packages from trusted certificates and a new Microsoft package is signed using a certificate that isn’t on your trusted list, package installation or restore can fail.

Microsoft specifically identifies NU3034 as an error that can occur when a package signed with the new certificate is not yet trusted.

This can appear unexpectedly.

For example, a developer may update a package:

dotnet add package SomeMicrosoftPackage

and everything may work on one machine but fail inside an organization’s build server.

The reason may not be the package version itself.

The difference could be the NuGet configuration used by the build environment.

Why CI/CD Pipelines Are Important

This certificate change is especially worth checking in CI/CD.

Consider a typical pipeline:

Developer

    ↓

Git Repository

    ↓

CI Build

    ↓

dotnet restore

    ↓

Package Verification

    ↓

Build

    ↓

Tests

    ↓

Deployment

If package verification happens during dotnet restore, the trusted certificate configuration becomes part of the build environment.

For example, your GitHub Actions or Azure DevOps pipeline might execute:

dotnet restore

dotnet build --no-restore

dotnet test --no-build

The developer’s local machine may have an updated global NuGet configuration while the build server still uses an older configuration.

That creates an important rule:

Don’t verify package security only on developer machines. Make the CI environment part of the same security model.

Using

dotnet nuget verify

The .NET CLI provides the dotnet nuget verify command for verifying signed NuGet packages.

A basic example is:

dotnet nuget verify MyPackage.nupkg

If your pipeline verifies that a package was author-signed by Microsoft, you can supply the accepted certificate fingerprints.

For example:

dotnet nuget verify MyPackage.nupkg \

  --certificate-fingerprint 3F9001EA83C560D712C24CF213C3D312CB3BFF51EE89435D3430BD06B5D0EECE \

  --certificate-fingerprint AA12DA22A49BCE7D5C1AE64CC1F3D892F150DA76140F210ABD2CBFFCA2C18A27 \

  --certificate-fingerprint 566A31882BE208BE4422F7CFD66ED09F5D4524A5994F50CCC8B05EC0528C1353 \

  --certificate-fingerprint 9A1B131BEE0605433056A4EA3815478A8E177961A968C6C0027C1093D1FEB630

Each --certificate-fingerprint option adds an accepted SHA-256 signer certificate fingerprint.

Keeping the existing fingerprints and adding the new one allows the verification command to recognize both newly signed packages and existing packages signed with older Microsoft certificates. (Microsoft Developer Blogs)

Don’t Confuse Package Version Changes With Certificate Changes

This is one of the easiest mistakes to make during troubleshooting.

Suppose a build suddenly starts failing after a dependency update.

A developer might immediately investigate:

• .NET version
• Package version
• Target framework
• Dependency conflicts
• NuGet source
• Package compatibility

Those are reasonable checks.

But if the error is related to package signature validation, the problem may instead be the signing certificate.

For example:

Package update

      ↓

New package downloaded

      ↓

New Microsoft signing certificate

      ↓

Trusted signer doesn't contain certificate

      ↓

Package verification fails

      ↓

Build fails

Understanding this path can save considerable debugging time.

Why Keeping the Old Certificates Matters

Suppose your application already uses several Microsoft packages.

Some packages may have been published before the certificate transition:

Package A → older certificate

Package B → older certificate

Package C → older certificate

A newly published package may use:

Package D → new certificate

If you simply replace the old certificates with the new certificate, you may create another problem.

Your configuration could recognize:

Package D ✓

but fail to recognize:

Package A ✗

Package B ✗

Package C ✗

A better transition strategy is:

Existing Microsoft certificates

             +

New Microsoft certificate

             ↓

      Trusted Microsoft signer

This allows existing and newly signed packages to coexist.

Microsoft explicitly recommends keeping the older Microsoft certificates when adding the new certificate. (Microsoft Developer Blogs)

What About Developers Who Don’t Use Trusted Signers?

If your application does not use a strict trusted-signer policy and you are not explicitly verifying Microsoft packages against certificate fingerprints, you may not need to make a change for this particular certificate transition.

This is why checking the actual configuration is important.

Don’t modify a production NuGet security configuration simply because a certificate changed.

First determine whether your environment depends on the affected validation mechanism.

A Better Enterprise Configuration Strategy

For larger .NET projects, it can be useful to keep the important NuGet configuration in source control.

For example:

MyCompany.Project/

│

├── src/

├── tests/

├── nuget.config

├── MyCompany.sln

└── README.md

A repository-level nuget.config makes the package configuration explicit and repeatable across development and build environments.

It also makes changes easier to review.

For example, when the new certificate is added, the change can go through the same pull-request process as other security-related configuration changes.

This is preferable to silently modifying only one developer’s machine.

What Should You Check in Your CI/CD Pipeline?

If you maintain Azure DevOps, GitHub Actions, Jenkins, or another CI system, check these areas.

1.

nuget.config

Search for:

<trustedSigners>

and:

<add key="signatureValidationMode" value="require" />

2. Package verification commands

Search your scripts for:

dotnet nuget verify

and:

--certificate-fingerprint

3. Restore configuration

Check whether your pipeline passes a custom configuration file:

dotnet restore --configfile ./nuget.config

4. Build agents

Make sure the configuration on build agents matches the configuration expected by your repository.

5. Container images

If your builds run inside Docker containers, check whether the image contains an old nuget.config.

A local machine can be correctly configured while the container still uses an outdated configuration.

A Practical Troubleshooting Workflow

If package restore starts failing after the Microsoft certificate transition, don’t immediately remove signature validation.

Instead, follow a structured process.

Step 1: Read the Actual Error

Look for errors related to:

NU3034

signature

certificate

trusted signer

package validation

Step 2: Find the Active NuGet Configuration

Check repository-level and machine-level nuget.config files.

Step 3: Check

trustedSigners

Look for the Microsoft author entry.

Step 4: Check the Fingerprints

Determine whether the new Microsoft SHA-256 fingerprint is present.

The new fingerprint is:

9A1B131BEE0605433056A4EA3815478A8E177961A968C6C0027C1093D1FEB630

Step 5: Keep Existing Certificates

Don’t remove older trusted Microsoft certificates simply to make the new package work.

Step 6: Test Package Verification

Use:

dotnet nuget verify

with the appropriate fingerprints.

Step 7: Test the Actual Pipeline

A successful restore on your development machine does not necessarily prove that the CI environment is correctly configured.

What This Means for .NET Supply-Chain Security

The certificate update is a good reminder that dependency security is not just about choosing trusted package sources.

A modern .NET application may depend on hundreds of packages, directly and indirectly.

The security chain can look like:

Developer

    ↓

Package source

    ↓

NuGet package

    ↓

Package signature

    ↓

Trusted certificate

    ↓

NuGet verification

    ↓

Application build

    ↓

Production deployment

Each layer serves a different purpose.

Package signing does not eliminate every supply-chain risk, but it gives organizations another mechanism for validating package authenticity and integrity.

For companies with strict software supply-chain requirements, explicitly managing trusted signers can therefore be valuable.

Should Every .NET Project Enable Strict Signature Validation?

Not necessarily.

The appropriate configuration depends on the application’s security requirements, organizational policies, package ecosystem, and deployment model.

A small personal project and a regulated enterprise application may have very different requirements.

The important thing is to understand what your configuration actually does.

If you enable:

<add key="signatureValidationMode" value="require" />

you are making package signature validation a required part of package installation and restore.

That means certificate management becomes an operational responsibility.

Certificate rotation, signer changes, and package ecosystem changes need to be considered when maintaining the build system.

A Simple Checklist for .NET Developers

If your organization uses NuGet package signing policies, use this checklist:

• ☐ Check whether signatureValidationMode is configured.
• ☐ Check whether trustedSigners is configured.
• ☐ Search CI/CD scripts for dotnet nuget verify.
• ☐ Search for --certificate-fingerprint.
• ☐ Check whether Microsoft is explicitly trusted by certificate.
• ☐ Add Microsoft’s new 2026 certificate fingerprint.
• ☐ Keep existing Microsoft certificates.
• ☐ Test package restore locally.
• ☐ Test package restore in CI.
• ☐ Check container-based builds if applicable.
• ☐ Avoid disabling signature validation just to bypass an error.
• ☐ Document the certificate transition in your build and security documentation.

Frequently Asked Questions

Do all .NET developers need to update their NuGet configuration?

No. Developers who do not use the affected trusted-signer or certificate-fingerprint verification scenarios are generally unaffected by this certificate transition.

Should I remove Microsoft’s old NuGet certificates?

No. Existing certificates should remain trusted when you add the new certificate, because existing packages may still be signed using those certificates.

What is the new Microsoft NuGet certificate fingerprint?

The new SHA-256 fingerprint published by Microsoft is:

9A1B131BEE0605433056A4EA3815478A8E177961A968C6C0027C1093D1FEB630

What error can occur if the new certificate isn’t trusted?

Microsoft states that installing a package signed with the new certificate without updating the trusted-signers configuration can result in NU3034.

Does this change affect unsigned NuGet packages?

This particular Microsoft certificate transition concerns packages signed by Microsoft. Whether unsigned packages are accepted depends on your own NuGet configuration and package-signing policy.

Final Thoughts

NuGet package signing is one of those .NET features that most developers can ignore until it becomes relevant to their build pipeline.

Microsoft’s 2026 author-signing certificate transition is a good example.

For projects using normal NuGet restore without certificate-specific trust policies, there may be nothing to change. For organizations that explicitly trust Microsoft certificates or verify packages using certificate fingerprints, however, the new certificate needs to be accounted for.

The safest approach is not to replace existing certificates blindly and not to disable package verification when a restore fails.

Instead, understand your current trust configuration, add the new Microsoft certificate alongside the existing certificates, and verify the change in both development and CI/CD environments.

As .NET applications become increasingly dependent on external packages, understanding how package signing and trust policies work is becoming part of responsible application maintenance rather than just a security specialist’s concern.

For a production .NET application, a small nuget.config change can have a surprisingly large impact on whether your next build succeeds.