AZ_FEDERATED_CREDENTIAL_ASSIGNED_TO

Summary

Forestall ACL Alias	AZ_FEDERATED_CREDENTIAL_ASSIGNED_TO
Entra ID (Azure AD) Alias	Federated Identity Credential on Application
Affected Object Types	App Federated Credential -> Application
Edge Direction	AZAppFederatedCredential -> AZApplication
Exploitation Certainty	Informational

Description

AZ_FEDERATED_CREDENTIAL_ASSIGNED_TO connects a federated identity credential (AZAppFederatedCredential) to the App Registration (AZApplication) it belongs to. Federated identity credentials implement workload identity federation: they let an external identity provider's token be exchanged for a token for the application, so an external workload can authenticate as the app without any secret or certificate.

Typical issuers are GitHub Actions (https://token.actions.githubusercontent.com), Kubernetes service accounts, and other OIDC providers. A credential is defined by its Issuer, Subject, and allowed Audiences (usually api://AzureADTokenExchange).

The edge is structural inventory of which federated credentials are attached to which application. It is security-relevant because a federated credential is a trust relationship: anyone who can make the external provider mint a token matching the configured issuer and subject can authenticate as the application, and therefore as the service principal it runs as (see AZ_RUNS_AS). An overly broad subject (for example a wildcard branch or environment) widens who can assume the identity, and adding a new federated credential is a stealthy, secretless persistence technique (modelled alongside AZ_ADD_SECRET).

The node carries Name, Issuer, Subject, Audiences, and Description.

Identification

PowerShell (Microsoft Graph)

Connect-MgGraph -Scopes "Application.Read.All"

Get-MgApplication -All | ForEach-Object {
    $app = $_
    Get-MgApplicationFederatedIdentityCredential -ApplicationId $app.Id -ErrorAction SilentlyContinue |
      ForEach-Object {
        [PSCustomObject]@{
            AppName   = $app.DisplayName
            AppId     = $app.AppId
            Name      = $_.Name
            Issuer    = $_.Issuer
            Subject   = $_.Subject
            Audiences = ($_.Audiences -join ', ')
        }
      }
} | Format-Table -AutoSize

Azure Portal

1. Open Microsoft Entra admin center -> App registrations -> select the application.

2. Open Certificates & secrets -> Federated credentials to review issuer, subject, and audience for each credential.

Exploitation

There is no direct exploit for this edge; it inventories an existing trust. Abuse requires controlling the external workload that matches the credential's issuer and subject, or adding a new federated credential to the application (a secretless persistence path), after which the attacker obtains tokens as the app and abuses the service principal it runs as (AZ_RUNS_AS). Watch especially for broad or wildcard subjects that let more external identities assume the app.

Mitigation

• Inventory federated credentials and confirm each issuer/subject pair is expected.

• Scope subjects as tightly as possible (specific repo, branch, environment, or service account) and avoid wildcards.

• Restrict who can add credentials to applications and monitor for new federated credential additions.

• Apply least privilege to the service principal the application runs as.

Detection

Use the Microsoft Entra admin center:

1. Open Microsoft Entra ID -> Audit logs.

2. Filter Activity for application updates that add or change federated identity credentials.

3. Review Initiated by (actor), Target (the application), Date, and Status for unexpected changes.

4. Review sign-in logs for the affected service principal to spot token exchange from unexpected issuers.

References

• https://learn.microsoft.com/en-us/graph/api/resources/federatedidentitycredential

• https://learn.microsoft.com/en-us/entra/workload-id/workload-identity-federation

• https://learn.microsoft.com/en-us/entra/identity-platform/app-objects-and-service-principals