By ByteBot
Microsoft is cutting NuGet API key lifetimes from 365 days to 30. The new cap takes effect August 17 for any key you create on NuGet.org. Keys you already have expire November 1 — that is the real deadline. If your CI/CD pipeline auto-publishes .NET packages and you have not looked at this yet, you are closer to the edge than you think.
What Changed
Starting August 17, 2026, new NuGet.org API keys have a maximum lifetime of 30 days. Keys created before that date remain valid under the old limit until November 1, 2026, at which point they expire regardless. After November 1, every team publishing to NuGet.org is on the 30-day clock — or on NuGet Trusted Publishing, which is the smarter option.
There is no opt-out and no grace extension. Microsoft was direct about this in the announcement on the .NET blog: this is a supply chain security measure, and the timeline is firm.
Why Microsoft Did This
The immediate trigger was the Nx Console supply chain breach in May 2026. A stolen publishing credential was used to push a malicious version of the popular VS Code extension. That version was live for under 40 minutes and was still activated approximately 6,000 times before removal. The downstream fallout was worse: GitHub’s CISO confirmed that roughly 3,800 internal repositories were exfiltrated.
The lesson is blunt: long-lived credentials are liabilities. A 365-day API key that gets exposed has a 365-day blast radius. A 30-day key cuts that to a month at most. It does not eliminate the risk, but it dramatically reduces the damage window.
The broader data backs this up. NuGet malware dropped 60 percent after the registry added mandatory two-factor authentication and Trusted Publishing. PyPI saw a 43 percent decline after doing the same. Short-lived credentials and OIDC-based publishing are demonstrably effective. This change is following a proven playbook that is already delivering measurable results across package ecosystems.
Two Paths Forward
Microsoft offers two options. One of them is clearly the right long-term answer.
Option 1: NuGet Trusted Publishing (Recommended)
Trusted Publishing uses OpenID Connect (OIDC) to authenticate your CI/CD pipeline directly with NuGet.org. There is no long-lived secret to store, rotate, or protect. Your pipeline proves its identity through a cryptographically signed token from GitHub or GitLab, and NuGet.org issues a temporary key that expires in about an hour.
This is currently supported for GitHub Actions and GitLab CI. Azure DevOps support is on the roadmap but not yet available.
Setup for GitHub Actions is straightforward. On NuGet.org, go to your account and add a Trusted Publisher policy — specify your repository and workflow file name. In your workflow, add the id-token: write permission and use the NuGet/login action to handle the token exchange:
permissions:
id-token: write
contents: read
steps:
- uses: actions/checkout@v4
- uses: NuGet/login@v3
- run: dotnet nuget push "*.nupkg" --source https://api.nuget.org/v3/index.jsonAndrew Lock has a detailed walkthrough on easily publishing NuGet packages from GitHub Actions with Trusted Publishing that covers the full setup. The official NuGet Trusted Publishing documentation covers the NuGet.org configuration side.
Option 2: Rotate API Keys on a 30-Day Schedule
If you are on Azure DevOps, Jenkins, or another CI system where Trusted Publishing is not yet available, key rotation is your path for now.
The rotation process is not complicated, but it is operationally repetitive: generate a new key before the current one expires, update every workflow and secret store that uses the old key, verify publishing works with the new key, then revoke the old one. Overlap the validity periods — do not wait until expiration day.
A few hard rules for NuGet API key hygiene: scope each key to specific packages only, store keys exclusively in secrets managers such as GitHub Secrets or Azure Key Vault, and never let a key touch a config file or a log. If a key is exposed, revoke it immediately.
Who Needs to Act Before November 1
Any team or maintainer that publishes packages to NuGet.org with an automated pipeline is affected. That includes internal enterprise teams using NuGet.org as their package registry, open-source .NET library maintainers, and any developer who set up a CI/CD job with a long-lived API key and has not revisited it since.
If you publish manually through the NuGet.org web interface, you will still need to generate a fresh key every 30 days going forward — but you are not at risk of a broken pipeline on November 1.
The Verdict
Migrate to NuGet Trusted Publishing if you can. The operational overhead of rotating API keys every 30 days is exactly the kind of maintenance burden that teams defer until it breaks something. Trusted Publishing eliminates the problem entirely — no secrets, no rotation, no emergency tickets when a key expires mid-release.
If you are on Azure DevOps and cannot switch to Trusted Publishing yet, automate your key rotation now. Manual rotation on a 30-day cycle across multiple packages is a production incident waiting to happen.
The November 1 deadline is not negotiable. Check your NuGet.org account and your CI/CD pipelines today. The Nx Console postmortem is worth 10 minutes of your time if you still think supply chain attacks only happen to other teams. The Sonatype supply chain report has the broader data that shows why every package registry is moving this direction.
