Workload identities; from Attack to Defense with Microsoft Security

8 min readJul 5, 2025

Workload identities in Microsoft Entra are non-human identities assigned to a software workload (e.g. application, service or script) to authenticate, authorize and access the Microsoft Entra Tenant (Microsoft Graph) and/or Azure (RBAC) subscription(s).

Introduction

This chapter explains the different types of workload identities and their usage in the Microsoft Entra Tenant.

Microsoft Entra ID Applications consists of the following types:

Application Registration is the blueprint (registration of the app in Entra) of the application in Entra ID defining settings like single- or multi-tenant, Application (Client) ID, certificates or secret(s) and API (Microsoft Graph) permissions.
Enterprise Application, also called Service Principal, is an instance of the Application in a specific Microsoft Entra Tenant.
Managed Identity is a special type of service principal for Azure resources (out-of-scope of this blog because the Security Tools described do not support this type of service principal).

API Permissions

API Permissions are available in two types of permissions:

Delegated permissions (access on behalf of user) are used in the context of the signed-in user, but with access limited by the selected permission. This type of permission can be granted by a user unless the permission is configured as requiring administrator consent.
For example, take an application that is granted the Files.Read.All delegated permission on behalf of the user. The application is only able to read files that the user can personally access.

For example: User Consent (bypass MFA / Conditional Access) can be abused by bad actors via phishing mail to get access to the mailbox of the user via the permissions Mail.Read

Application permissions (access without user) are used autonomous by the application (no user context). This type of permission requires administrator consent.
For example, an application granted the Microsoft Graph API’s application permission Files.Read.All is able to read any file in the tenant using Microsoft Graph. In general, only an administrator or owner of an API's service principal can consent to application permissions exposed by that API.

The permissions are categorized by Workload (e.g. User or Mail) and subdivided in Type and optional Scope, for example Mail.Read orUser.ReadWrite.All

Consent

Consent grants applications permissions and access to protected resources. First time access shows the consent page (example below via graph explorer) which request permissions and access is be granted via Accept.

There are two types of consent:

User Consent happens when the user sign into the application with their user sign-in credentials and consent was not granted before by user or admin. Again this is often abused via phishing mail containing ‘links to OneDrive documents’ to trick the user and gain unauthorized access to the mailbox and bypassing security controls like MFA.

OAuth App Consent permissions bypass security controls like Conditional Access so always disable User App Consent which will be the default setting juli/august 2025 [MC1097272] for 3P Applications.

Admin Consent is required for global and high priviliged permissions which can harm the organization. Admin consent are for the entire organization.

The table below is an overview of High Priviliged permissions in the Microsoft Graph API.

High Priviliged Microsoft Graph Permissions

As we can see applications (service principals) can be harmful and securing them (or against them) is very important because of the lack of understanding and security controls like MFA.

Single- versus Multi-tenant Security

Microsoft Entra Workload ID protects single-tenant service principals (enterprise applications) which can be abused by stealing credentials and gain unauthorized access to the Microsoft Tenant and/or Azure resources via the API permissions.

Microsoft Defender for Cloud Apps protects against multi-tenant enterprise applications (service principals) which can be abused via phishing and OAuth App Consent attacks.

Both security solutions can run in the same tenant.

Microsoft Entra Workload ID

Service principals can be (ab)used to access resources via the ClientID (username) and ClientSecret (password) in the Microsoft Tenant (Microsoft Graph) and/or Azure (Azure RBAC / IAM) subscription bypassing Security Controls like MFA (Conditional Acces).

Service Principal Microsoft Graph Access via ClientID & ClientSecret

Microsoft Entra Workload ID is a premium license ($3 per workload identity/month) and a set of security controls focused on protecting Workload identities.

In-scope of Workload identities for Entra Workload ID are service principals. managed identities are not supported.

The Security controls in Microsoft Entra Workload ID are

ID Protection
Conditional Access
Access Reviews
App Health

ID Protection

ID Protection for workload identities protects service principals from lost or stolen credentials (ClientID and ClientSecret).

Certificates are more secure from a Security perspective than Client Secrets (password).

The following detections are available:

