NuGet's signing story gets less public attention than npm or PyPI, partly because .NET supply chain discourse happens on different channels and partly because Microsoft has been quietly enforcing signing policies for years. In 2026 the NuGet ecosystem is arguably more uniformly signed than most of its peers, and the remaining gaps are subtler than they look at first glance. If you ship .NET and you have not revisited your NuGet posture recently, the assumptions you are carrying from 2022 are probably out of date.
What exactly does NuGet sign, and how is it different from other ecosystems?
NuGet has two distinct signature types. An author signature is attached by the package author using a code-signing certificate they own, and it attests that the package came from that author. A repository signature is attached by the registry operator (nuget.org, in most cases) when the package is accepted for publication, and it attests that the registry saw the package in its current form. The combination gives you two independent trust anchors, which is stronger than the single-signature model most other ecosystems use.
The practical consequence is that a NuGet package on the public feed is typically double-signed: once by the author with their own certificate, and once by nuget.org with Microsoft's certificate. Verification can require either or both, depending on your policy. This is actually closer to the direction Sigstore and attestation standards are moving than to the GPG-based models those standards are replacing; NuGet got there first, in a slightly different shape.
Why does Microsoft enforce stricter signing than most registries?
Because the .NET ecosystem is largely enterprise, and enterprise customers expect authenticity guarantees that consumer-facing ecosystems have historically handwaved. nuget.org has required repository signing on all published packages for years, and the push toward requiring author signatures on popular packages has been gradual but persistent. Microsoft's internal .NET libraries have required author signatures with EV certificates for longer than most OSS ecosystems have had any signing at all.
The downside of this maturity is that the tooling and certificate-authority requirements are more demanding. Getting a code-signing certificate for NuGet author signing is a real process, with identity verification and ongoing certificate management. For a casual open-source maintainer this is a friction point, and a long tail of smaller NuGet packages ship without author signatures simply because the setup is too heavy. This is one of the reasons the 2025 experimental support for OIDC-based signing on NuGet matters: it offers a path to the same guarantees without the certificate management overhead.
What is the state of OIDC-based trusted publishing for NuGet?
Experimental and gaining traction through 2025 and 2026. NuGet.org has been piloting a trusted-publisher model analogous to PyPI's, where a GitHub Actions workflow can claim publish rights for a package ID via OIDC without a long-lived API key. The feature is not as mature as PyPI's equivalent, and enterprise customers publishing from Azure DevOps have a parallel story that is further along.
If you publish internal NuGet packages from Azure DevOps pipelines, the OIDC-to-Entra-ID flow is probably the cleanest configuration available today, and it integrates more naturally with existing identity controls than any of the GitHub-specific patterns. If you publish to the public nuget.org from GitHub Actions, watch for the feature to graduate out of preview; when it does, migrating off long-lived NuGet API keys should be one of the cheaper supply chain wins available to you.
How should consumers verify NuGet signatures in 2026?
The dotnet CLI and NuGet clients have supported signature verification for years, but the default configuration is permissive. The trustedSigners section in nuget.config is the main policy primitive, and it lets you require specific signatures from specific authors or repositories. Most teams have never touched it.
The pattern I recommend is a baseline policy that requires the nuget.org repository signature on every package, plus an allowlist of trusted author certificates for the critical dependencies. Running dotnet nuget verify in CI as part of the build will surface drift from this policy, and the output is readable enough that the first few failures usually just need someone to decide whether a new author certificate is legitimate before adding it to the allowlist.
What about private feeds, Azure Artifacts, and GitHub Packages for NuGet?
Azure Artifacts has mature signing support and integrates cleanly with Entra ID for authentication. GitHub Packages supports NuGet but with a thinner signature story than Azure Artifacts. ProGet and similar third-party feeds vary widely; some preserve upstream signatures cleanly, others strip them during proxy operations in ways that break downstream verification.
If you operate a private NuGet feed, the important audit question is whether your feed passes through the repository signatures from nuget.org untouched, or whether it re-signs proxied packages with its own key. Both are defensible, but the implications for your policy are different. Passing through means your consumers are verifying against Microsoft's trust chain; re-signing means they are verifying against yours. I generally prefer pass-through with a supplemental internal signature, so consumers see both chains of custody.
Are there known attacks specific to the NuGet signing model?
The most interesting failure modes are around certificate revocation and timestamp verification. NuGet author signatures include trusted timestamps from RFC 3161 timestamping authorities, so a signature remains verifiable even after the signing certificate expires, provided the timestamp was applied while the certificate was valid. This is a nice property that keeps legitimate old packages usable. It also means that a compromise of a timestamping authority could, in principle, allow a backdated signature to appear valid. In practice this has not happened, but it is the kind of risk worth understanding if you are building a verification policy for a long-lived artifact set.
Certificate revocation is the more common operational issue. If an author's certificate is revoked, previously-published packages signed with that certificate become suspect. The verification tools handle this correctly but the signal can be noisy; a revocation might indicate a compromise or it might just indicate that the CA updated its practices. Treat revocation signals as a trigger for review rather than an automatic block, and have a documented escalation path.
Do SBOMs and attestations add anything on top of NuGet's native signing?
Yes, for two specific reasons. First, NuGet's signatures attest to the package contents but not to the build provenance; knowing that a package came from a given author is different from knowing which commit and workflow produced it. Attestations, whether via Sigstore or Microsoft's internal equivalent, give you the build-provenance layer on top. Second, SBOMs give you dependency-graph visibility across the .NET ecosystem in a way that signature verification alone does not. For a regulated environment, running both is the right answer; treating NuGet signatures as sufficient leaves you blind to build-time compromises that would not affect the final signature.
How Safeguard.sh Helps
Safeguard.sh audits your NuGet feed configurations for permissive trustedSigners defaults, verifies both author and repository signatures across your dependency graph, and flags packages whose signing posture has regressed between versions. We track the emerging OIDC-based publishing flows and help you migrate high-value packages off long-lived API keys. The goal is to give .NET teams a supply chain posture that matches the ecosystem's actual maturity, without requiring every developer to become a NuGet signing expert.