Dependabot no longer needs a PAT for GitHub Packages

If your dependabot.yml contains a personal access token so the bot can read your private packages, you can delete it today. GitHub made automatic Dependabot access to GitHub-hosted registries generally available on September 8, 2026. Dependabot now authenticates with its own GITHUB_TOKEN and packages: read permission. No PAT, no rotation reminder, no long-lived credential sitting in a repo secret with more scope than it needed.

What actually happened

Per the GitHub Changelog, the change covers every GitHub Packages ecosystem Dependabot supports, across both *.pkg.github.com and ghcr.io. It first shipped in June 2026, got rolled back over an npm routing conflict, and is now back as a fallback that still respects explicit registry credentials when you set them.

The migration is two steps, and the first one is the one people skip:

1. On each private package's settings page, grant the consuming repository Read access under Manage Actions access
2. Remove the PAT-based registries: block from .github/dependabot.yml

Order matters. Drop the PAT before granting package access and Dependabot goes quiet — it will stop opening update PRs for anything it can no longer resolve, and a bot that fails silently looks exactly like a bot with nothing to do.

Why killing that PAT matters for your business

A personal access token in a Dependabot config is one of the most under-examined credentials in a small shop's stack. Ours usually turn out to belong to whoever set up CI in 2023. It reads packages across the whole org because scoping it per-repo was fiddly. It has no expiry, because an expiry meant a broken build at 2am. And it survives that person leaving the company, which is the part that should bother you.

Replacing it with a scoped, ephemeral GITHUB_TOKEN removes a standing credential and replaces implicit org-wide reach with per-package grants you can actually see. That is the same direction the rest of the ecosystem moved this year — npm trusted publishing and agent identity work at NIST are the same idea applied to different plumbing: stop handing automation a password that outlives the job.

Do the audit while you're in there. Run through your org's PATs and fine-grained tokens and ask which ones exist only because some tool could not authenticate itself two years ago. Most shops we open up have three to five. GitHub has been removing the reasons for them one at a time; the tokens do not remove themselves.

One caveat: this covers GitHub-hosted registries. Private Artifactory, a self-hosted Nexus, or a third-party npm proxy still need real credentials in registries:. Those are the ones worth putting on a rotation schedule, because nothing is coming to retire them for you.

Sources: GitHub Changelog, Dependabot options reference.