Microsoft Entra Threat Intelligence; risk detection indicates some activity that is consistent with known attack patterns based on Microsoft’s internal and external threat intelligence sources.
Suspicious Sign-ins; risk detection indicates sign-in properties or patterns that are unusual for this service principal.
Leaked Credentials; risk detection indicates that the account’s valid credentials leaked.
Malicious application; detection combines alerts from ID Protection and Microsoft Defender for Cloud Apps to indicate when Microsoft disables an application for violating our terms of service.
Suspicious application; detection indicates that ID Protection or Microsoft Defender for Cloud Apps identified an application that might be violating our terms of service but hasn’t disabled it.
Anomalous service principal activity; risk detection baselines normal administrative service principal behavior in Microsoft Entra ID, and spots anomalous patterns of behavior like suspicious changes to the directory
Suspicious API traffic; risk detection is reported when abnormal GraphAPI traffic or directory enumeration of a service principal is observe

Leaked Credentials

For example if credentials are stored in a public repositories like GitHub, they can be discovered with tools like GitLeaks, GitGuardian or GitHubscanner.

ID Protection for workload identities detects Leaked credentials from service principals stored in GitHub (public repo).

The service principal is classified as risk level: high risk (compromised service principal).

Conditional Access

By default (without the premium license), Conditional Access policies can only be assigned to users or groups. When the premium license is enabled, workload identies are available in the assignment list.

A Conditional Access Policy can be created for service principals: risk- or location-based access policies (e.g. block risk level: high risk).

Conditional Access Policy to Block High Risk Service Principal

By blocking high risk service principals via Conditional Access, we can prevent malicious abuse of the service principal permissions if the credentials are compromised.

Access Reviews

Entra workload Access Reviews is a security practice in Microsoft Entra ID, ensuring that non-human identities (service principals) have only the necessary permissions to access resources to mitigate the risk of over-privileged identities and/or potential security breaches, aligning with the principle of least privilege.

Setup of Access Reviews for Azure Resources (Service Principals) is configured via Priviliged Identity Management.

Setup of Access Reviews for Service Principals

The reviewer(s) gets an e-mail to approve or deny the permissions and/or role of service principal(s).

App Health

Microsoft Entra recommendations (part of Identity Secure Score) provides Security recommendations for workload identity governance to keep the service principal security baseline secure. The portal is visible via the Recommendationssection of the Identity overview page in Entra

Security Recommendation for Service Principal

Microsoft Entra Workload ID adds four recommendations for service principals:

Renew expiring application credentials provides an overview of all app registrations with expiring credentials (e.g. ClientSecret which is time-bound)
Renew expiring service principal credentials provides an overview of all enterprise applications with expiring credentials (e.g. Certificate which is time-bound)
Remove unused credentials from applications provides an overview of applications with credentials not used in more than 30 days
Remove unused applications provides an overview of all applications not used for the last 90 days

Defender for Cloud | App Governance

Tools like 365-stealer or o365-attack-toolkit abuse OAuth App Consent and compromise the Entra ID to steal data from Email, OneDrive, OneNote, etc. by accessing a ‘Microsoft’ website and the user Consent(attack tool is configured with Delegated Permissions in the context of the signed-in user).

Microsoft Defender for Cloud Apps is part of the Microsoft 365 E5 license and does not require the premium license. One of the features is App Governance which provices insights, governance, detection and remedation of OAuth-enabled applications in the Microsoft Tenant.

Enable App Governance in the Defender XDR portal settings -> Cloud Apps -> App Governance, also a requirement for Automatic Attack Disruption.

Microsoft 365
App Governance provides an overview (insights) in all Microsoft 365 enterprise applications in the Microsoft Tenant. An initial filter for suspicious apps with high priviliges:

Privilege level: High
App origin: External
Publisher verified: No

App Origin: External is a multi-tenant application from outside your tenant.

Publisher verified: No is an application without verified publisher from Microsoft via MPN (Microsoft Partner Network)

These filter settings provides an overview of all possible high risk ‘suspicious / malicious’ apps used in the organization including information about Graph API access, Permisions type (Delegated or Application), Consent (User or Admin) and Data usage. If the application is malicious, it can be disabled from the portal (governance).

Policies
We can also create Policies to be alerted (detection) when new suspicious applications (same filter conditions as above) are added to the Microsoft tenant. An option is to add Actions to Disable the App (remediation).

Microsoft Defender XDR

The result of the App Governance Policy is a Microsoft Defender XDR Incident if a suspicious app is added to the Microsoft Tenant (via User Consent).

I hope this blog gives more insights in service principals and how to secure the environment against threats like credentials compromise for internal applications and OAuth App consent phishing via external applications.