New Claims Matching Expression (Preview) federated credentials fail to create on any app/pattern, while pre-existing ones of the same type still work

Question

New Claims Matching Expression (Preview) federated credentials fail to create on any app/pattern, while pre-existing ones of the same type still work

Ajitem Joshi 10

Description

Creation of new Claims Matching Expression (Preview) federated credentials fails for the GitHub Actions issuer across every variation tested -different literal values, different wildcard positions, and two different app registrations, including a pattern copied verbatim from Microsoft's own documentation.

Meanwhile, pre-existing credentials of the same type, created previously on both app registrations, continue to function correctly.

Two possible explanations remain open (see Primary question below), and we haven't yet been able to isolate which one applies.

Environment

Tenant ID: (will provide privately if needed)

Application (client) ID: (will provide privately if needed)

App registrations tested: App-A, App-B - both already had pre-existing, working Claims Matching Expression credentials before this investigation began. No test has been performed yet against a completely fresh app registration with zero prior flexible credentials.

Issuer: https://token.actions.githubusercontent.com

Existing working credentials (created previously, still active)

App-A:

claims['sub'] matches 'repo:contoso-org/sample-repo*:environment:env-alpha'
claims['sub'] matches 'repo:contoso-org/sample-repo*:environment:env-beta'

App-B: at least one pre-existing working flexible credential (exact count/values TBD)

Tests performed (all fail identically)

#	Test	Result
1	Same pattern shape as existing working credentials, new environment name, App-A	❌ Fails
--------	--------	--------
1	Same pattern shape as existing working credentials, new environment name, App-A	❌ Fails
2	Same pattern shape, throwaway dummy value, App-A	❌ Fails
3	Same pattern shape, different app registration (App-B) — note: App-B also had pre-existing flexible credentials, so this is not a zero-prior-credentials control	❌ Fails
4	Wildcard moved to the environment segment instead of repo segment, literal repo name	❌ Fails
5	Pattern copied directly from Microsoft's own documented example	❌ Fails

Error (identical for every failing attempt)

Failed to add federated credential. Error detail: The 
FederatedIdentityCredential.ClaimsMatchingExpression.Value is invalid. 
Rule exception: Expression configured for issuer 
'https://token.actions.githubusercontent.com' either lacks all required 
claims or contains unallowed claims. paramName: 
FederatedIdentityCredential.ClaimsMatchingExpression.Value, 
objectType: Microsoft.Online.DirectoryServices.Application

Sample Trace ID: 00857c72-ab71-4a3f-a211-2733db303300 Sample Correlation ID: b09fe026-0397-4756-ac4f-5003241720b0 Sample Timestamp: 2026-08-03 08:47:53Z

Primary question

Two competing explanations remain open, and we'd appreciate clarity on which (if either) applies:

Tenant/region eligibility changed - creation of new flexible federated credentials may no longer be enabled for this tenant, while previously-created ones remain grandfathered and continue to work.

An undocumented per-app or per-issuer limit on the number of wildcard/flexible credentials exists, and both App-A and App-B happened to already be at or near that limit - so new additions are rejected regardless of content.

We have not yet been able to test against a completely empty app registration (zero pre-existing flexible credentials) to cleanly separate these two theories, due to concerns about disrupting production workflows during isolation testing. If there's a way to check this from Microsoft's side (e.g., tenant Preview enrollment status, or any documented/undocumented per-app limits on claimsMatchingExpression credentials), that would help us confirm the cause without further production-side testing.

Gary Powell-Jones 35 Reputation points

2026-08-04T12:31:50.05+00:00

Same here.
I can't make a change to any existing claim that is already on the Entra app registration either.
GitHub has made changes to the OIDC pattern, but I can't at the moment match that in Entra.

Tried on 3 separate tenants - all with same error, so I'd assume a change in the Azure platform is stopping this.

Note - doesn't matter if we use Azure portal or az rest CLI - same error generated
Julia Radkolb 5 Reputation points

2026-08-11T13:19:57.0933333+00:00
Following the updates regarding immutable subject claims for GitHub, the required claims for federated credentials have changed.

