Audit Entra Workload Identity Federated Credentials

A federated identity credential is a standing trust rule: any token from the named issuer with the named subject becomes an access token for your app or managed identity, and nobody reviews those rules after the pipeline that created them goes green. Federation removes stored secrets, but it moves the security boundary to the issuer and subject, which live outside Entra ID in GitHub, GitLab, Terraform Cloud, Kubernetes clusters and other clouds. This guide is the periodic audit: building an inventory of every federated identity credential on app registrations and user-assigned managed identities, judging each issuer and subject, matching credentials to real sign-ins, and removing the ones that are unused, too broad or unowned. It is for Entra administrators, cloud platform teams and NHI programme owners. If you are still moving apps off client secrets, start with How to replace Azure app secrets with federated credentials; this page assumes federation is already in use.

This is an independent guide from NHI Mgmt Group, based on Microsoft and GitHub public documentation as of November 2026. It is not sponsored or reviewed by Microsoft or GitHub. Product features change, and flexible federated identity credentials are in preview, so confirm commands and properties against current documentation.

Key takeaways

Two places to look, two APIs. Federated identity credentials on app registrations come from Microsoft Graph; those on user-assigned managed identities come from Azure Resource Manager per subscription. An audit that only reads one misses half the trust.
The issuer decides who you trust. An issuer you do not recognise, a self-managed cluster issuer, or another tenant's login.microsoftonline.com issuer each hands token minting to someone outside your normal app governance.
The subject decides how much. A GitHub pull_request subject, a branch subject on a privileged app, or a flexible credential with a matches wildcard can let untrusted code obtain tokens.
Prove use from logs. FederatedCredentialId in AADServicePrincipalSignInLogs and AADManagedIdentitySignInLogs shows which credential each sign-in used, so unused trusts can be removed with evidence.
Standard tooling cannot read flexible credentials. Microsoft states that Azure CLI, Azure PowerShell and Terraform return an error when reading a flexible credential, so the audit script must use Graph beta and ARM REST directly or it will under-report.

When you need this

Scheduled review: quarterly, alongside the review of client secrets and certificates, as part of workload identity recertification.
After a source platform change: a GitHub repository renamed or transferred, a GitLab group restructured, a Kubernetes cluster rebuilt with a new OIDC issuer, a Terraform Cloud organisation renamed. The old trust often survives and may now match someone else.
After an incident involving a CI/CD platform or a cluster: a compromised pipeline can request tokens for every app that trusts its subject. Federated trust must be scoped in the response, not only stored secrets.
Before tightening controls: before an Azure Policy deny on managed identity federated credentials or a Conditional Access policy for workload identities, you need to know what exists and what will break.
Merger, divestment or tenant consolidation: credentials whose issuer is another Entra tenant represent cross-tenant trust that should be on the same register as B2B and cross-tenant access settings.

Before you start

Requirement	Detail
Graph read access	Application.Read.All (delegated or application) is the least privileged permission for listing an application's federatedIdentityCredentials. Delegated callers also need a role such as Cloud Application Administrator or Application Administrator, or ownership of the app
Azure read access	Reader on every subscription that holds user-assigned managed identities, so the ARM federatedIdentityCredentials child resources can be listed
Logs	Entra diagnostic settings sending ServicePrincipalSignInLogs and ManagedIdentitySignInLogs to Log Analytics, giving the AADServicePrincipalSignInLogs and AADManagedIdentitySignInLogs tables; retention at least as long as your longest workload cycle
Source platform access	Read access to the GitHub, GitLab or Terraform Cloud organisations and Kubernetes clusters named in subjects, to confirm the repository, environment or service account still exists and who controls it
Change authority	For removal later: an app owner or Application Administrator for app registrations; Contributor or Owner on the managed identity, which is what Microsoft documents for configuring its credentials

The audit itself is read-only until the remediation step. Agree before you begin who signs off removal of a credential that has no owner and no recent sign-ins.

Step-by-step

Steps 1 to 6 are read-only. Step 7 changes or removes credentials.

