Does NuGet Recover From Expired Feed Credentials During Non-Interactive CI Restores?

Private feeds such as Azure Artifacts authenticate through static credentials in NuGet.config or through credential provider plugins such as the Azure Artifacts Credential Provider, which acquires short-lived Microsoft Entra ID tokens. Least-privilege guidance favors narrow scopes: read-only access for restore, package-scoped API keys for push.

The unresolved point is expiry. NuGet does not refresh static NuGet.config credentials, so an expired entry surfaces as 401 Unauthorized during restore and keeps failing until the file is edited. Credential providers can re-acquire tokens, but how reliably that happens in a non-interactive CI run is unclear, and NuGet's per-session credential cache may keep serving stale failures after the credential is renewed. Behavior also differs across dotnet CLI, NuGet.exe, and Visual Studio.

For an unattended restore-only pipeline, the trade-off is a long-lived narrowly scoped credential that will eventually expire versus a provider-based short-lived token whose silent renewal in headless environments still needs verification against current NuGet clients.

• Does the Azure Artifacts Credential Provider silently re-acquire an expired token during a non-interactive dotnet restore, or does the build fail until fresh credentials are supplied?
• After a credential is renewed, can NuGet's cached session state keep returning 401 until the build process restarts?
• Can restore and push be bound to separate credentials for the same feed URL, or does per-source credential mapping force one identity?