NuGet API Keys Expire in 30 Days: Fix Your Pipeline Now

Microsoft has eliminated the 365-day NuGet API key. Starting today, new keys cap at 30 days. If your team created a key before August 17, 2026, it works until November 1 — then it stops. That CI/CD pipeline quietly running on a year-old NUGET_API_KEY secret? It will break in Q4 unless you act now.

Why Microsoft Pulled the Trigger Today

This change has a direct cause: the Nx Console supply chain attack in May 2026. An attacker hijacked a legitimate contributor’s credentials — stolen earlier via the TanStack compromise — published a malicious Nx Console v18.95.0, and within 36 minutes it had activated 6,000 times, harvesting GitHub tokens, AWS credentials, Kubernetes configs, and 1Password vaults from developer machines worldwide. CVE-2026-48027 is now on CISA’s Known Exploited Vulnerabilities catalog.

The lesson is uncomfortable: a stolen API key with a year of validity gives attackers a year-long attack window. NuGet is the last major package registry to close this gap — PyPI, npm, and RubyGems already moved to short-lived credentials. As Microsoft put it in the official announcement: “Long-lived credentials significantly increase the impact of accidental disclosure.”

What Actually Changed

Two deadlines, one action:

• August 17, 2026 (today): New NuGet API keys are capped at 30 days. The 365-day and 730-day options are gone.
• November 1, 2026: All existing keys created before today expire automatically, regardless of their original expiry date.

If you publish .NET packages — whether to a public NuGet feed or an internal one — audit your secrets now. Check GitHub repository secrets, organization-level secrets, and any CI/CD credential stores your team uses.

Two Paths Forward

You have two options, and one is clearly better.

Option 1: Rotate Monthly (the stopgap)

Generate a new 30-day key, update your stored secret, repeat every month. This works but adds toil and human error risk. A stolen key is still a valid key for up to 30 days. It’s the “change your password more often” solution to what is fundamentally an authentication architecture problem.

Option 2: NuGet Trusted Publishing (the real fix)

Trusted Publishing replaces stored credentials entirely. Your GitHub Actions workflow proves its identity using an OIDC token — cryptographically signed by GitHub, verified by NuGet.org, exchanged for a temporary key that expires in one hour and works once. No secret to steal. No rotation to remember. The official Trusted Publishing docs walk through the full setup.

Migrating to Trusted Publishing: 4 Steps

Step 1: On NuGet.org, go to your username → Trusted Publishing → Add a new policy. Specify your GitHub repository owner, repository name, and the workflow filename (just ci.yml, not .github/workflows/ci.yml — the full path breaks it).

Steps 2–4: Update your GitHub Actions workflow:

jobs:
  publish:
    permissions:
      contents: read
      id-token: write  # required: enables OIDC token issuance
    steps:
      - name: Log in to NuGet.org
        id: nuget-login
        uses: NuGet/login@v1
        with:
          user: ${{ secrets.NUGET_USER }}

      - name: Push package
        run: >-
          dotnet nuget push "./artifacts/*.nupkg"
          --source https://api.nuget.org/v3/index.json
          --api-key "${{ steps.nuget-login.outputs.nuget-api-key }}"

Then delete the old API key from NuGet.org and remove it from your repository secrets. Don’t leave both in place — you’ll forget which one the pipeline is actually using. Andrew Lock’s migration guide has a thorough walkthrough if you want additional context.

Gotchas That Will Bite You

• Token timing matters: The temporary key is valid for ~1 hour. Request it immediately before the push step, not at the start of the job.
• Rename = broken policy: If you rename your repo or workflow file, update the policy on NuGet.org or publishing stops.
• Private repos start partially active: The policy enters a 7-day provisional period until the first successful publish.
• Local publishing still needs a key: Trusted Publishing is CI/CD only. For local dotnet nuget push, you still need a conventional API key — keep it short-lived.

The Bottom Line

The November 1 deadline for existing keys is real. If you run any automated NuGet publishing, audit now — not when a Q4 release breaks at 2 AM. Trusted Publishing is the better solution: more secure, less toil, already proven at scale across the package ecosystem. Start with your highest-traffic publishing pipeline. The workflow change takes under 30 minutes.