Add Federated Identity Credential
Add Federated Identity Credential
Event
Adds a federated identity credential to an application registration, configuring trust in an external workload identity. In the subject-based configuration illustrated here, an externally issued token must satisfy the configured issuer, subject, and audience checks before it can be exchanged for an Entra access token. Adding this trust does not itself grant API permissions or Azure resource roles.
Security Context
An unauthorized trust can add an authentication path to an existing application (T1098.001). Legitimate CI/CD commonly uses workload federation. Rotating a separate client secret does not remove the federated trust, but this does not make federation unlogged or immune to access controls. The public GitHub issuer is shared infrastructure; the repository/subject configuration and who controls the workload determine the risk.
Log Source
Microsoft Entra directory audit logs, ApplicationManagement category. This page title describes the change, not a guaranteed activityDisplayName. Microsoft lists Update application - Certificates and secrets management; the illustrative sample uses that label, but the exact activity and FederatedIdentityCredentials modified-property representation must be verified against tenant logs. Correlate application changes with service-principal sign-in records and resource audit evidence; configuration success is not token-exchange success.
Key Fields
| Field | Investigation value |
|---|---|
initiatedBy, result, resultReason | Actor and recorded outcome; verify authority independently. |
targetResources[].id | Application object ID; distinguish it from client ID and tenant service-principal ID. |
targetResources[].modifiedProperties | Prior/new trust where available; parse embedded JSON and compare issuer, subject, audiences, and name. |
activityDateTime, correlationId | Timeline and related change records. |
What to Investigate
- Verify change approval, the actor’s effective application-management permission, and any preceding ownership change.
- Compare the resulting trust with the intended external workload. For the GitHub branch subject shown, inspect repository control, branch protections, workflow token permissions, and actual subject customization; environment and pull-request contexts can produce different subjects.
- Resolve the application’s service principal and effective app-role/Azure role assignments. Trust creation is an authentication change, not a new authorization grant.
- Correlate external workflow runs, service-principal sign-ins, and resource operations. If unauthorized, include the federated trust in containment planning; client-secret rotation alone does not remove it.
Sample Event
Synthetic scenario. The example adds a trust for a GitHub repository’s main-branch subject. Repository ownership, control of a matching workload, a successful token exchange, and subsequent access are not established by this record. The branch subject does not identify a unique workflow file.
Exact activity labeling, modified-property naming, target ordering, and serialization remain unverified against captured logs. The sample is illustrative and is not a guaranteed detection schema.
{ "id": "Directory_90000000-0000-4000-8000-000001100110_9D2C4_71832055", "category": "ApplicationManagement", "correlationId": "90000000-0000-4000-8000-000001100110", "result": "success", "resultReason": "", "activityDisplayName": "Update application - Certificates and secrets management", "activityDateTime": "2026-04-15T18:33:07.4419006Z", "loggedByService": "Core Directory", "operationType": "Update", "initiatedBy": { "app": null, "user": { "id": "30000000-0000-4000-8000-001010011010", "displayName": "Draco Malfoy", "userPrincipalName": "draco@fantasticlogs.cloud", "ipAddress": "203.0.113.66" } }, "targetResources": [ { "id": "40000000-0000-4000-8000-001010011010", "displayName": "BoggartImpersonator", "type": "Application", "userPrincipalName": null, "groupType": null, "modifiedProperties": [ { "displayName": "FederatedIdentityCredentials", "oldValue": "[]", "newValue": "[{\"name\":\"github-persistence\",\"issuer\":\"https://token.actions.githubusercontent.com\",\"subject\":\"repo:draco-org/persistence-runner:ref:refs/heads/main\",\"audiences\":[\"api://AzureADTokenExchange\"],\"description\":\"GitHub Actions token exchange\"}]" }, { "displayName": "Included Updated Properties", "oldValue": null, "newValue": "\"FederatedIdentityCredentials\"" } ] } ], "additionalDetails": [ { "key": "User-Agent", "value": "python/3.11.6 (Linux-5.15.0-1052-aws-x86_64-with-glibc2.35) AZURECLI/2.56.0 (DEB)" } ]}Sources
MITRE ATT&CK Mapping
Tactics: Persistence
- T1098.001 — Additional Cloud Credentials — Adversaries may add adversary-controlled credentials to a cloud account to maintain persistent access to victim accounts and instances within the environment.