> For the complete documentation index, see [llms.txt](https://docs.forestall.io/forestall/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.forestall.io/forestall/edges/azure/az_federated_credential_assigned_to.md).

# 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](https://docs.forestall.io/fsprotect/edges/azure/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](https://docs.forestall.io/fsprotect/edges/azure/az_add_secret)).

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

## Identification

### PowerShell (Microsoft Graph)

```powershell
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](https://docs.forestall.io/fsprotect/edges/azure/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>