Dependabot Drops PATs for Private GitHub Packages

Dependabot can now read private packages hosted on GitHub Packages without a personal access token (PAT), removing one of the more awkward pieces of authentication from automated dependency updates. GitHub re-enabled the capability on September 8, 2026, after previously rolling it back because of an npm package-resolution problem, so the change matters most to teams that maintain private dependencies and want fewer long-lived credentials in their repositories.

Dependabot private GitHub Packages access now uses repository permissions

The change is built around the GITHUB_TOKEN, GitHub's automatically provided token for repository automation. Dependabot jobs can now request packages: read permission and use that token when retrieving packages from GitHub-hosted registries, including GitHub Packages and the GitHub Container Registry. The important difference is that access is tied to the repository's existing package permission rather than a developer-created PAT stored as a secret. 

For a private package to be available, its owner must grant the repository read access through the package's Manage Actions access setting. Once that relationship exists, Dependabot can pull the package automatically. GitHub says this works across every GitHub Packages ecosystem supported by Dependabot, rather than being limited to a single package manager such as npm. 

The practical change is smaller configuration, not a new dependency system

Before this change, teams using private GitHub-hosted packages could put authentication details into dependabot.yml. A personal access token could then give Dependabot the credentials needed to reach the private registry. That approach works, but it creates another credential that has to be protected, rotated and eventually removed when its owner or permissions change. GitHub's new approach lets repository-level package access perform that job instead. 

For an existing project, the migration is relatively straightforward. The package owner grants the Dependabot repository Read access under package settings, then any PAT-based registry configuration used solely for that GitHub-hosted package can be removed from dependabot.yml. GitHub specifically says no change to the Dependabot configuration file is required for the new authentication method. 

GitHub had to fix a real npm routing problem first

This is not simply a delayed announcement of an old feature. GitHub first introduced automatic Dependabot access on June 23, 2026, then temporarily rolled it back after discovering a conflict that caused some npm update jobs to resolve public packages through GitHub Packages. That detail is significant because dependency automation depends on getting the correct package from the correct registry; an authentication improvement is not useful if registry resolution can silently change underneath it. 

GitHub says the feature has now been re-enabled with automatic GitHub Packages credentials used only as fallback authentication. Explicit registry credentials and normal registry routing continue to take precedence. In other words, the September release is better understood as a corrected version of the earlier rollout rather than an entirely new authentication model. 

What this means for npm, containers and other package ecosystems

The benefit is broader than JavaScript projects. GitHub says the automatic access method applies to every GitHub Packages ecosystem supported by Dependabot, including packages accessed through the GitHub Container Registry. That matters for organizations where application dependencies, internal libraries and container images all live behind GitHub's package infrastructure.

There is also an important boundary: this change does not eliminate PATs for every private registry. Third-party services such as Artifactory, Azure Artifacts and Nexus still require their own authentication configuration, and GitHub's documentation continues to describe token-based registry entries for those services. The new mechanism is specifically useful when the private dependency is hosted by GitHub itself. 

The security advantage comes from reducing credential sprawl

Removing a PAT is valuable because dependency automation often runs without a developer sitting at the keyboard. A token embedded in automation configuration becomes another secret that an organization has to govern, while repository-scoped permissions can be changed by adjusting package access. The new arrangement therefore reduces the number of long-lived credentials involved in routine dependency maintenance, although it does not remove the need to review which repositories can read private packages.

That distinction is worth keeping in mind. Granting a repository access to a private package is itself a permission decision, so teams should not treat the removal of PATs as permission-free automation. The safer configuration is still the narrowest one: grant only the repositories that genuinely need a package, give them Read access, and avoid leaving obsolete token-based credentials in configuration after migration.

Developers should check their Dependabot configuration now

Teams already using private GitHub Packages should inspect their dependabot.yml files for PAT-based registry entries that exist only to authenticate against GitHub-hosted packages. After confirming that the relevant repository has package Read access, those credentials can be removed according to GitHub's migration guidance. Teams using third-party private registries should leave their existing authentication configuration in place because the new GitHub-hosted mechanism does not replace it.

The more interesting part of this release is not that Dependabot learned another way to download a package. It is that dependency automation is moving toward permissions that follow the repository and package relationship instead of individual developer credentials. If GitHub can keep that model predictable across package ecosystems, the result should be simpler automation with fewer secrets to rotate and fewer authentication failures to investigate.