The shorthand "npm packages are signed" hides a more complicated reality. npm has signed every published tarball with the registry's PGP key for years, the registry signing infrastructure rotated to ECDSA keys in 2023, sigstore-backed provenance attestations layer on top of that for packages that opt into them, and npm audit signatures is the CLI surface that lets you verify any of this from the consumer side. What the shorthand does not capture is that none of this verification happens automatically during a normal npm install, that downstream package managers and registry mirrors have varying degrees of support for the verification flow, and that the practical experience of running verification in CI depends heavily on which corner of the ecosystem you are in.
This piece walks through the actual state of npm signature verification in 2026, what npm audit signatures does and does not check, how the verification interacts with provenance, and what the downstream tooling landscape looks like for organizations that want install-time verification rather than after-the-fact auditing.
What does the registry signature actually prove?
When a package version is published, the registry hashes the tarball and signs the hash with the registry's signing key. The signature is published in the package metadata alongside the tarball URL, and any client that fetches the metadata can verify that the tarball it downloads matches the signed hash. This guarantees that the bytes you receive from the registry are the same bytes that were on the registry when the version was published; it does not guarantee that the published bytes correspond to a particular source repository, a particular maintainer, or any specific build process.
The signing key rotation in 2023 moved the registry from a long-standing PGP key to an ECDSA key on the P-256 curve, and the public keys are distributed through the registry's /-/npm/v1/keys endpoint along with key validity windows that let clients pick the right key for verification when historical signatures are checked against current keys. The rotation also added a forward-compatibility mechanism so that future key changes can be deployed without breaking older clients, which has mattered more than it sounds; supply chain key rotations are operationally complex, and the npm rotation did expose some clients that had hardcoded the older key.
What the signature does not say is anything about the publisher. The signature is the registry's signature, not the publisher's; npm operates the signing infrastructure on the publisher's behalf, and a compromise of the registry's signing infrastructure or of an individual package's publish credentials would still produce a signature that verifies cleanly. Provenance attestations are what tie the package back to a specific build identity through sigstore, and they exist precisely because the registry signature alone does not answer the question "did the right person publish this?"
What does npm audit signatures actually verify?
npm audit signatures is the official CLI command for verifying both registry signatures and provenance attestations against an installed dependency tree or against a lockfile. The command fetches the signature data for each package version in the tree, validates the registry signatures against the current and historical npm public keys, and validates any provenance attestations against the sigstore certificate transparency log. The output is a per-package status that distinguishes between verified-signature-and-provenance, verified-signature-only, signature-failure, and missing-signature states.
The command runs against a resolved tree, which means it works on a fresh npm install or on an existing node_modules directory but does not run as part of the install itself. The default npm install does not verify signatures unless you have configured it to do so, and even then the verification covers only the registry signature, not the provenance attestation. This is a deliberate design choice; verification has a cost in install time, the long tail of packages without provenance would produce a lot of noise if missing attestations failed the install, and the npm team has chosen to expose verification as an explicit step rather than as an implicit gate.
The verification path is well-defined but not always easy to wire into CI. The recommended pattern in 2026 is to run npm audit signatures after npm ci in a CI job, fail the build on signature failures, and report attestation status as metadata that flows to a security dashboard rather than as a build-breaking signal. Signature failures are rare and almost always indicate something has gone seriously wrong, so failing the build on them produces a high signal-to-noise alert. Missing attestations are common enough that failing on them is impractical for most real applications.
How does signature verification compose with provenance and Trusted Publishing?
The three primitives stack cleanly: registry signature, provenance attestation, and Trusted Publishing configuration. The registry signature proves that the bytes you have are the bytes the registry published. The provenance attestation proves that those bytes were produced by a specific workflow run from a specific commit in a specific repository. The Trusted Publishing configuration on the registry side proves that the publish was authorized through OIDC binding to that specific workflow, rather than through a long-lived token that could have been stolen. For a package that has all three, the chain of custody from source to install runs through verifiable artifacts at every step, and a consumer can reconstruct the chain from public data after the fact.
The asymmetry in 2026 is that registry signatures are universal (every package on the registry has one), provenance attestations are common for major packages but spotty in the long tail, and Trusted Publishing is a publisher-side configuration that consumers can observe through provenance attestation metadata but cannot directly query at install time. A consumer who wants the full chain has to combine signature verification, attestation verification, and inspection of the attestation's claims about the build identity. npm audit signatures does the first two; the third is a step the consumer has to do themselves or with external tooling.
For high-value packages, the right consumer posture is to pin trust to specific workflow identities for specific packages, so that a future publish from a different workflow (which might still produce a valid signature and a valid attestation) is flagged for review. This is similar to the way TLS pinning works in mobile applications; the goal is to detect a legitimate-but-unexpected change in the identity chain before it propagates into production. The tooling for this kind of pinning at the npm consumer level is improving but is not yet a first-class part of npm audit signatures; it usually involves capturing attestation claims into a baseline file and diffing future installs against it.
Where does downstream tooling sit in the verification chain?
The npm CLI itself is the reference implementation, but most real-world installs in 2026 go through one or more layers of intermediation that have their own verification posture. pnpm and Yarn both have varying degrees of support for npm-style signature verification, with pnpm having implemented audit signatures equivalents and Yarn 4 having a more limited verification surface. Registry mirrors and proxies, including Artifactory, Nexus, and Verdaccio, all handle signature passthrough differently; some re-sign with their own key after caching, which preserves availability but breaks end-to-end verification against the upstream npm signature.
For organizations using a registry mirror, the verification question splits into two parts: does the mirror preserve the upstream signature data faithfully, and does the consumer's tooling verify against the upstream key rather than against the mirror's key? The clean answer is to configure the mirror in pure proxy mode where signatures are passed through unchanged, and to run signature verification against the upstream npm public keys in CI. The less clean answer is that some enterprise mirrors re-sign for operational reasons (typically to support content modifications like CVE patches), and in those environments the verification chain shifts from being a check against npm's identity to a check against the mirror's identity, with the trust assumption that the mirror operator has done the upstream verification on the consumer's behalf.
The downstream tooling story for provenance is more uniform. Sigstore is a public infrastructure, the Rekor transparency log is accessible to anyone, and attestations can be verified by any tool that speaks the in-toto and DSSE formats. cosign verify-attestation works against npm provenance bundles with some configuration, and the ecosystem of attestation verifiers continues to grow. The result is that provenance is in some ways easier to verify outside the npm CLI than registry signatures are, simply because the underlying infrastructure is more open and the verification path does not depend on npm-specific tooling.
What should organizations actually do in 2026?
The pragmatic recommendation is to enable npm audit signatures as a CI step on every project, fail on signature verification errors, and capture the provenance attestation status for visibility without making it a build-breaking gate for the general case. For a defined set of critical packages, raise the bar to requiring valid provenance and a specific Trusted Publishing configuration, and treat failures on these packages as production incidents.
The other thing to do is to inventory the verification posture of your registry mirrors and proxies. Re-signing mirrors are not inherently bad, but they change the trust model, and a security program that thinks it is verifying npm's signatures while actually verifying its own mirror's signatures has a blind spot it does not know about. The mitigation is to either run signature verification against the upstream registry directly from CI, or to ensure that the mirror's re-signing process is itself audited and that the mirror's verification of upstream signatures is logged and reviewable.
For the long tail of packages without provenance, the realistic posture is patience. Coverage is climbing, the major packages have it, and packages without it are increasingly visible as a risk signal. Pushing maintainers toward adoption through pull requests, public dashboards, and TPRM conversations is more effective than trying to enforce a hard requirement that will fail against half the dependency graph. The verification story will look meaningfully different in 2027, and 2026 is the year to set up the infrastructure that will be ready when coverage catches up.
How Safeguard Helps
Safeguard runs continuous signature and provenance verification across every npm package in your dependency graph and stores the verification state alongside the SBOM so that you can see at a glance which packages have full chain-of-custody and which ones do not. Griffin AI flags signature verification failures as high-severity events and surfaces packages whose provenance attestations change identity, branch, or workflow file from one version to the next. Reachability analysis tells you which unverified or weakly verified packages are actually used by your application versus which ones are inert, so prioritization reflects real exposure. TPRM workflows let you require specific verification states for vendor-supplied packages and track adoption over time. Policy gates enforce signature verification and critical-package provenance requirements at install time and across CI, blocking deploys when the verification posture regresses below your bar.