Free tool: runs in your browser
Npm trusted publishing checklistbefore you set up or change it for a package
TimeBinder adds a layer of protection against AI and human fraud and disputes. Check the workflow and package settings that must match, the 2-day first-publish window, old tokens and staged publishing, and the exact files you can still show.
Nothing you tick is sent anywhere. This page is not a security audit and cannot show that a package or workflow is secure.
Check the setup, the tokens and the copies you can still show
Tick what is true of the package, the workflow and the files you keep. You get a shareable result and clear next steps. Nothing you tick is sent to TimeBinder.
Your choices stay on this page. Nothing you tick is sent anywhere or tied to your name.
Tick everything that is true before you set up or change npm trusted publishing
This looks at the current npm docs on trusted publishing, the workflow and package settings that must match, what happens to old tokens, and the exact files you can still show. It is not a security audit.
What to do now
What should I check before I switch an npm package to trusted publishing? The short answer
Read the current npm docs on trusted publishing first. Make sure the workflow filename, repository and any environment name on npmjs.com exactly match your setup, that the workflow has id-token: write, and that package.json repository.url matches the GitHub repository. Add the trusted publisher when a release is ready to run, because a new configuration must complete its first successful publish within 2 days or it expires. Then decide about old tokens and staged publishing, and keep dated copies of the workflow, package.json and your settings.
This checklist is not a security audit. The docs describe trusted publishing as replacing long-lived tokens with short-lived credentials, and that does not show a package is free of compromise. A TimeBind of a file you already hold can show that exact file existed no later than a recorded time and still matches.
Why this came up in October and November 2026
The npm docs on trusted publishing (last edited 6 October 2026 at the time of our check) describe publishing from CI/CD with OpenID Connect instead of long-lived npm tokens. They list the requirements: npm CLI 11.5.1 or later and Node 22.14.0 or later; supported cloud-hosted providers (GitHub Actions on GitHub-hosted runners, GitLab CI/CD on GitLab.com shared runners, CircleCI cloud); an exact, case-sensitive workflow filename; and id-token: write for GitHub Actions. Each package can have up to 10 trusted publishers, and an existing configuration cannot be changed, only deleted and recreated. A new configuration must complete its first successful publish within 2 days or it expires.
The docs also describe changes this year. Configurations created before 20 May 2026 allow npm publish only, and configurations created after 3 September 2026 are set to allow npm stage publish, with direct npm publish a separate choice. With staged publishing, a maintainer reviews a staged package and approves it with 2FA before it goes live. The docs recommend, once trusted publishing works, disallowing tokens in the package settings and revoking automation tokens you no longer need, and using a read-only token for installing private dependencies. Provenance is generated automatically only for public packages published from public repositories.
Security press reported a flaw in October 2026. Help Net Security reported on 13 October 2026 that Bloom Security found npm trusted publishing could trust a GitHub repository name rather than a permanent ID, exposing more than 1,500 packages to takeover, and that unvalidated configurations now expire. Posts on X repeated this widely. This page relies on the current npm docs for what to do, and does not treat press descriptions as the official wording.
Measured demand is current. Autocomplete checked on 12 November 2026, about 11:40 PM Australia/Brisbane, returned ten suggestions for “npm trusted publishing”, including “npm trusted publishing github actions” and “npm trusted publishing 404”, and “npm classic token revoked”. A dated YouTube sample the same evening included 24 October 2026 explainers on trusted publishing and on staged publishing (16 and 11 views at the check, which is thin) and several supply-chain videos with 40 to 213 views. An X search of the same window, first page of 25 posts as a lower bound, included a 25 October 2026 post asking for branch-to-tag mapping that reached 21,541 impressions and 204 likes at the check, and a 3 November 2026 post that setup had changed twice since April. Counts and suggestions will keep moving.
The checks are written for the next time you set up or change trusted publishing. Always read the current docs, since they have changed more than once this year.
Sources: the current npm trusted publishing docs and staged publishing docs.
What this checklist does and does not do
The honest job of this page is to slow down a publishing change until the settings match, the tokens are decided and the exact files are kept, not to certify a package for you. See also the glossary entries for existed no later than and fingerprint.
| Part | What it does | What it does not do |
|---|---|---|
| Current npm docs | Reminds you to read the requirements, the 2-day first-publish window, the allowed actions and the token advice. | Configure npm for you, or show that your setup matches the docs. |
| Match and tokens | Gives you a reason to check the workflow filename, repository and permissions, and to decide about old tokens and staged publishing. | Show that a package is secure, or that no token was ever exposed. |
| Copies you already hold | Reminds you to keep the exact workflow file, package.json and the settings you chose. | Show who published a version, or what a past CI run did. |
| A TimeBind of a file you already hold | Records that an exact file existed no later than a recorded time and still matches, using a SHA-256 fingerprint made in your browser. The file stays on your device. | Show that a package or publish was safe. |
If a workflow or release file is one you may need to stand behind later
Before you set up or change trusted publishing:
- Keep a dated copy of the exact publish workflow, package.json and a screenshot or export of the trusted publisher and publishing access settings.
- Make a TimeBind of each exact file you already hold. The fingerprint is made in your browser and the file stays on your device. You can later download a Proof of Time Certificate.
- Read the current docs first, and store the files, the docs capture and the certificate together, with a note of when the repository or workflow was last renamed or moved.
A TimeBind shows the exact file existed no later than the recorded time and still matches. It cannot show that a package or a publish was safe.
First Pooled TimeBind free, no card, then from US$5. An ASAP TimeBind is US$15.
What a TimeBind shows, and what it does not. It shows that an exact file existed no later than a recorded time and that a copy shown later still matches its fingerprint. It does not show who made the file, who owns it, that its contents are true, or whether AI was used to make or edit it. This is general information, not legal advice.
npm trusted publishing checklist: FAQ
Can this tool show that my npm package is secure?
No. The npm docs describe trusted publishing as removing long-lived write tokens in favour of short-lived credentials, and this checklist only helps you pause, check the settings and keep copies. It cannot show that a package is free of compromise.
What happens if I add a trusted publisher and do not publish for a week?
The current npm docs say a newly created configuration must complete its first successful publish within 2 days, or it expires and can no longer be used or edited. You would delete it and create a new one. Add it when a release is ready to run.
Why does my publish fail with ENEEDAUTH?
The docs say to first check that the workflow filename matches exactly what you configured, including the extension and letter case, and that the other fields match. They also note that npm does not verify the configuration when you save it, and that calling workflows can cause a mismatch. Read the current troubleshooting section.
Should I revoke my old tokens?
The docs recommend setting up trusted publishing first and checking it works, then restricting token access and revoking automation tokens you no longer need. Use a read-only token for installing private dependencies. Decide for your own package and keep a note of what you changed.
Does trusted publishing give me provenance for a private repository?
No. The docs say provenance is generated automatically only when publishing from a public repository to a public package, and not for private repositories.
Is anything I tick sent to TimeBinder?
No. The checklist runs in your browser. Your ticks stay on the page.
Related guides and tools
- GitHub Actions workflow lockfile checklistA neighbouring job before you merge a workflow that calls third-party actions
- Cloud coding assistant checklistA checklist before you share a private repo with a cloud assistant
- Ethersphere bee-js npm compromise: what developers should keepWhat to keep after an npm package compromise
- GitHub Actions CI secret-stealer: what developers should keepWhat to keep if a compromised action is in play
- Developer timestampingThe TimeBinder hub for developer file records
- Source code timestampingDated records for source you already hold
- GlossaryPlain definitions of fingerprint, SHA-256 and existed no later than
- All free toolsPrivate, in-browser tools
Date the exact files you already hold
Add a layer of protection against AI and human fraud and disputes: a dated, checkable record of the exact workflow and settings, kept beside the docs wording you may later need to show.
- Open the app and sign in with email or Google.
- Add your files. They stay on your computer.
- Seal them and download your Proof of Time certificates.
First Pooled TimeBind free, no card, then from US$5. See pricing.