The npm CLI verifies registry signatures from any registry that serves ECDSA public keys at /-/npm/v1/keys and puts a signature in each version's dist metadata. You can check yours by requesting that keys URL. If it returns keys but packages lack signatures, npm audit signatures reports missing signatures.
What registry signatures protect against
The npm docs say packages from the public registry are signed so you can detect tampering with package content. The stated threat is an attacker who controls a registry mirror or proxy and tries to alter a tarball in transit. Verification needs npm v8.15.0 or later and dependencies installed with npm install or npm ci.
This is separate from provenance. A registry signature says the registry vouches for this tarball. Provenance says where and how it was built. Our post on signatures, provenance and SBOM attestations draws the difference.
What a compatible registry must provide
The docs list two conventions.
- Signatures in metadata. Each published version has a dist object with a signatures array of entries with a keyid and a sig. The signed message is the package name, version and tarball integrity in the form name@version:integrity.
- Public keys at a fixed path. The registry serves keys at its host under /-/npm/v1/keys. Each key has an expiry (or null), a keyid that is the SHA256 fingerprint, a keytype and scheme (only ecdsa-sha2-nistp256 is supported by the CLI), and a base64 public key. The keyid on each signature must match one of these keys.
The docs add that current best practice is to sign using a key management system that does the operation in a hardware security module, so nobody handles the private key directly.
Check your registry
curl -s https://registry.internal.example/-/npm/v1/keys
npm audit signatures
Read the results:
| Result | Meaning |
|---|---|
| Keys endpoint returns keys, all packages verified | Signatures work |
| Keys endpoint returns keys, some packages report missing signatures | The CLI errors, because the registry advertises signing but some versions lack signatures |
| Keys endpoint returns nothing useful | The registry does not support signatures, so there is nothing to verify |
The docs explain the middle case: the CLI errors on missing signatures when the registry supports them, because the absence could mean an attacker is trying to get around verification.
If your registry is a proxy
A proxy or mirror in front of the public registry often passes through the upstream metadata, including the signature. Whether verification works depends on whether it passes that field unchanged and whether keys resolve at your host. Test it rather than assume. If your tool rewrites metadata, signatures may break or vanish.
Rollout steps
- Run the check against your registry from a clean machine.
- Record the result and the npm version.
- If keys are missing, ask your registry vendor or admin whether signing is supported.
- Add the audit signatures step to CI, after install.
- Decide what the build does on failure, since a hard failure is the safer default.
See also what npm audit signatures verifies in your intake pipeline.
Where Safeguard fits
Safeguard's dependency scanning and SBOM generation read your lockfiles and record the components your build resolved, which complements registry-level checks. A free scan is at https://gold.safeguard.sh/scan.
Quick check
How do I know if a registry supports signatures?
Request registry-host/-/npm/v1/keys. If it returns public signing keys, the registry advertises signature support.
Why does npm treat missing signatures as an error?
If the registry supports signatures and a package lacks one, the docs say an attacker might be trying to circumvent verification, so the CLI errors.
Sources
Last reviewed: 19 October 2026.