Enumerate app registration credentials. List every application, then each one's federated identity credentials. The documented endpoint is GET /applications/{id}/federatedIdentityCredentials (or /applications(appId='{appId}')/federatedIdentityCredentials), and Azure CLI exposes the same as az ad app federated-credential list --id <appId>. The v1.0 resource returns name, issuer, subject, audiences, description and id. To catch flexible credentials, which carry a claimsMatchingExpression instead of a subject, also read the same path on the beta endpoint:
```
az rest --method get \
  --url "https://graph.microsoft.com/beta/applications/{objectId}/federatedIdentityCredentials"
```
Any record with a null subject and a populated claimsMatchingExpression is a flexible credential. Record the app's display name, appId, owners and the Graph application permissions and Azure role assignments of its service principal alongside each credential.
Enumerate managed identity credentials. For each subscription, list user-assigned managed identities, then each identity's credentials. The CLI form is az identity federated-credential list --identity-name <name> --resource-group <rg>; PowerShell is Get-AzFederatedIdentityCredentials in Az.ManagedServiceIdentity. The ARM path is the child resource Microsoft.ManagedIdentity/userAssignedIdentities/{name}/federatedIdentityCredentials. Microsoft's flexible credential examples use api-version=2025-01-31-preview; use a version that returns claimsMatchingExpression so flexible credentials are not missed. System-assigned managed identities cannot hold federated credentials, so they are out of scope.
Normalise into one register. One row per credential with: parent type (application or managed identity), parent name and ID, credential name, issuer, subject or expression, audience, description, owner, privileges of the parent, and the source platform object it should map to.
Classify each issuer. Group rows by issuer string and decide for each whether it is known and governed. Use the issuer table below.
Score each subject. Rate the breadth of the subject or expression against the privileges of the parent. Use the subject table below. A broad subject on a read-only app is a finding; the same subject on an app with Owner on a subscription or Directory.ReadWrite.All is urgent.
Match credentials to sign-ins. Join the register to the sign-in tables by FederatedCredentialId, which Microsoft describes as the identifier of the federated identity credential used to sign in:
```
union AADServicePrincipalSignInLogs, AADManagedIdentitySignInLogs
| where TimeGenerated > ago(90d)
| where isnotempty(FederatedCredentialId)
| summarize SignIns=count(),
    IPs=make_set(IPAddress, 20), Resources=make_set(ResourceDisplayName, 20),
    LastSeen=max(TimeGenerated)
    by ServicePrincipalId, ServicePrincipalName, FederatedCredentialId
```
Credentials with no sign-ins in the window are removal candidates. Sign-ins from IP ranges or resources that do not fit the source platform are investigation candidates. Review failed attempts separately: the two tables do not describe ResultType values the same way, so check how success is recorded in your workspace before filtering on it.
Remediate in order of risk (changes state). Remove unused and orphaned credentials, narrow broad subjects, and replace unknown issuers. For apps use az ad app federated-credential delete or the Graph delete method; for managed identities use az identity federated-credential delete or Remove-AzFederatedIdentityCredentials. Record the full credential JSON before deleting: a federated credential cannot be restored from a recycle bin, but it can be recreated exactly from that record, which is your rollback.

Issuer classification

Issuer seen	What it means	Audit question
https://token.actions.githubusercontent.com	GitHub Actions on github.com. The issuer is shared by every GitHub customer, so the subject alone separates your repositories from everyone else's	Does the subject name a repository and organisation you control, and has that repository been renamed or transferred?
GitLab, Terraform Cloud or other SaaS CI issuers	A shared multi-customer issuer, as with GitHub	Is the project, group or workspace in the subject still yours and still in use?
A Kubernetes cluster OIDC issuer URL (AKS, EKS, GKE or self-managed)	Whoever controls the cluster's service account signing key, or can create pods with the named service account, can obtain tokens	Does the cluster still exist, who administers it, and is the issuer endpoint the managed service's or one you host?
https://accounts.google.com	Google Cloud service account identity tokens	Does the numeric service account ID still exist in a project you govern?
https://login.microsoftonline.com/{tenant}/v2.0	A user-assigned managed identity is the source, possibly in another tenant	Is the tenant ID yours? If not, is the cross-tenant trust approved and recorded?
Anything else	An unrecognised or self-hosted OIDC provider	Who runs it, where are its signing keys, and is it still needed? Treat as high risk until answered

Microsoft notes that issuer, subject and audience matching is case-sensitive and exact, and that leading or trailing whitespace blocks token exchange. Credentials whose issuer differs from the real token issuer only by a trailing slash or space will never be used; they are dead entries, not risks, but they hide in the register and should go.

Subject breadth scoring

