{ "api_version": "1", "kind": "dse_post", "self": "https://update.dsesecurity.com/api/v1/posts/entra-risky-workload-identities-investigation/", "item": { "id": "https://update.dsesecurity.com/updates/entra-risky-workload-identities-investigation/", "slug": "entra-risky-workload-identities-investigation", "url": "https://update.dsesecurity.com/updates/entra-risky-workload-identities-investigation/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/entra-risky-workload-identities-investigation.md", "json": "https://update.dsesecurity.com/api/v1/posts/entra-risky-workload-identities-investigation/" }, "title": "Investigate risky workload identities separately from risky users", "summary": "Microsoft Entra ID Protection has workload-identity risk reports and remediation guidance, but workload identities cannot complete user MFA and the documented detection scope excludes some identity types.", "format": { "slug": "playbook", "name": "Playbook" }, "priority": { "slug": "important", "name": "Important" }, "featured": false, "image": { "theme": "identity-cloud", "label": "Identity & cloud", "alt": "Governed cloud identity system with connected service and lifecycle nodes.", "card_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" }, { "slug": "microsoft-365-identity", "name": "Microsoft 365 & Identity", "url": "https://update.dsesecurity.com/topic/microsoft-365-identity/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-08-25T21:35:24+00:00", "modified_at": "2026-08-25T21:36:18+00:00", "reviewed_on": "2026-08-25", "reading_minutes": 3, "word_count": 480, "potentially_affected": "Organizations with Microsoft Entra application registrations and service principals, especially those using workload identity credentials for unattended access.", "dse_recommendation": "Inventory the credential and permissions of each flagged service principal, preserve evidence, contain based on business impact, rotate affected credentials, and verify dependent automation afterward.", "primary_source": { "name": "Securing workload identities", "url": "https://learn.microsoft.com/en-us/entra/id-protection/concept-workload-identity-risk", "published_on": null, "authority": "Microsoft Learn" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "

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.

\n

Source fact: what Microsoft documents

\n

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.

\n

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.

\n

What the source does not establish

\n

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.

\n

Applicability questions

\n\n

DSE recommendation: controlled next steps

\n

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

\n
    \n
  1. Preserve the risk record, sign-in evidence, object identifiers, owners, credentials, permissions, and recent configuration changes before cleanup.
    2. \n
  2. Compare observed IPs, resources, user agents, API calls, and credential use with the application’s documented baseline.
    3. \n
  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. \n
  4. Add a known-good credential using the supported application design, remove all suspect credentials, and rotate reachable secrets or downstream credentials.
    5. \n
  5. Revalidate permissions, owners, automation, and monitoring before dismissing risk or restoring service.
    6. \n
\n

Verification and evidence

\n\n

Official references

\n", "content_text": "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.\nSource fact: what Microsoft documents\nMicrosoft’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.\nMicrosoft 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.\nWhat the source does not establish\nA 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.\nApplicability questions\n\nIs the flagged object a supported single-tenant service principal, a multitenant application, Microsoft SaaS object, or managed identity?\nWhat credentials exist on both application and service-principal objects, and where are copies stored?\nWhich Graph, Azure, Microsoft 365, Key Vault, and third-party permissions can it exercise?\nWhich owners, jobs, applications, and customers depend on it, and what is the containment impact?\nAre the required reports, detail, exports, and Conditional Access controls licensed and available?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\n\nPreserve the risk record, sign-in evidence, object identifiers, owners, credentials, permissions, and recent configuration changes before cleanup.\nCompare observed IPs, resources, user agents, API calls, and credential use with the application’s documented baseline.\nIf 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.\nAdd a known-good credential using the supported application design, remove all suspect credentials, and rotate reachable secrets or downstream credentials.\nRevalidate permissions, owners, automation, and monitoring before dismissing risk or restoring service.\n\nVerification and evidence\n\nRetain exported risk detections, service-principal sign-ins, audit events, credential metadata, and permission assignments.\nRecord every credential and secret rotation without storing secret values in the incident record.\nProve expected jobs succeed with the new credential and old credentials fail.\nDocument unsupported identity types and the separate monitoring used for them.\n\nOfficial references\n\nSecuring workload identities — Microsoft", "content_markdown": "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.\n\n## Source fact: what Microsoft documents\n\nMicrosoft’s [workload-identity risk documentation](https://learn.microsoft.com/en-us/entra/id-protection/concept-workload-identity-risk) 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.\n\nMicrosoft 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.\n\n## What the source does not establish\n\nA 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.\n\n## Applicability questions\n\n- Is the flagged object a supported single-tenant service principal, a multitenant application, Microsoft SaaS object, or managed identity?\n\n- What credentials exist on both application and service-principal objects, and where are copies stored?\n\n- Which Graph, Azure, Microsoft 365, Key Vault, and third-party permissions can it exercise?\n\n- Which owners, jobs, applications, and customers depend on it, and what is the containment impact?\n\n- Are the required reports, detail, exports, and Conditional Access controls licensed and available?\n\n## DSE recommendation: controlled next steps\n\nThe following steps are DSE recommendations based on the cited source.\n\n- Preserve the risk record, sign-in evidence, object identifiers, owners, credentials, permissions, and recent configuration changes before cleanup.\n\n- Compare observed IPs, resources, user agents, API calls, and credential use with the application’s documented baseline.\n\n- 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.\n\n- Add a known-good credential using the supported application design, remove all suspect credentials, and rotate reachable secrets or downstream credentials.\n\n- Revalidate permissions, owners, automation, and monitoring before dismissing risk or restoring service.\n\n## Verification and evidence\n\n- Retain exported risk detections, service-principal sign-ins, audit events, credential metadata, and permission assignments.\n\n- Record every credential and secret rotation without storing secret values in the incident record.\n\n- Prove expected jobs succeed with the new credential and old credentials fail.\n\n- Document unsupported identity types and the separate monitoring used for them.\n\n## Official references\n\n- [Securing workload identities](https://learn.microsoft.com/en-us/entra/id-protection/concept-workload-identity-risk) — Microsoft" }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/entra-risky-workload-identities-investigation/", "url": "https://update.dsesecurity.com/updates/entra-risky-workload-identities-investigation/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-08-25" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/entra-risky-workload-identities-investigation/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Investigate risky workload identities separately from risky users", "item": "https://update.dsesecurity.com/updates/entra-risky-workload-identities-investigation/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/entra-risky-workload-identities-investigation/#article", "identifier": "https://update.dsesecurity.com/updates/entra-risky-workload-identities-investigation/", "url": "https://update.dsesecurity.com/updates/entra-risky-workload-identities-investigation/", "headline": "Investigate risky workload identities separately from risky users", "description": "Microsoft Entra ID Protection has workload-identity risk reports and remediation guidance, but workload identities cannot complete user MFA and the…", "abstract": "Microsoft Entra ID Protection has workload-identity risk reports and remediation guidance, but workload identities cannot complete user MFA and the documented detection scope excludes some identity types.", "articleBody": "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.\nSource fact: what Microsoft documents\nMicrosoft’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.\nMicrosoft 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.\nWhat the source does not establish\nA 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.\nApplicability questions\n\nIs the flagged object a supported single-tenant service principal, a multitenant application, Microsoft SaaS object, or managed identity?\nWhat credentials exist on both application and service-principal objects, and where are copies stored?\nWhich Graph, Azure, Microsoft 365, Key Vault, and third-party permissions can it exercise?\nWhich owners, jobs, applications, and customers depend on it, and what is the containment impact?\nAre the required reports, detail, exports, and Conditional Access controls licensed and available?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\n\nPreserve the risk record, sign-in evidence, object identifiers, owners, credentials, permissions, and recent configuration changes before cleanup.\nCompare observed IPs, resources, user agents, API calls, and credential use with the application’s documented baseline.\nIf 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.\nAdd a known-good credential using the supported application design, remove all suspect credentials, and rotate reachable secrets or downstream credentials.\nRevalidate permissions, owners, automation, and monitoring before dismissing risk or restoring service.\n\nVerification and evidence\n\nRetain exported risk detections, service-principal sign-ins, audit events, credential metadata, and permission assignments.\nRecord every credential and secret rotation without storing secret values in the incident record.\nProve expected jobs succeed with the new credential and old credentials fail.\nDocument unsupported identity types and the separate monitoring used for them.\n\nOfficial references\n\nSecuring workload identities — Microsoft", "datePublished": "2026-08-25T21:35:24+00:00", "dateModified": "2026-08-25T21:36:18+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/entra-risky-workload-identities-investigation/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/entra-risky-workload-identities-investigation/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/identity-cloud-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Investigate risky workload identities separately from risky users" }, "articleSection": [ "Cybersecurity", "IT", "Microsoft 365 & Identity" ], "keywords": [ "Cybersecurity", "IT", "Microsoft 365 & Identity", "Playbook", "Important priority" ], "genre": "Playbook", "about": [ { "@type": "Thing", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "@type": "Thing", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" }, { "@type": "Thing", "name": "Microsoft 365 & Identity", "url": "https://update.dsesecurity.com/topic/microsoft-365-identity/" } ], "wordCount": 480, "timeRequired": "PT3M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "Securing workload identities", "url": "https://learn.microsoft.com/en-us/entra/id-protection/concept-workload-identity-risk" } } ] } }