They are three separate states. Deprecated is a publisher notice that a package or version should not be used. Unlisted hides a package from search but leaves it installable. Vulnerable means a published advisory affects a version. A package can be any combination, so check each one separately.
Definitions
| State | Set by | What it means for you |
|---|---|---|
| Deprecated | The package publisher | Existing consumers can find out and see a reason and a suggested alternative |
| Unlisted | The package publisher | Hidden from search, still restorable if you reference it |
| Vulnerable | An advisory, matched by NuGet Audit | A known security issue affects that package version |
Microsoft's documentation is explicit that deprecating does not unlist, and a publisher may do both.
Deprecation reasons
nuget.org lets a publisher choose a reason: Legacy, when the package is no longer maintained, has critical bugs, or Other. They can name an alternate package and write a custom message. Note that the custom message appears on nuget.org only. Clients such as the dotnet CLI and the NuGet Package Manager do not show it, so the reason and the alternate are what you see locally.
How to find each state
dotnet list package --deprecated
dotnet list package --vulnerable --include-transitive
dotnet list package --outdated
From the .NET 10 SDK the same commands exist in noun first form, for example dotnet package list. The vulnerable option cannot be combined with deprecated or outdated in one run, so run them separately. Vulnerable output depends on your audit sources.
Unlisted status is harder to see from the command line. Floating version resolution does not take listing into account, so an unlisted package can still be picked up. Check the package page on nuget.org when a dependency looks abandoned.
What to do with each result
- Vulnerable: update to a fixed version, or follow your fix ladder if the vulnerability is transitive.
- Deprecated for Legacy: plan a move to the suggested alternate, and set a date.
- Deprecated for critical bugs: treat it like a vulnerability and move quickly.
- Unlisted: ask why. Maintainers often unlist after finding a problem, and Microsoft advises avoiding a package that is both deprecated and unlisted.
- No fix and no alternate: read the advisory for mitigating factors, open an issue with the maintainer, or consider contributing a fix.
A caution about queries
Package source mapping does not apply to the deprecated check. That command asks every configured source for deprecation metadata, sending your package IDs to each one, including public feeds. Keep that in mind if you have private package names.
Making it routine
Run all three checks in a scheduled pipeline, store the JSON output with the format option, and review the changes weekly. That gives you a trend rather than a one time list.
Try it yourself
Click through it at your own pace, or open it full screen. Notice how findings are grouped by status, which is the same sorting you need for these three states.
Safeguard's dependency scanning surfaces known vulnerabilities across your projects, and a free scan is a way to see them without setup.
Quick check
If a package is deprecated, will restore fail?
No. Deprecation is informational. The package still restores until you remove it.
Does an unlisted package disappear from my project?
No. Unlisting hides it from search. Existing references still restore.
Sources
- Deprecating packages on nuget.org, Microsoft Learn
- dotnet package list command, Microsoft Learn
- NuGet package dependency resolution, Microsoft Learn
- Best practices for a secure software supply chain, Microsoft Learn
Last reviewed: 19 October 2026.