According to the new documentation, you will need to make the following changes:

For GitHub, a flexible federated identity credential must match the sub claim and one or both of the following additional claims:

repository_id identifies the repository where the workflow runs.

repository_owner_id identifies the repository owner/organization. These additional claims are required regardless of whether sub uses a name-based, customized, or immutable format. Include the claims that represent the intended trust boundary.

So the result would probably look similar to this:

claims['sub'] matches 'repo:contoso-org/sample-repo*:environment:env-alpha' claims['repository_id'] eq '00000' and claims['repository_owner_id'] eq '000000' claims['sub'] matches 'repo:contoso-org/sample-repo*:environment:env-beta' and claims['repository_owner_id'] eq '000000'

I have already tried this exact approach and so far it is working!
Regarding pre-existing credentials, it seems they can be left as-is unless there are changes to the existing claims needed.
Gary Powell-Jones 35 Reputation points

2026-08-11T13:57:17.3566667+00:00
@Julia Radkolb thanks & this solves the issue. The documentation on the Entra App registration pages doesn't reflect this (yet).
Both older repos (that dont use immutable format) and newer ones (post July 15) work in my tests with no changes to the calling repos or yaml files.

For others, we found repository_owner_id was most flexible for us as it is the organisation ID & we are using multiple reusable workflows.

claims['sub'] matches 'repo:contoso-org/sample-repo*:environment:env-beta' and claims['repository_owner_id'] eq '000000'

Can this please be marked as the answer
Ajitem Joshi 10 Reputation points

2026-08-14T07:52:47.4866667+00:00

Thanks @Julia Radkolb for your insights!

Hi @Gary Powell-Jones , could you please post your solution as an answer? I'm unable to mark a comment as an answer.

Your answer

Gary Powell-Jones 35 Reputation points

2026-08-04T12:31:50.05+00:00

Same here.
I can't make a change to any existing claim that is already on the Entra app registration either.
GitHub has made changes to the OIDC pattern, but I can't at the moment match that in Entra.

Tried on 3 separate tenants - all with same error, so I'd assume a change in the Azure platform is stopping this.

Note - doesn't matter if we use Azure portal or az rest CLI - same error generated
Julia Radkolb 5 Reputation points

2026-08-11T13:19:57.0933333+00:00

Following the updates regarding immutable subject claims for GitHub, the required claims for federated credentials have changed.

According to the new documentation, you will need to make the following changes:

For GitHub, a flexible federated identity credential must match the sub claim and one or both of the following additional claims:

repository_id identifies the repository where the workflow runs.

repository_owner_id identifies the repository owner/organization. These additional claims are required regardless of whether sub uses a name-based, customized, or immutable format. Include the claims that represent the intended trust boundary.

So the result would probably look similar to this:

claims['sub'] matches 'repo:contoso-org/sample-repo*:environment:env-alpha' claims['repository_id'] eq '00000' and claims['repository_owner_id'] eq '000000' claims['sub'] matches 'repo:contoso-org/sample-repo*:environment:env-beta' and claims['repository_owner_id'] eq '000000'

I have already tried this exact approach and so far it is working!
Regarding pre-existing credentials, it seems they can be left as-is unless there are changes to the existing claims needed.
Gary Powell-Jones 35 Reputation points

2026-08-11T13:57:17.3566667+00:00

@Julia Radkolb thanks & this solves the issue. The documentation on the Entra App registration pages doesn't reflect this (yet).
Both older repos (that dont use immutable format) and newer ones (post July 15) work in my tests with no changes to the calling repos or yaml files.

For others, we found repository_owner_id was most flexible for us as it is the organisation ID & we are using multiple reusable workflows.

claims['sub'] matches 'repo:contoso-org/sample-repo*:environment:env-beta' and claims['repository_owner_id'] eq '000000'

Can this please be marked as the answer
Ajitem Joshi 10 Reputation points

2026-08-14T07:52:47.4866667+00:00

Thanks @Julia Radkolb for your insights!

Hi @Gary Powell-Jones , could you please post your solution as an answer? I'm unable to mark a comment as an answer.