nuget.org Accounts, Organizations and API Keys

This section documents MSBuild 18.9, the .NET SDK 10.0.402 (with its dotnet CLI) and NuGet 7.9, as published in the MSBuild, .NET and NuGet documentation on learn.microsoft.com, which is the reference these pages are written and verified against. Material about .NET 11 / NuGet 8.0 is still in preview and is always flagged as such — never presented as baseline.

This content was generated with the assistance of AI and should be verified against the official documentation before being relied on in production.

The C# Reference bibliography lists the reference material consulted while preparing these pages.

Pushing to nuget.org needs an account that owns (or will own) the package ID and a credential proving it: an API key or, since September 2025, a short-lived key obtained through Trusted Publishing. This page covers accounts, organizations and API keys, including the 2026 change to key lifetimes. Nothing here was run against nuget.org; the commands use placeholder keys, and the environment-variable form was run against the local BaGetter feed with .NET SDK 10.0.402 (NuGet 7.9.0).

An API key is a password for publishing in your name: anyone who has it can push new versions of your packages. Never commit it, put it in a nuget.config in a repository, pass it where CI prints commands, or paste it into an issue. Store it as a CI secret, scope it to the packages and operations it needs, and delete it the moment it may have leaked.

Accounts and organizations

An individual account is a person’s identity on nuget.org; it signs in with a personal Microsoft account or a work account (Microsoft Entra ID), with two-factor authentication required. An organization account has individual accounts as members and owns packages on behalf of a company or project — to consumers both just appear as package owners. Organizations and users share one namespace, so an organization name (and its e-mail address) must be unique.

  • Add an organization — Manage Organizations > Add new organization; the creator becomes its administrator.

  • Transform an account into an organization — for a team that has been sharing one user account; another user becomes the administrator. Irreversible.

  • Members are added by user name (not e-mail) as collaborators (manage the organization’s packages: push, update, unlist) or administrators (also metadata, members and co-ownership requests).

  • Transfer packages — add the organization as a co-owner, then remove yourself; an administrator’s request is accepted immediately, a collaborator’s needs an administrator to accept.

Source: nuget.org overview: Accounts, Individual accounts vs organization accounts, Add a new individual account, Delete a nuget.org account, Organizations: Adding a new organization, Transform an existing account, Managing organization members, Transferring packages to an organization.

Scoped API keys

An API key is created on nuget.org under API Keys > Create, and is scoped along three axes:

  • Operations — Push new packages and package versions, Push only new package versions, or Unlist.

  • Packages — a list of existing packages, or a glob pattern such as ledgerline.*, which also covers new packages that match it later.

  • Package owner — the user or one organization; a key works only for packages of that owner.

The key is shown once, behind a Copy button; leaving the page loses it. Edit changes the package list (not the scopes), Refresh issues a new key with the same settings and invalidates the old one, Delete removes it for good. nuget.org warns on the page when a key has expired and e-mails the owner ten days before.

A sensible set for Ledgerline: one key for CI with Push only new package versions on Ledgerline and Ledgerline.*, owned by the organization; a separate, rarely used key with Push new packages for the first push of a new ID.

Source: nuget.org overview: API keys, Scoped API keys: Acquire an API key, Create scoped API keys, Use glob patterns, Obtain API keys securely, Edit existing API keys, Refresh or delete existing API keys, Organizations: Using API keys.

Key lifetimes since 2026

The NuGet team announced on 2026-08-03:

  • Since 2026-08-17, new API keys last at most 30 days; the 365-day option is gone.

  • Every key created before 2026-08-17 expires on 2026-11-01.

  • The duration "may be reduced further in the future"; the recommended path is Trusted Publishing.

The documentation has not caught up: Scoped API keys (last revised 2019) still shows a key "valid for 365 days" and says the old legacy account key "continues to work …​ as long as you want it to work" and "never expires" (unless unused for 365 days). Both statements are outdated. A publishing workflow that still uses a stored key must therefore be able to rotate it every month — or move to Trusted Publishing, where nuget.org issues a key valid for one hour per run and nothing is stored.

Source: Strengthening NuGet Supply Chain Security: Reducing API Key Lifetime, nuget.org overview: Trusted Publishing.

Using and storing a key

The key goes to dotnet nuget push with -k/--api-key, or — since NuGet 7.6 (SDK 10.0.300) — from the NUGET_API_KEY environment variable (and NUGET_SYMBOL_API_KEY for symbols), so it never appears on a command line. The option wins over the variable, and the variable over a key stored in nuget.config. Against BaGetter, whose key was set when the container was started:

NUGET_API_KEY="$BAGETTER_API_KEY" dotnet nuget push artifacts/feed/Ledgerline.Money.1.0.0.nupkg -s ledgerline-bagetter
dotnet nuget push artifacts/feed/Ledgerline.Money.1.5.0.nupkg -s ledgerline-bagetter    # no key at all
Pushing Ledgerline.Money.1.0.0.nupkg to 'http://localhost:5555/api/v2/package'...
  PUT http://localhost:5555/api/v2/package/
  Created http://localhost:5555/api/v2/package/ 83ms
Your package was pushed.

warn : No API Key was provided and no API Key could be found for 'http://localhost:5555/api/v2/package'. To save an API Key for a source use the 'setApiKey' command.
Pushing Ledgerline.Money.1.5.0.nupkg to 'http://localhost:5555/api/v2/package'...
  PUT http://localhost:5555/api/v2/package/
  Unauthorized http://localhost:5555/api/v2/package/ 62ms
error: Response status code does not indicate success: 401 (Unauthorized).

In CI the key is a secret mapped to that variable (not run here):

- name: Push to nuget.org
  run: dotnet nuget push "artifacts/*.nupkg" -s https://api.nuget.org/v3/index.json --skip-duplicate
  env:
    NUGET_API_KEY: ${{ secrets.NUGET_API_KEY }}

nuget setapikey (nuget.exe) stores a key encrypted in the user-level nuget.config under <apikeys>; the dotnet CLI has no equivalent command. A key stored there is per machine and per user — fine on a workstation, wrong in a repository. API keys are not used to authenticate to private feeds for restore; those use credentials (Authenticated Feeds and Credential Providers).

Source: NuGet 7.6 release notes, nuget setapikey, nuget.config: apikeys, dotnet nuget push: Options.

ID prefixes

An account or organization can reserve an ID prefix (Ledgerline.*): only its packages may then use the prefix, and they show a verified checkmark. Reservation and its criteria are on Publishing to nuget.org.

Source: nuget.org overview: ID prefixes.

Common mistakes

  • One unscoped key shared by everyone — one leak exposes every package.

  • A long-lived key in a secret store without a rotation plan — since 2026-08-17 it stops working within 30 days.

  • Pushing with an individual’s key for organization packages — the key’s owner must own the package.

  • --api-key on a logged command line — use NUGET_API_KEY or a masked secret.

  • Transforming the only admin account into an organization without a second admin — the change can’t be undone.

References