Subject or expression	Breadth	Typical finding
repo:org/repo:environment:production	Narrow, and gated if the GitHub environment has required reviewers	Acceptable; confirm the environment protection rules exist
repo:org/repo:ref:refs/heads/main	Narrow to a branch, but anyone who can push to that branch can obtain tokens	Check branch protection; prefer an environment for write-capable apps
repo:org/repo:pull_request	Broad: GitHub issues this subject for pull request workflows, including from contributors	Should not be trusted by any app with write or admin permissions
Customised subject with only repo, or repository_owner	GitHub warns that including only repo covers all workflows in the repository across branches, tags and environments, and that repository_owner alone covers every repository under the owner	Usually too broad; confirm the organisation or repository subject template
system:serviceaccount:namespace:name	One service account, but anyone who can create pods in that namespace can use it	Check namespace RBAC on the cluster
Flexible expression with matches and a wildcard	Many subjects in one credential, for example every branch of a repository	Confirm it is bound to repository_id (and repository_owner_id where needed); otherwise reject

Flexible federated identity credentials

Flexible federated identity credentials are in preview. Instead of an exact subject they hold a claimsMatchingExpression with a value and a languageVersion of 1. Microsoft documents three operators: eq for exact match, matches for wildcards (* for many characters, ? for one) and and for combining claims. They are supported for GitHub, GitLab and Terraform Cloud issuers, on both applications and user-assigned managed identities.

Binding to immutable IDs: for GitHub, Microsoft requires the expression to match sub and one or both of repository_id and repository_owner_id. Audit that the IDs in the expression are the IDs of your repositories, not just that they are present.
Wildcard review: an expression such as claims['sub'] matches 'repo:contoso/app:ref:refs/heads/*' trusts every branch, including ones created by anyone with push access. Treat it as the equivalent of a branch-wide trust and score it against the app's privileges.
job_workflow_ref: an expression can pin a reusable workflow. This is the strongest GitHub binding available, because the trusted code path is fixed, and it is worth recording as a positive control.
Tooling gap: Microsoft states that Azure CLI, Azure PowerShell and Terraform providers do not yet support flexible credentials and return an error when reading one created through Graph or the portal. An audit script built on those tools may fail or skip the record. Use az rest against Graph beta and the ARM preview API.

GitHub's immutable subject format, repo:OWNER@OWNER-ID/REPO@REPO-ID:..., applies automatically from 15 July 2026 to repositories created, renamed or transferred, while existing repositories keep the name-based format until they opt in. Expect a mix of both formats in the register, and expect a renamed repository's old name-based credentials to stop matching. GitHub notes that the old name-based format could let a recycled namespace produce the same subject value, which is exactly the risk this audit is looking for.

Where identity governance fits

A federated credential is a credential of a non-human identity, so it belongs in the same inventory, ownership and recertification process as secrets and certificates. Three governance points matter:

Who can add them: Microsoft states that anyone who can create an app registration and add a secret or certificate can add a federated identity credential. App owners, Application Developers, Application Administrators and Cloud Application Administrators can therefore create a trust to an issuer they control. Review those assignments as part of the audit. See the Entra ID Applications and Consent Guide.
Restricting managed identity credentials: Microsoft documents an Azure Policy deny rule on the resource type Microsoft.ManagedIdentity/userAssignedIdentities/federatedIdentityCredentials. Apply it with exemptions for the deployment pipelines that are allowed to create trust, so new credentials appear only through reviewed code.
Conditional Access limits: Conditional Access for workload identities can block token requests by location or service principal risk, but only for single-tenant service principals in your tenant, needs Workload Identities Premium licences, and does not cover managed identities. Microsoft suggests access reviews for managed identities instead. See the Azure Managed Identities Security Guide.

Verify it worked

Register complete: the count of credentials in the register equals the sum of Graph (v1.0 plus beta-only flexible records) and ARM listings across every subscription.
Every row owned: each credential maps to a named owner and a source object (repository, environment, cluster service account, cloud service account) that still exists.
Removals clean: after the observation window, no sign-in shows a FederatedCredentialId belonging to a removed credential, and no workload has failed with AADSTS70021 because a needed credential was removed.
Negative test: for each narrowed subject, a run from outside the new scope (another branch, another namespace) is refused. A mismatched subject fails at exchange without a descriptive error, so test the refusal deliberately.

