Investigate risky workload identities separately from risky users

Bottom line: A workload identity is not a user account. It cannot respond to MFA, may use stored credentials, and often lacks a formal lifecycle. Microsoft Entra ID Protection provides workload-identity risk detections and reports for supported service principals, but its scope and licensing differ from user-risk protection.

Source fact: what Microsoft documents

Microsoft’s workload-identity risk documentation describes detections based on sign-in behavior and offline indicators. Documented examples include Microsoft Entra threat intelligence, suspicious sign-ins, and suspicious API traffic. Administrators can review risky workload identities and workload-identity risk detections or query the corresponding Microsoft Graph collections.

Microsoft states that the feature’s risk scope covers specified application and service-principal scenarios and that managed identities are not currently in scope. Full risk detail and risk-based access controls have licensing requirements. Conditional Access for workload identities can block selected service principals marked at risk, but documented resource and identity limitations apply. Microsoft’s remediation sequence includes inventorying credentials, adding a new credential, removing compromised credentials, and rotating Key Vault secrets the identity could access.

What the source does not establish

A risk detection is not proof that an application was compromised, and the absence of a detection is not proof that a workload identity is safe. The feature does not inventory all secrets, certificates, federated credentials, API keys, managed identities, permissions, or downstream sessions. Disabling a service principal can interrupt business services, while rotating only one credential may leave other persistence intact.

Applicability questions

• Is the flagged object a supported single-tenant service principal, a multitenant application, Microsoft SaaS object, or managed identity?
• What credentials exist on both application and service-principal objects, and where are copies stored?
• Which Graph, Azure, Microsoft 365, Key Vault, and third-party permissions can it exercise?
• Which owners, jobs, applications, and customers depend on it, and what is the containment impact?
• Are the required reports, detail, exports, and Conditional Access controls licensed and available?

DSE recommendation: controlled next steps

The following steps are DSE recommendations based on the cited source.

1. Preserve the risk record, sign-in evidence, object identifiers, owners, credentials, permissions, and recent configuration changes before cleanup.
2. Compare observed IPs, resources, user agents, API calls, and credential use with the application’s documented baseline.
3. If compromise is plausible, contain according to consequence: disable the service principal or restrict its access when operationally safe, and coordinate an outage path when it is not.
4. Add a known-good credential using the supported application design, remove all suspect credentials, and rotate reachable secrets or downstream credentials.
5. Revalidate permissions, owners, automation, and monitoring before dismissing risk or restoring service.

Verification and evidence

• Retain exported risk detections, service-principal sign-ins, audit events, credential metadata, and permission assignments.
• Record every credential and secret rotation without storing secret values in the incident record.
• Prove expected jobs succeed with the new credential and old credentials fail.
• Document unsupported identity types and the separate monitoring used for them.

Official references

• Securing workload identities — Microsoft