Non-Human Identity Security Management in Microsoft Entra ID
Non-human identity security management in Microsoft Entra ID: attack paths for service principals, managed identities, and AI agents.
Table of Contents
Stop AD Threats As They Happen
Cayosoft Protector provides continuous monitoring and real-time alerts across your entire Microsoft Identity stack
Like This Article?
Subscribe to our LinkedIn Newsletter to receive more educational content
Non-human identities have become one of the most important and least understood identity security risks in Microsoft Entra ID. App registrations, service principals, managed identities, enterprise applications, workload identities, and AI agents can authenticate without a person, hold persistent permissions, and act across Microsoft 365, Azure, and directory resources.
The risk is not that these identities exist. Modern environments depend on them. The risk is that many of them are overprivileged, unowned, unmonitored, or protected by controls designed for human users. A single client secret, certificate, OAuth consent grant, service principal role, managed identity token, or agent identity can become a path to privilege escalation, data access, or tenant compromise.
Purpose: This guide explains how non-human identities become attack paths in Microsoft Entra ID and how defenders can reduce and detect that risk. It focuses on practical controls, known abuse patterns, Microsoft Sentinel detection examples, and Cayosoft Guardian detections for real-time monitoring of identity changes.
What you will learn: How to identify risky app registrations and service principals, which Microsoft Graph permissions matter most, how OAuth consent and credential abuse work, where managed identities and AI agents expand the attack surface, and which logs and detections help security teams monitor these risks.
What non-human identity security management covers
Scope: Non-human identity security management covers the discovery, governance, hardening, monitoring, and recovery of identities that authenticate without a person directly signing in. In Microsoft Entra ID, that includes app registrations, service principals, managed identities, enterprise applications, workload identities, and AI agents.
Why it matters: Most identity programs were built for people. They enforce multifactor authentication, Conditional Access, password policy, device compliance, and user lifecycle controls. Non-human identities do not work that way. They may hold credentials, roles, consent grants, or application permissions that rival administrator access, but they often lack clear ownership, expiration, access reviews, and real-time monitoring.
Who should use this guide
This guide is written for teams responsible for protecting the Microsoft identity control plane, including identity administrators, security operations teams, cloud security architects, incident responders, and risk, audit, or compliance teams. It is intended to help both deep identity practitioners and broader security stakeholders understand where non-human identity risk comes from and what to monitor first.
What non-human identities include in Microsoft Entra ID
Definition: A non-human identity is any application, workload, automation, service, or agent identity that authenticates without a person directly signing in. In Microsoft Entra ID, that definition includes app registrations, service principals, managed identities, enterprise applications, workload identities, and AI agent identities.
Core concepts defenders must understand
Identity type | What it is | Why defenders should care |
App registration | The application blueprint that defines the app identity, requested permissions, redirect URIs, secrets, certificates, and authentication configuration. | Risky configuration or overbroad requested permissions can create future abuse paths. |
Service principal | The local tenant identity for an application where granted permissions and credentials often live. | This is often the object attackers target because it can authenticate and act with application permissions. |
Managed identity | An Azure-managed service principal used by workloads such as virtual machines, functions, applications, and automation. | It reduces stored secret risk, but overprivileged managed identities can still be abused if the workload is compromised. |
Enterprise application | The tenant-local representation of an application that has been added or consented to, including third-party SaaS apps. | These applications can retain ongoing access to Microsoft 365 or directory data after the original business need changes. |
Workload identity | An identity used by software, services, automation, or cloud workloads to authenticate and perform work. | These identities operate continuously and often do not follow normal user lifecycle controls. |
Agent identity | An identity assigned to an AI agent so it can authenticate, access data, call tools, and act autonomously. | Agents can act quickly across connected systems, so they need the same governance as other privileged workload identities. |
Which Microsoft Graph permissions create the most risk
Some Microsoft Graph permissions create more risk than others because they allow an application to change directory roles, assign app permissions, modify applications, write across directory objects, or change domain trust settings. These permissions should be treated as high-impact control-plane access and reviewed before they are granted to any non-human identity.
RoleManagement.ReadWrite.Directory: This permission allows an application to manage directory roles and can create a path to Global Administrator if abused. Defenders should restrict it heavily, review every holder, and alert when it is granted, changed, or used by a service principal.
AppRoleAssignment.ReadWrite.All: This permission allows an application to assign app roles, including permissions on Microsoft Graph. In the wrong hands, it can let a service principal grant itself or another app broader access without a normal human approval path.
Application.ReadWrite.All: This permission allows an application to modify app registrations and service principals. A compromised identity with this permission may be able to add a new secret or certificate to a powerful application and then authenticate as that application.
Directory.ReadWrite.All: This permission provides broad write access across directory objects such as users, groups, and other identity resources. Defenders should require a clear business justification, remove it where possible, and monitor any non-human identity that holds it.
Domain.ReadWrite.All: This permission can modify domain settings that influence authentication and trust. Because federation and domain configuration changes can affect which tokens are trusted, this permission should be restricted and monitored for any domain or federation-related change.
How attackers abuse OAuth consent grants
Attack path: An attacker controls an application that asks for broad Microsoft Graph permissions. A phishing lure sends the user to a legitimate OAuth consent screen. If the user accepts, the application receives tokens and persistent access to mail, files, and directory data. Resetting the user’s password or multifactor authentication does not remove that access because the grant belongs to the application, not the user session.
Mitigate: Restrict user consent so regular users cannot approve privileged or unverified applications. Enable the admin consent workflow so users can request access without directly granting it. Limit who can register applications, who can add application owners, and which third-party applications are trusted. Existing OAuth permission grants should be reviewed regularly so unused, excessive, or unowned grants can be removed.
Detect: Monitor Microsoft Entra audit logs for new consent-to-application events, delegated permission grants, and app role assignments. Pay special attention to unverified applications, consent grants issued by non-admin users, and applications receiving broad Microsoft Graph permissions for mail, files, directory data, or application access. If suspicious consent is found, revoke the grant, disable or remove the application if it is not legitimate, and review the data accessed by the app.
Microsoft Sentinel example: New OAuth consent grant in AuditLogs.
AuditLogs
| where TimeGenerated > ago(24h)
| where Category =~ "ApplicationManagement"
| where OperationName has_any (
"Consent to application",
"Add delegated permission grant",
"Add app role assignment to service principal"
)
| where Result =~ "success"
| extend ActorUser = tostring(InitiatedBy.user.userPrincipalName)
| extend ActorApp = tostring(InitiatedBy.app.displayName)
| extend Actor = iif(isnotempty(ActorUser), ActorUser, ActorApp)
| mv-expand TargetResources
| extend TargetName = tostring(TargetResources.displayName)
| extend TargetType = tostring(TargetResources.type)
| extend TargetId = tostring(TargetResources.id)
| project TimeGenerated, OperationName, Actor, TargetName, TargetType, TargetId, Result
Cayosoft Guardian detection: Microsoft Entra tenant where regular users can register applications.
How a privileged service principal becomes an attack path
Attack path: A user owns an application whose service principal holds a privileged directory role. If that user or session is compromised, the attacker can add a client secret, sign in as the application, and operate with the service principal’s privileges instead of the user’s. That can lead to administrator password resets, Temporary Access Pass creation, MFA bypass, and tenant control.
Mitigate: Avoid assigning privileged directory roles such as Privileged Authentication Administrator or Global Administrator to service principals unless there is a narrowly justified exception. Remove standing owners from privileged applications, tightly govern credential additions, and constrain Temporary Access Pass policies to short lifetimes and tightly scoped users.
Detect: Review service principals assigned to privileged directory roles and alert when a secret or certificate is added to an application with elevated access. Monitor administrator password resets, Temporary Access Pass creation, new app-only sign-ins, and ownership changes that occur near credential or role changes. If abuse is suspected, remove the unauthorized credential, revoke active tokens where possible, and validate whether administrative accounts were reset or issued a Temporary Access Pass.
Microsoft Sentinel example: Service principal credential or role activity in AuditLogs.
AuditLogs
| where TimeGenerated > ago(7d)
| where Category has_any (
"ApplicationManagement",
"RoleManagement"
)
| where OperationName has_any (
"Add service principal credentials",
"Add member to role",
"Add eligible member to role"
)
| where Result =~ "success"
| extend ActorUser = tostring(InitiatedBy.user.userPrincipalName)
| extend ActorApp = tostring(InitiatedBy.app.displayName)
| extend Actor = iif(isnotempty(ActorUser), ActorUser, ActorApp)
| mv-expand TargetResources
| extend TargetName = tostring(TargetResources.displayName)
| extend TargetType = tostring(TargetResources.type)
| project TimeGenerated, OperationName, Actor, TargetName, TargetType, Result
Cayosoft Guardian detection: Entra ID application owner attribute populated with a hybrid user account; Microsoft Entra app with client secrets.
How app role assignments can lead to Global Administrator access
Attack path: A leaked certificate or secret exposes a service principal with AppRoleAssignment.ReadWrite.All. The attacker uses that permission to grant the service principal additional high-risk Microsoft Graph permissions, then adds it to a privileged directory role. The escalation can happen through app-only calls without a human approval step.
Mitigate: Treat AppRoleAssignment.ReadWrite.All and RoleManagement.ReadWrite.Directory as high-impact permissions. Require explicit approval for new high-privilege app role assignments, shorten the lifetime of secrets and certificates, and use just-in-time administrative workflows for changes that involve service principals.
Detect: Monitor app role assignment events that involve high-privilege Microsoft Graph permissions. Pay particular attention to self-grant patterns where a service principal grants itself additional access, directory role changes that add service principals, and newly active credentials on identities that already hold elevated permissions. If a self-grant occurred, remove the unauthorized assignment, rotate exposed credentials, and validate downstream administrative activity.
Microsoft Sentinel example: High-risk Microsoft Graph permission granted.
AuditLogs
| where TimeGenerated > ago(7d)
| where Category =~ "ApplicationManagement"
| where OperationName has_any (
"Consent to application",
"Add app role assignment to service principal",
"Add delegated permission grant"
)
| extend RawDetails = tostring(TargetResources)
| where RawDetails has "RoleManagement.ReadWrite.Directory"
or RawDetails has "AppRoleAssignment.ReadWrite.All"
or RawDetails has "Application.ReadWrite.All"
or RawDetails has "Directory.ReadWrite.All"
or RawDetails has "Domain.ReadWrite.All"
| extend ActorUser = tostring(InitiatedBy.user.userPrincipalName)
| extend ActorApp = tostring(InitiatedBy.app.displayName)
| extend Actor = iif(isnotempty(ActorUser), ActorUser, ActorApp)
| project TimeGenerated, OperationName, Actor, RawDetails
Cayosoft Guardian detection: Microsoft Entra app with risky write permissions.
How first-party service principal hijacking can affect Exchange Online
Attack path: An actor with Application.ReadWrite.All can add a credential to a powerful first-party service principal, such as Exchange Online. If that identity carries broad directory or domain privileges, the attacker may be able to abuse built-in trust, change federation configuration, forge tokens, and impersonate privileged users without knowing their passwords.
Mitigate: Limit Application Administrator and Application.ReadWrite.All to a small trusted set of administrators. First-party service principals with elevated built-in privileges should be monitored closely, and changes to federation settings, domain authentication configuration, and token-signing material should require privileged access workflows and clear change control.
Detect: Alert when credentials are added to first-party or highly privileged service principals. Monitor new federated domains, changes to domain authentication settings, unexpected token-signing certificate changes, unusual Security Assertion Markup Language token activity, and administrative actions that occur without normal interactive sign-in context. If suspicious changes are found, remove unauthorized credentials, restore trusted federation settings, and review whether privileged users were impersonated.
Microsoft Sentinel example: Federation or domain authentication change in AuditLogs.
AuditLogs
| where TimeGenerated > ago(7d)
| where Category has_any (
"DomainManagement",
"DirectoryManagement"
)
or OperationName has_any (
"Add domain",
"Update domain",
"Set domain authentication",
"Update federation settings"
)
| extend ActorUser = tostring(InitiatedBy.user.userPrincipalName)
| extend ActorApp = tostring(InitiatedBy.app.displayName)
| extend Actor = iif(isnotempty(ActorUser), ActorUser, ActorApp)
| mv-expand TargetResources
| extend TargetName = tostring(TargetResources.displayName)
| extend TargetType = tostring(TargetResources.type)
| project TimeGenerated, OperationName, Actor, TargetName, TargetType, Result
Cayosoft Guardian detection: Unauthorized certificate addition to Entra ID Enterprise Application; Modified federation settings in Microsoft Entra domain.
What OAuth client ID spoofing and ROPC abuse mean for defenders
Attack path: OAuth client ID spoofing abuses legacy authentication behavior to test whether usernames and passwords are valid. In these attempts, attackers may use an unknown or spoofed OAuth client ID with the Resource Owner Password Credentials flow. Because some activity may not appear as normal named-application sign-ins, detections that only watch known applications can miss the behavior.
Mitigate: Block legacy authentication and Resource Owner Password Credentials flows wherever possible. Require modern authentication, strengthen risk-based access policies, and reduce password-based dependencies in automation or legacy integrations so attackers have fewer opportunities to validate credentials through older flows.
Detect: Monitor sign-in records with missing, blank, unknown, or unusual application names, especially when they appear with repeated failures, many targeted users, shared source IP addresses, or Microsoft Entra error-code patterns. These signals can indicate that an attacker is testing which accounts exist or which passwords are valid. If confirmed, investigate the affected users, source IP addresses, result codes, and application identifiers, then tune detections so blank or unusual application names are not excluded.
Microsoft Sentinel example: Blank or missing application name during sign-in.
SigninLogs
| where TimeGenerated > ago(24h)
| where isempty(AppDisplayName)
or AppDisplayName =~ "Unknown"
| summarize Attempts = count(), DistinctUsers = dcount(UserPrincipalName), ResultCodes = make_set(ResultType), SampleUsers = make_set(UserPrincipalName, 10)
by IPAddress, AppId, AppDisplayName
| where Attempts > 20
or DistinctUsers > 5
| order by Attempts desc
Cayosoft Guardian detection: Microsoft Entra ID account enumeration via unknown OAuth client ID.
How managed identities can be taken over
Attack path: An attacker compromises a workload, such as an app, virtual machine, Function, container, or service that has a managed identity. From that host, the attacker requests a token from the local metadata endpoint and uses the managed identity’s permissions to access Azure resources, read secrets, or change roles. Removing stored secrets improves hygiene, but it does not remove privilege risk.
Mitigate: Grant managed identities only the roles required for the workload and avoid assigning broad permissions such as Owner, Contributor, RoleManagement, or high-impact Microsoft Graph permissions by default. Harden the host that carries the identity, because a workload compromise can quickly become an identity compromise.
Detect: Monitor managed identity token usage for unusual resources, source IP addresses, regions, or time windows. Watch for new Azure role assignments, Microsoft Graph app-role grants involving workload identities, unusual Key Vault secret reads, and workloads whose permissions no longer match observed behavior. If abuse is suspected, contain the workload, review the managed identity’s role assignments, and validate downstream access to sensitive resources.
Microsoft Sentinel example: Managed identity sign-in anomaly.
let Lookback = 14d;
let Baseline = AADManagedIdentitySignInLogs
| where TimeGenerated between (ago(Lookback) .. ago(1d))
| summarize KnownResources = make_set(ResourceDisplayName), KnownIPs = make_set(IPAddress)
by ServicePrincipalId;
AADManagedIdentitySignInLogs
| where TimeGenerated > ago(1d)
| lookup kind=leftouter Baseline on ServicePrincipalId
| where isempty(KnownResources)
or ResourceDisplayName !in (KnownResources)
or IPAddress !in (KnownIPs)
| project TimeGenerated, ServicePrincipalId, ServicePrincipalName, IPAddress, ResourceDisplayName, ResultType, ResultDescription
Cayosoft Guardian detection: Microsoft Entra app with risky write permissions, where the managed identity or workload identity holds high-impact permissions.
How AI agent identities become attack paths
Attack path: AI agents extend the same identity problem as other non-human identities. An attacker can plant malicious instructions in content the agent later reads. If the agent treats that content as trusted instruction and has broad access to mail, files, APIs, or internal tools, the compromise can move at machine speed without a traditional user sign-in or multifactor authentication prompt.
Mitigate: Give each agent a distinct identity and scope access to the task it performs. Avoid shared API keys, broad standing credentials, and excessive tool access. Apply prompt-injection safeguards, provenance-aware data access, ownership, expiration, review cadence, and retirement rules so agent identities fall under the same non-human identity security management controls as other privileged workload identities.
Detect: Monitor agent access to unfamiliar resources, sudden spikes in activity, unusual token usage, failed access attempts, and machine-scale data access patterns. Pay attention to agents retrieving sensitive data, following external links, or accessing resources outside their expected purpose, hours, or normal behavior. If compromise is suspected, isolate the agent identity, review tool and data access history, and reduce permissions before restoring service.
Microsoft Sentinel example: Agent identity monitoring should focus on unusual service principal or workload identity activity until dedicated agent telemetry is available.
AADServicePrincipalSignInLogs
| where TimeGenerated > ago(24h)
| summarize SignIns = count(), DistinctResources = dcount(ResourceDisplayName), Resources = make_set(ResourceDisplayName, 10)
by ServicePrincipalId, ServicePrincipalName, AppId
| where SignIns > 100
or DistinctResources > 5
| order by SignIns desc
Cayosoft Guardian detection: Microsoft Entra app with risky write permissions; Microsoft Entra app with client secrets; monitor ownership, credential, and permission changes for agent-backed applications.
How Cayosoft Fits
Cayosoft Guardian supports non-human identity security management with live threat detections and real-time change monitoring for non-human identity attack paths. It helps defenders see risky permissions, credential changes, ownership changes, federation changes, and other identity control-plane activity as it happens, not after the next audit cycle.
Start monitoring non-human identity risk, live threat detections, and real-time Microsoft Entra ID control-plane changes before they become incidents for free with Cayosoft Guardian Protector.
Supporting Resources
Key Takeaways
- Non-human identities are privileged identities, not background configuration.
- Application permissions, app role assignments, and service principal credentials can create direct tenant takeover paths.
- User controls alone do not protect app-only authentication, managed identities, or autonomous agents.
- The most important signals are new credentials, new consents, new app role assignments, directory role changes, federation changes, blank application-name sign-ins, managed identity anomalies, and agent access drift.
- The first practical step is to enumerate every app, service principal, managed identity, enterprise app, and agent identity, then find which ones hold the highest-risk permissions.
Frequently Asked Questions
What is a non-human identity?
A non-human identity is an application, service, workload, automation account, managed identity, enterprise application, or AI agent that authenticates to systems without a person directly signing in.
Why are service principals risky?
Service principals are risky because they can hold credentials, Microsoft Graph permissions, OAuth consent grants, and directory roles. If an attacker gains access to a secret, certificate, owner account, or token, they may be able to act as the application.
What permissions should defenders review first?
Defenders should first review RoleManagement.ReadWrite.Directory, AppRoleAssignment.ReadWrite.All, Application.ReadWrite.All, Directory.ReadWrite.All, and Domain.ReadWrite.All because these permissions can enable privilege escalation, app modification, broad directory writes, or role assignment abuse.
What logs are most important for detecting non-human identity attacks?
The most important logs are Microsoft Entra AuditLogs, SigninLogs, AADServicePrincipalSignInLogs, AADManagedIdentitySignInLogs, AzureActivity, and Key Vault diagnostic logs where available.
How can organizations improve non-human identity security management quickly?
Organizations can reduce risk quickly by inventorying all non-human identities, removing unused applications, restricting user consent, reviewing high-risk Microsoft Graph permissions, shortening credential lifetimes, and monitoring credential, consent, role, and federation changes in real time.