Azure Artifacts Credential Provider: token acquisition for dotnet and NuGet feeds

The problem is a token, and the component lives outside your build script

The Azure Artifacts Credential Provider automates the acquisition of credentials for an Azure Artifacts feed. Put plainly, the problem it solves is authentication: when a package restore asks a private Azure Artifacts feed for a package, something has to present a valid token, and in a non-interactive environment that something is usually a credential provider.

Its most common use is as a component inside package manager tooling, and the documentation names the credential providers for dotnet, npm, Maven and pip among them. Used directly, it integrates with MSBuild and NuGet.exe. Windows, Mac and Linux are all supported.

The value of the approach is that the token is acquired and securely stored on behalf of the NuGet client you are using, and this happens any time you restore or install packages from an Azure Artifacts feed. For a developer at a workstation that means an interactive sign-in rather than a credential in a config file. For a build agent it means the provider can be the thing that handles the flow, instead of your pipeline reaching for a secret that someone pasted into a settings file.

The audience is therefore specific: teams that publish and consume packages through Azure Artifacts, and the engineers whose pipelines restore from those feeds. If your packages come from nuget.org or a self-hosted feed with its own auth scheme, this component has nothing to do for you.

Two install shapes: a dotnet global tool and a NuGet plugin

The install path depends on which client you drive, and the repository is explicit about the difference. For dotnet, the tool installer included with dotnet acquires the provider regardless of operating system.

dotnet tool install --global  Microsoft.Artifacts.CredentialProvider.NuGet.Tool

For nuget.exe or MSBuild, the provider is a plugin that goes on NuGet's plugin search path, and the NuGet documentation for cross platform authentication plugins covers both manual and scripted instructions. The netcore variant serves dotnet, and the netfx variant is the one nuget.exe and MSBuild need, so both may be required if you use both clients.

There is a wrinkle in the dotnet install worth planning for. If your project is already configured through a nuget.config to use an Azure Artifacts feed exclusively, you may need to run the command from a folder outside your project, because the tool installer resolves its own package source through the same config. The alternative is to name the public feed explicitly.

dotnet tool install --global  Microsoft.Artifacts.CredentialProvider.NuGet.Tool --source https://api.nuget.org/v3/index.json

For container images and other repeatable installs, pinning is the sensible move.

dotnet tool install --global  Microsoft.Artifacts.CredentialProvider.NuGet.Tool --version 2.* --source https://api.nuget.org/v3/index.json

Most users need no further steps, although some container and manual dotnet install scenarios require adding the dotnet tools directory to PATH, for example with ENV PATH="$PATH:/root/.dotnet/tools". The repository ships a sample Dockerfile for that case.

Version floors that decide whether your client can use it

The prerequisites are specific numbers, and they are the first thing to check because they decide which install route you have.

For dotnet, tool installation requires the .NET SDK version 9.0.200 or later. If you need to use .NET 8, the documentation points to the plugin method used for NuGet instead, which is a workaround rather than an equal path. Visual Studio users may already have a suitable SDK included, and Visual Studio Code users may already have it through the C# Dev Kit extension.

For MSBuild on Windows, you need Visual Studio 15.9-preview1 or later to get MSBuild version 15.8.166.59604 or later, or you can install the Build Tools for Visual Studio. MSBuild also ships as part of the .NET Core SDK, which is often the simpler route on a build agent.

For nuget.exe, version 4.8.0.5385 or later is required, and the recommended version is 5.5.x or later because of bug fixes related to cancellations and timeouts. That last point matters on a build agent, where a timeout behaviour that is merely annoying on a workstation turns into a flaky pipeline.

Linux self-contained installs have their own requirement: they may need extra native dependencies such as libicu and libssl, and the documentation links to the .NET 8 Linux package list and the self-contained applications guide for the full dependency set.

Windows manual and script installs, and the netcore and netfx split

On Windows there is a scripted route and a manual one, and the script is more capable than it first looks. The PowerShell helper script at helpers/installcredprovider.ps1 requires PowerShell 5.1 or later.

The documented invocations cover several combinations.

iex "& { $(irm https://aka.ms/install-artifacts-credprovider.ps1) }"