Rollback and common errors

A workload breaks after removal: recreate the credential from the saved JSON with the same issuer, subject and audience. Allow several minutes for replication; early requests fail with AADSTS70021.
Script errors on some apps: likely a flexible credential read through Azure CLI or PowerShell. Switch that read to Graph beta.
409 Conflict when recreating several managed identity credentials: credentials on one identity must be written one at a time; credentials on different identities can be written in parallel.
400 issuer and subject combination already exists: the credential was already recreated, or a duplicate exists under another name. List before retrying.
Region errors for a managed identity: Microsoft lists Malaysia South as not supporting federated credentials on user-assigned managed identities; such identities will show none.

Common failure patterns

Auditing apps only: teams review app registrations in Graph and never list managed identity credentials in ARM, where platform teams create most Kubernetes and pipeline trust.
Trusting a shared issuer without a tight subject: the GitHub issuer is the same for every GitHub customer. A typo or a renamed organisation in the subject can leave trust that a different owner could satisfy under the name-based format.
Pull request subjects on privileged apps: a credential for pull_request on an app with deployment rights lets contributor-supplied workflow code request production tokens.
Orphaned cluster issuers: the cluster was rebuilt with a new OIDC issuer URL, so the old credential is dead, but a test cluster on the same pattern still matches a credential on a privileged identity.
Forgotten test tenants and apps: trust from another tenant's managed identity, or an old test app with live permissions, sits outside every review. Midnight Blizzard used a legacy test tenant OAuth application with elevated access to reach Microsoft corporate mailboxes; see the Microsoft Midnight Blizzard Breach.
Descriptions as the only record: the description is unvalidated free text. An audit that trusts "owned by platform team" without checking the source object proves nothing.

Detection and measurement

Between audits, alert when federated trust changes. For user-assigned managed identities, writes to the federatedIdentityCredentials child resource appear in the Azure Activity log for the subscription. For app registrations, credential changes appear in the Entra audit log under ApplicationManagement; Microsoft's audit activity reference lists credential activities such as Update application - Certificates and secrets management, but does not name a separate federated credential activity, so make a test change in a non-production app and confirm which activity and modified property your tenant records before writing the rule. Detection of new credentials in general is covered in How to detect new credentials added to an app registration.

Metric	Target
Federated credentials with a named owner and a verified source object	100%
Credentials with no sign-in in 90 days	Zero after each audit
Credentials with an issuer not on the approved issuer list	Zero, or each one on an exceptions register with an expiry date
Credentials with pull_request, repo-only or wildcard subjects on apps or identities with write or admin rights	Zero
New credentials created outside approved deployment pipelines	Zero; each investigated
Days since last complete audit	Under 100

Framework mapping

Framework	Reference	Relevance
NIST SP 800-53 Rev 5	IA-5 Authenticator Management; IA-9 Service Identification and Authentication	Federated credentials are the authenticators for service identities and need periodic review
NIST SP 800-53 Rev 5	AC-2 Account Management; AC-6 Least Privilege	Owners, removal of unused trust, narrow subjects against parent privileges
NIST SP 800-53 Rev 5	CM-8 System Component Inventory; AU-6 Audit Record Review, Analysis, and Reporting	The register of credentials and the sign-in join that proves use
NIST CSF 2.0	PR.AA-01; PR.AA-05; DE.CM-03	Service credentials managed; access reviewed; use monitored
MITRE ATT&CK v20	T1098.001 Additional Cloud Credentials; T1078.004 Cloud Accounts; T1199 Trusted Relationship	A rogue federated credential is persistence; a compromised source platform abuses a trust relationship to reach cloud accounts

Practitioner checklist

List app registration credentials from Graph v1.0 and beta, and managed identity credentials from ARM in every subscription.
Build one register with parent, issuer, subject or expression, owner, privileges and source object.
Maintain an approved issuer list and flag every issuer outside it.
Score subject breadth against the parent's privileges; prioritise pull_request, repo-only and wildcard subjects on privileged identities.
Check every flexible credential is bound to your repository_id or repository_owner_id.
Join to sign-in logs by FederatedCredentialId and remove credentials unused for 90 days.
Save credential JSON before any deletion as the rollback record.
Deny managed identity credential creation outside approved pipelines with Azure Policy, and alert on credential changes.

How to audit Entra workload identity federated credentials: find every trust, test it, prune it