NuGet.org publishers using stored API keys should start planning a rotation now: Neowin reports that Microsoft will cap new NuGet.org API keys at 30 days beginning August 17, 2026, and force keys created before that date to expire on November 1. The operational consequence is straightforward: a release pipeline that has quietly relied on a 365-day secret can begin failing during the fourth quarter unless its maintainers either automate monthly renewal or move to NuGet Trusted Publishing.
The reporting describes the change as a Microsoft supply-chain security measure, but there is an important limitation to the announcement as it currently stands. As of August 4, Microsoft’s public NuGet documentation still describes scoped API keys generally and does not yet show the August 17 or November 1 deadlines; WindowsForum also could not locate a corresponding Microsoft blog post or NuGet.org announcement setting out the rollout. The dates and the new 30-day ceiling therefore rest on Neowin’s report for now, rather than a public first-party notice that administrators can track for implementation details.
That does not make the preparation optional. It means teams should treat the dates as a near-term planning deadline while watching NuGet.org account notices and official documentation for confirmation of how the cutoff will be enforced.
The distinction between the two reported dates matters. August 17 is said to be the date on which newly created keys lose the option for a longer lifetime; November 1 is the more disruptive deadline because it would invalidate every older API key in scope at once.
This is not a simple policy change affecting only future package maintainers. It is a planned revocation event for existing publishing credentials. A classic failure mode will be repositories whose release workflow uses a
Microsoft’s current NuGet documentation says API keys are credential-like secrets that should be protected, refreshed after potential exposure, and scoped to narrowly defined packages and actions. It also says the service provides a warning email ten days before expiry. That is useful for an individual maintainer, but it is not enough for a shared CI/CD credential if the alert reaches an inactive mailbox, a former employee, or an account that no longer owns the release process.
The reported schedule provides only about 11 weeks between the August 17 policy start and the November 1 bulk-expiration date. Organizations with dozens or hundreds of .NET package repositories should not wait for the first warning mail. They should inventory each NuGet.org publishing identity, identify the secret store and workflow consuming its key, and verify who can rotate it without interrupting releases.
The key supplied through that exchange lasts about one hour and can be used for the immediate publishing operation. Microsoft’s documentation says the underlying OIDC token can be exchanged only once for one temporary NuGet key. In practice, that shrinks the useful life of a stolen publishing credential from months to the duration of a single release job.
The shift also changes what a compromise looks like. A conventional NuGet key copied from a repository secret, build log, developer machine, or compromised CI environment can remain usable until someone notices and revokes it. With trusted publishing, an attacker needs access to an approved workflow’s identity context and must satisfy the configured policy at the time of the push. That is a meaningful reduction in standing access, though it does not make a compromised release workflow safe by itself.
Microsoft documents Trusted Publishing for GitHub Actions, while Neowin reports that GitLab is supported as well. The public Microsoft Learn page visible today focuses on the GitHub Actions flow, including the
For GitHub Actions publishers, the migration path is relatively clear:
Nx’s own May 2026 postmortem identifies the affected item as Nx Console version 18.95.0, a Visual Studio Code extension published to the Visual Studio Marketplace and the Open VSX registry. The official Nx security advisory says the malicious build was available for roughly 18 minutes in Microsoft’s Visual Studio Marketplace and approximately 36 minutes on Open VSX. Its telemetry recorded around 6,000 extension activations from VS Code, plus one from Cursor.
The incident began earlier, according to Nx: a malicious dependency obtained through a routine
There was also a separate 2025 compromise involving malicious Nx-related npm packages. That earlier incident included theft of an npm publishing token. Combining that event with the 2026 Nx Console extension compromise makes for a simpler narrative, but it obscures the important common denominator: the attacker did not need to defeat package-registry authentication; they obtained a valid publishing credential.
A 30-day NuGet key would not have stopped the Nx Console compromise during the minutes the attacker used the stolen token. Its value is in limiting the attacker’s post-theft dwell time. Nx’s postmortem estimates that the attacker had access to the stolen token for more than five days before publishing the malicious extension. A credential with months remaining can give an attacker an even longer window to wait, reconnoiter, and strike when a release is least likely to be noticed.
Simply setting a calendar reminder is an unreliable answer. The better interim model for teams that cannot use trusted publishing is to create narrowly scoped keys, track their expiration centrally, rotate them before expiry, update the CI secret through an automated secret-management workflow, and confirm the prior credential is revoked. Reusing one account-wide key with push authority across every package turns one missed rotation into a broad publishing outage and one leak into a broad compromise.
NuGet’s scoped-key model can limit keys to package name patterns and to individual operations such as publishing new versions or unlisting packages. Teams should use that capability even if they retain API keys. A release key for
Manual publishers have a simpler fallback: Neowin says Microsoft recommends publishing through the NuGet.org web interface. That avoids maintaining an automated API credential, but it trades repeatability and auditability for an interactive process. It is reasonable for a small library with occasional releases; it is a poor substitute for a controlled, reproducible release pipeline in an organization that ships frequently.
Next, identify whether the key belongs to a personal NuGet.org account or an organization-controlled identity. The latter is preferable for continuity, but ownership alone will not prevent failure if the key is set to expire and nobody owns the rotation process.
Finally, prioritize Trusted Publishing for repositories that already release through GitHub Actions. The reported 30-day maximum does not mean every project must spend the rest of 2026 rotating secrets every month. It means Microsoft is applying enough pressure that storing a long-lived publishing key should now be considered a transitional arrangement, not normal release engineering.
The November 1 expiry date is the deadline that will matter in production: an unrotated legacy key will not degrade gracefully. It will reject the package push, often at the end of an otherwise successful release job, when the package is ready but the publishing credential is no longer accepted.
That does not make the preparation optional. It means teams should treat the dates as a near-term planning deadline while watching NuGet.org account notices and official documentation for confirmation of how the cutoff will be enforced.
The November 1 date is a forced migration point
The distinction between the two reported dates matters. August 17 is said to be the date on which newly created keys lose the option for a longer lifetime; November 1 is the more disruptive deadline because it would invalidate every older API key in scope at once.This is not a simple policy change affecting only future package maintainers. It is a planned revocation event for existing publishing credentials. A classic failure mode will be repositories whose release workflow uses a
NUGET_API_KEY secret that was created months or years ago, has no owner in the current team, and only runs when someone tags a release. The pipeline may remain green through October, then fail the first time it attempts a dotnet nuget push after the old key expires.Microsoft’s current NuGet documentation says API keys are credential-like secrets that should be protected, refreshed after potential exposure, and scoped to narrowly defined packages and actions. It also says the service provides a warning email ten days before expiry. That is useful for an individual maintainer, but it is not enough for a shared CI/CD credential if the alert reaches an inactive mailbox, a former employee, or an account that no longer owns the release process.
The reported schedule provides only about 11 weeks between the August 17 policy start and the November 1 bulk-expiration date. Organizations with dozens or hundreds of .NET package repositories should not wait for the first warning mail. They should inventory each NuGet.org publishing identity, identify the secret store and workflow consuming its key, and verify who can rotate it without interrupting releases.
Trusted Publishing removes the stored NuGet secret
Microsoft’s strongest answer to recurring API-key rotation is its existing Trusted Publishing system, introduced for NuGet.org in September 2025. Rather than keeping a reusable NuGet credential in GitHub Actions, a configured workflow requests an OpenID Connect, or OIDC, identity token from its CI provider. NuGet.org checks that token against a policy tied to the approved repository and workflow, then issues a temporary API key for the package push.The key supplied through that exchange lasts about one hour and can be used for the immediate publishing operation. Microsoft’s documentation says the underlying OIDC token can be exchanged only once for one temporary NuGet key. In practice, that shrinks the useful life of a stolen publishing credential from months to the duration of a single release job.
The shift also changes what a compromise looks like. A conventional NuGet key copied from a repository secret, build log, developer machine, or compromised CI environment can remain usable until someone notices and revokes it. With trusted publishing, an attacker needs access to an approved workflow’s identity context and must satisfy the configured policy at the time of the push. That is a meaningful reduction in standing access, though it does not make a compromised release workflow safe by itself.
Microsoft documents Trusted Publishing for GitHub Actions, while Neowin reports that GitLab is supported as well. The public Microsoft Learn page visible today focuses on the GitHub Actions flow, including the
NuGet/login action and an id-token: write permission. GitLab users should verify the exact current NuGet.org setup steps before deleting their existing secrets rather than assuming the GitHub example translates directly.For GitHub Actions publishers, the migration path is relatively clear:
- Create a NuGet Trusted Publishing policy for the package owner, repository, and specific workflow file permitted to release packages.
- Add the OIDC permission required for the release job and use the NuGet login action to obtain a temporary key immediately before the package push.
- Remove the long-lived NuGet API key from GitHub Actions secrets only after a successful test release or package publication confirms the policy works.
- Restrict the policy to the release workflow rather than granting every workflow in the repository authority to publish.
The cited Nx incident needs a correction
Neowin’s explanation points to the recent Nx Console compromise as an example of why long-lived credentials create durable risk. The general lesson is valid, but the description needs sharpening because the record does not show an “NX console NPM package” maliciously updated and active for 36 minutes.Nx’s own May 2026 postmortem identifies the affected item as Nx Console version 18.95.0, a Visual Studio Code extension published to the Visual Studio Marketplace and the Open VSX registry. The official Nx security advisory says the malicious build was available for roughly 18 minutes in Microsoft’s Visual Studio Marketplace and approximately 36 minutes on Open VSX. Its telemetry recorded around 6,000 extension activations from VS Code, plus one from Cursor.
The incident began earlier, according to Nx: a malicious dependency obtained through a routine
pnpm install on a contributor’s developer machine stole a GitHub CLI OAuth token. The attacker subsequently used the compromised contributor identity to publish the poisoned extension. Nx says its CLI, official @nx/* npm plugins, and Nx Cloud were not affected by the May Nx Console extension incident.There was also a separate 2025 compromise involving malicious Nx-related npm packages. That earlier incident included theft of an npm publishing token. Combining that event with the 2026 Nx Console extension compromise makes for a simpler narrative, but it obscures the important common denominator: the attacker did not need to defeat package-registry authentication; they obtained a valid publishing credential.
A 30-day NuGet key would not have stopped the Nx Console compromise during the minutes the attacker used the stolen token. Its value is in limiting the attacker’s post-theft dwell time. Nx’s postmortem estimates that the attacker had access to the stolen token for more than five days before publishing the malicious extension. A credential with months remaining can give an attacker an even longer window to wait, reconnoiter, and strike when a release is least likely to be noticed.
Thirty days will expose brittle release engineering
The immediate security benefit comes with a predictable operational cost. Packages released through hands-on workstation workflows will require maintainers to sign in and generate or rotate a fresh key at least monthly. Build systems with secrets provisioned through infrastructure-as-code, enterprise vaults, Azure DevOps variable groups, Jenkins credentials, TeamCity, GitLab CI/CD variables, or self-hosted runners need an owner and a tested renewal process.Simply setting a calendar reminder is an unreliable answer. The better interim model for teams that cannot use trusted publishing is to create narrowly scoped keys, track their expiration centrally, rotate them before expiry, update the CI secret through an automated secret-management workflow, and confirm the prior credential is revoked. Reusing one account-wide key with push authority across every package turns one missed rotation into a broad publishing outage and one leak into a broad compromise.
NuGet’s scoped-key model can limit keys to package name patterns and to individual operations such as publishing new versions or unlisting packages. Teams should use that capability even if they retain API keys. A release key for
Contoso.Logging.* should not be able to push an unrelated package owned by the same organization, and a publisher that never unlists releases should not hold unlisting permission.Manual publishers have a simpler fallback: Neowin says Microsoft recommends publishing through the NuGet.org web interface. That avoids maintaining an automated API credential, but it trades repeatability and auditability for an interactive process. It is reasonable for a small library with occasional releases; it is a poor substitute for a controlled, reproducible release pipeline in an organization that ships frequently.
What .NET teams should do before August 17
Teams should first find every occurrence of a NuGet.org publishing key. Search CI/CD secret inventories, repository configuration, local build scripts,NuGet.Config files, password managers, deployment documentation, and runbooks. Do not assume that a key named NUGET_API_KEY is the only one; older workflows may use generic names such as API_KEY, PACKAGE_TOKEN, or a credential injected by a release platform.Next, identify whether the key belongs to a personal NuGet.org account or an organization-controlled identity. The latter is preferable for continuity, but ownership alone will not prevent failure if the key is set to expire and nobody owns the rotation process.
Finally, prioritize Trusted Publishing for repositories that already release through GitHub Actions. The reported 30-day maximum does not mean every project must spend the rest of 2026 rotating secrets every month. It means Microsoft is applying enough pressure that storing a long-lived publishing key should now be considered a transitional arrangement, not normal release engineering.
The November 1 expiry date is the deadline that will matter in production: an unrotated legacy key will not degrade gracefully. It will reject the package push, often at the end of an otherwise successful release job, when the package is ready but the publishing credential is no longer accepted.
References
- Primary source: neowin.net
Published: 2026-08-04T03:22:01+00:00
Loading…
www.neowin.net - Related coverage: learn.microsoft.com
Loading…
learn.microsoft.com - Related coverage: devblogs.microsoft.com
Loading…
devblogs.microsoft.com - Related coverage: devblogs.microsoft.com
Loading…
devblogs.microsoft.com - Related coverage: github.com
Loading…
github.com - Related coverage: learn.microsoft.com
Loading…
learn.microsoft.com - Related coverage: putridparrot.com
Loading…
putridparrot.com - Related coverage: nuget.org
Loading…
www.nuget.org - Related coverage: github.com
Loading…
github.com - Related coverage: feed.nuget.org
Loading…
feed.nuget.org - Related coverage: nuget.org
Loading…
www.nuget.org - Related coverage: github.blog
Loading…
github.blog - Related coverage: docs.gitguardian.com
Loading…
docs.gitguardian.com - Related coverage: nvd.nist.gov
Loading…
nvd.nist.gov