The pnpm setting trustPolicy: no-downgrade makes an install fail when a package version carries weaker trust evidence than an earlier release of the same package. If a package used to be published by a trusted publisher and a new version has only provenance or nothing, pnpm refuses to install it.
What the setting does
pnpm added trustPolicy in v10.21.0. The default is off. With no-downgrade, pnpm compares the trust evidence of the version you are about to install with every earlier version of that package. If any earlier release had stronger evidence, the install fails.
The pnpm docs give the example directly: a package was previously published by a trusted publisher, but the new version has only provenance or no trust evidence. That pattern is what a stolen maintainer token tends to look like, because an attacker publishing from a laptop cannot reproduce the CI identity that earlier releases had.
Two details matter:
- The check is based on publish date, not on semver. A patch release on an old line still counts as "later" if it was published later.
- Since v10.24.0, prerelease versions are ignored when judging trust for a stable install, so a trusted prerelease cannot block a stable release that lacks trust evidence.
What it does not do
It does not prove a package is safe. It detects a drop in how the package was published. A package that never had provenance has nothing to downgrade from, so the policy stays quiet. A malicious release published through the same trusted pipeline passes too.
Treat it as one signal alongside a release age delay, lockfile review and script controls, not as a verdict. Our post on what package provenance proves and what it does not covers the same limit from the publisher side.
Adopting it without breaking the build
Older versions of many packages were published before provenance existed. pnpm gives you three tools for that.
| Setting | Purpose | Added in |
|---|---|---|
| trustPolicyExclude | List package selectors, including specific versions, that are allowed to fail the check | v10.22.0 |
| trustPolicyIgnoreAfter | Skip the check for versions published more than a set number of minutes ago | v10.27.0 |
| trustPolicyExcludePrune | Remove exclusion entries the new lockfile no longer resolves | v12.4.0 |
A practical rollout:
- Add trustPolicy: no-downgrade to pnpm-workspace.yaml on a branch.
- Run an install and note which packages fail.
- For each failure, decide whether the drop is a real signal. Look at the package's recent releases and who published them.
- Add reviewed exceptions to trustPolicyExclude with a comment saying why.
- Optionally set trustPolicyIgnoreAfter so old releases stop needing manual entries.
# pnpm-workspace.yaml
trustPolicy: no-downgrade
trustPolicyExclude:
- 'webpack@4.47.0 || 5.102.1'
Registries that cannot date releases
The check reads publish dates. Some private registries and mirrors omit the time field. pnpm v11.23.0 and later let minimumReleaseAgeIgnoreMissingTime govern this: when true, the package is skipped with a warning instead of failing with ERR_PNPM_MISSING_TIME. If you want a hard failure, set it to false and fix the mirror.
Where Safeguard fits
A policy in your package manager decides what installs. Safeguard's SBOM and dependency scanning shows what actually resolved in your lockfiles afterward, and policies and gates can block a pull request that adds a risky component. You can try a free scan at https://gold.safeguard.sh/scan.
Quick check
Is trustPolicy on by default?
No. The default is off. You opt in with trustPolicy: no-downgrade in your pnpm settings.
Will it flag a package that never had provenance?
No. The policy only fails when trust evidence decreases compared with earlier releases, so a package that never had any evidence has nothing to downgrade from.
Sources
Last reviewed: 19 October 2026.
