The option is generally available on github.com. GitHub says it will also be available in GitHub Enterprise Server 3.24, but the announcement does not provide a release date for that server version.
Anonymous authentication is not unrestricted access
The important distinction is between authentication and permission to contact a host.
Selecting Anonymous tells Dependabot to use a registry without credentials. It does not change the registry’s own access policy or bypass Dependabot’s network controls. On github.com, update jobs can contact hosts on the egress allowlist and configured private registries; defining a private source only in .npmrc or nuget.config is insufficient.
GitHub’s troubleshooting documentation explains why: Dependabot jobs use an HTTP/HTTPS proxy that checks outbound destinations. This reduces the risk of malicious dependencies or build scripts sending repository contents or registry credentials to unapproved hosts. It is not a complete shield against exfiltration, however, because an allowed destination could itself be compromised.
In short, “no password required” and “approved destination” answer different questions. Both conditions still matter.
Organization-wide configuration, with repository boundaries
Organization-level registries apply to repositories granted access to the definition. Crucially, that includes repositories using only Dependabot security updates, even when they have no dependabot.yml file. “Organization-level” therefore means centrally managed—not automatically accessible to every repository.
GitHub’s registry-access documentation adds the practical consequence: Dependabot cannot check private dependencies for security or version updates, or raise update pull requests for them, unless it can access their registry. A working developer restore is not sufficient evidence that the automated update job has equivalent access.
For teams maintaining private package sources, the value is straightforward: central configuration can remove an access obstacle without introducing a meaningless secret.
How to add an anonymous registry
GitHub documents organization-owner access for configuring private registries through the user interface. Before proceeding, confirm that the intended registry permits credential-free reads and identify which repositories should receive access.
- Open the organization’s Settings.
- Select Secrets and variables, then Private registries.
- Choose New private registry.
- Supply the registry’s URL and Type.
- Select Anonymous as the authentication method.
- Choose the repository-access scope: all repositories, private and internal repositories, or selected repositories.
- Select Add Registry to save the definition.
Existing placeholder-token entries must be replaced. GitHub says authentication methods cannot be changed after creation: delete the existing registry and recreate it with Anonymous authentication. As an administrative precaution, record its URL, type and repository scope before deletion so the replacement preserves the intended access.
If the update still fails, inspect the proxy log
GitHub documents a useful diagnostic distinction: an egress denial returns 403 Forbidden, but the package manager may present it as a network or authentication failure. Look for proxy lines containing:
egress not allowlisted packages.example.com
The hostname identifies the blocked destination. Check for additional blocked hosts too: registries can redirect downloads to separate storage or CDN endpoints. Changing credentials will not resolve a proxy rejection.
GitHub’s blocked-host guide describes repository-level configuration through the top-level registries key and an updates reference in dependabot.yml. The new announcement separately confirms organization-level access for security-update repositories without that file. Administrators should not interpret the older YAML-oriented explanation as a requirement to duplicate every organization registry in every repository.
For validation, look for the next applicable job to retrieve dependencies without the previous access failure. A successful job need not produce a pull request if no update is required; the key is distinguishing successful registry access from an absence of update activity. That is the operational lesson here: remove unnecessary authentication workarounds, but verify the actual dependency-access path.