Entra federated identity credential added
A FEDERATED IDENTITY CREDENTIAL was added to an Entra application or service principal — workload identity federation, which lets an EXTERNAL issuer mint…
What it detects
A FEDERATED IDENTITY CREDENTIAL was added to an Entra application or service principal — workload identity federation, which lets an EXTERNAL issuer mint tokens for this identity.
This is not the same backdoor as a client secret, and it is quieter. No credential is stored in the tenant, so there is nothing to find in a secrets review and nothing to expire: the trust is a subject claim pointing at an outside workload (a GitHub Actions repo, a Kubernetes service account, another cloud's OIDC issuer). Anyone who controls that external subject can obtain tokens for the application indefinitely, without a password and without MFA. Rotating every secret in the tenant does not remove it.
The pack already alerts on secret and certificate additions (m365_app_credential_added), but those key on the credential-management operations. In the Entra audit log this arrives as a plain Update service principal whose changed property is FederatedIdentityCredentials, so it did not match — the operation name says nothing about credentials.
Read the SUBJECT: it names exactly which external workload was trusted.
MITRE ATT&CK mapping
False positives and triage
Workload identity federation is a legitimate and recommended pattern — teams adopting it to remove long-lived secrets from CI/CD will produce this, usually in a short burst while pipelines are wired up and then rarely again.
Escalate on the subject and the actor rather than on the event itself: an issuer that is not your CI/CD platform, a subject naming a repository or organization outside your own (repo:someone-else/…), a credential added to a high-privilege application (Directory.*, Mail.*, full_access_as_app), or an addition by an account that does not normally administer applications. A federated credential added shortly after a suspicious sign-in by the same actor is the strong case.
The rule
Declarative YAML read by the detection engine — data, never executed. Confidence 70%. Source: rules/cloud/entra_federated_identity_credential_added.yaml, licensed under the Apache License 2.0.
id: cloud.identity.entra_federated_identity_credential_added
version: 1.0.0
status: stable
severity: high
confidence: 0.7
platforms: [application]
mitre_techniques: [T1098.001, T1078.004]
description: |
A FEDERATED IDENTITY CREDENTIAL was added to an Entra application or service
principal — workload identity federation, which lets an EXTERNAL issuer mint
tokens for this identity.
This is not the same backdoor as a client secret, and it is quieter. No
credential is stored in the tenant, so there is nothing to find in a secrets
review and nothing to expire: the trust is a subject claim pointing at an
outside workload (a GitHub Actions repo, a Kubernetes service account, another
cloud's OIDC issuer). Anyone who controls that external subject can obtain
tokens for the application indefinitely, without a password and without MFA.
Rotating every secret in the tenant does not remove it.
The pack already alerts on secret and certificate additions
(`m365_app_credential_added`), but those key on the credential-management
operations. In the Entra audit log this arrives as a plain
`Update service principal` whose changed property is
`FederatedIdentityCredentials`, so it did not match — the operation name says
nothing about credentials.
Read the SUBJECT: it names exactly which external workload was trusted.
match:
provider_any: [AzureAD, Office365]
event_action_contains_any:
- "Update service principal"
- "Update application"
raw_message_contains_any:
- "FederatedIdentityCredentials"
- "federatedIdentityCredentials"
correlation_keys: [user_name, target_user_name]
false_positive_guidance: |
Workload identity federation is a legitimate and recommended pattern — teams
adopting it to remove long-lived secrets from CI/CD will produce this, usually
in a short burst while pipelines are wired up and then rarely again.
Escalate on the subject and the actor rather than on the event itself: an issuer
that is not your CI/CD platform, a subject naming a repository or organization
outside your own (`repo:someone-else/…`), a credential added to a
high-privilege application (Directory.*, Mail.*, full_access_as_app), or an
addition by an account that does not normally administer applications. A
federated credential added shortly after a suspicious sign-in by the same actor
is the strong case.
Related detections
Run this rule on your own logs — offline
KIROSEC runs this rule and the rest of the library over Windows, Linux, macOS and cloud audit logs on the analyst's own machine. Every alert links to the events that raised it, and nothing leaves the device.