GitHub's documentation says repositories created after July 15, 2026 use an immutable default OIDC sub claim that includes the owner and repository IDs. Existing repositories keep the old name based format unless they opt in. If you write trust rules by hand for new repositories, match the new format.
What changed
The classic sub claim is built from names, for example the owner and repository name followed by the context. Names can change. Repositories get renamed, transferred, or deleted and recreated, and a name can later be claimed by someone else.
For new repositories, GitHub's reference shows a format that adds IDs, with an example like repo:OWNER@OWNER-ID/REPO@REPO-ID:ref:refs/heads/BRANCH. Because the IDs do not change when a name does, the claim identifies the actual repository. The docs call this an immutable default. A note on the OIDC concepts page says the new format is not available on GitHub Enterprise Server.
Why it is a good change
Name based trust has a known weakness: if a repository is deleted and a new one is created with the same name, a rule that matches on name may trust the newcomer. ID based claims close that gap. GitLab's guidance points the same way, recommending stable identifiers such as project_id alongside the subject because a path can be reused while an ID cannot.
| Property | Name based sub | ID based sub |
|---|---|---|
| Survives a rename | No, rule must be updated | Yes |
| Resists a recreated repo with the same name | No | Yes |
| Easy to read in a policy | Yes | Less so |
| Applies to | Existing repositories by default | Repositories created after July 15, 2026 by default |
What to check in your own setup
- Note the creation date of each repository that deploys with OIDC. Anything created after July 15, 2026 may emit the new format.
- Open the cloud trust rule for those repositories and compare it with the format GitHub documents. A rule written for the old format will refuse the new token.
- For existing repositories, decide whether to opt in. GitHub says existing repositories keep the earlier format unless they opt in, and that custom templates are controlled through the customization settings, including a setting that resets a repository to the default.
- If you use organization level templates, remember GitHub says they do not affect workflows already using OIDC unless the repository has opted in.
- When you change the format, create the matching condition in the cloud first. Otherwise, per GitHub, the generated token might not be accepted.
- Test both a positive and a negative run after the change.
Reading the format
A sub with IDs is longer, but the parts are the same: the owner with its ID, the repository with its ID, then the context, such as a ref or an environment. You can write exact matches for environment and ref forms just as before. Keep exact matches rather than wildcards; a wildcard over the whole repository still trusts every branch and pull request.
Who should care most
Platform teams that create many repositories from templates, and teams that run automated provisioning of cloud roles per repository. If your automation builds trust rules from a template, update the template so new repositories get working rules from day one.
Quick check
Do I have to migrate existing repositories?
GitHub says they keep the previous default unless they opt in. Migration is a choice; consider it where renames or recreated names are a real risk.
Does the new format apply on GitHub Enterprise Server?
GitHub's concepts page says it is not available there.
Safeguard asset discovery can help you list repositories and pipelines that hold cloud access, and policies and gates can review pull requests that change workflow files. A free scan is at gold.safeguard.sh/scan.
Sources
- GitHub Docs: OpenID Connect reference
- GitHub Docs: About security hardening with OpenID Connect
- GitLab Docs: ID token authentication
Last reviewed: 19 October 2026.