That installs the netcore bits. The -InstallNet6 and -InstallNet8 flags install specific .NET versions of the bits, and -AddNetfx adds the .NET Framework variant, which is the one nuget.exe needs. A further -AddNetFx48 flag covers .NET Framework 4.8.1 support. Installing both netfx and netcore in one pass is the safe default on a Windows machine that runs both clients.

The manual path is short. Download the latest Microsoft.Net8.NuGet.CredentialProvider.zip from the releases page, unzip it, and copy the netcore directory, plus netfx if you use nuget.exe, into the plugins directory under the user profile.

iex "& { $(irm https://aka.ms/install-artifacts-credprovider.ps1) } -AddNetfx"

NuGet's plugin discovery rules also allow installing the provider somewhere else and pointing at it with the NUGET_PLUGIN_PATHS environment variable, set to the CredentialProvider.Microsoft.exe path. The documentation does not recommend that route if you use both nuget.exe and dotnet, and it links the NuGet issue explaining why.

Token caching and the environment surface the documentation only gestures at

The provider is described as acquiring and securely storing a token on behalf of the client, and the project page has a section titled Session Token Cache Locations plus a section on environment variables. The specific cache paths and the exact variable names are worth reading in the project's own documentation before you rely on them.

That matters operationally. A cached session token on a shared build agent is the difference between a restore that works unattended and one that stops working when an interactive session expires, and knowing where the cache lives tells you whether your agent image needs to persist that directory between runs. If the cache is inside the container's writable layer and your pipeline does not mount it, you get a fresh interactive flow on every build.

The same logic applies to the other documented sections. The project page carries notes for the 1.0.0 release and an upcoming 2.0.0 version, which suggests the behaviour around versions and configuration changed between those lines, and the current tags confirm that 2.0.x is the live series.

For the other package ecosystems the guidance is different and simpler. If you use one of the credential provider tools for Maven, pip or npm, follow the guidance for that tool, and a separate installation of the Azure Artifacts Credential Provider may not be required at all.

MIT licensed, 2.0.x releases through September 2026

The licence field on the repository says MIT, which is a short permissive grant that lets you use, modify and redistribute the component inside a build pipeline without imposing source disclosure on your own tooling. Reading the LICENSE file for the exact terms is still the sensible step, and none of this is legal advice.

On maintenance, the numbers are recent. The last push was on 2026-09-29, the repository is not archived, and the release line is active: 2.0.4-alpha on 2026-07-23, 2.0.4 on 2026-08-03, and 2.0.5 on 2026-09-28. A patch series in the 2.0 range with an alpha in the middle of it reads like normal servicing rather than a redesign, and the presence of a SECURITY.md file, a .vsts-ci.yml pipeline and a devcontainer configuration in the repository shows the build and test infrastructure is part of the project rather than an afterthought.

The repository layout reinforces that. There is a solution file, a CredentialProvider.Microsoft.Tests project for the test suite, a CredentialProvider.Microsoft.VSIX project for the Visual Studio extension packaging, a build directory, a helpers directory with the PowerShell script, a samples directory with the Dockerfile and devcontainer sample, and a src directory. The separate VSIX project is worth noting, because it means the provider can reach Visual Studio users without going through the nuget.exe plugin path at all.

The upstream build is published to a Microsoft Azure DevOps pipeline rather than to GitHub Actions, and the repository carries a .vsts-pr.yml file, so the release automation lives in the same Azure estate as the product it serves.

Editorial conclusion

Adopt the Azure Artifacts Credential Provider when your build restores packages from an Azure Artifacts feed and you want interactive sign-in and token caching instead of a personal access token pasted into a nuget.config. Do not adopt it if your feeds live elsewhere, since its entire job is acquiring Azure Artifacts credentials, and note that the tool targets .NET 9.0.200 or later while nuget.exe users must stay on the plugin path with netfx binaries. Before rolling it into a build, check the version floor of your dotnet SDK or your nuget.exe, confirm the dotnet tools directory is on PATH inside your container image, and decide which release to pin given that 2.0.x tags shipped in July, August and September 2026.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. microsoft/artifacts-credprovider on GitHub
4. README
5. Releases