Privileged Service Principal Check: Entra Directory Roles

A service principal that holds an Entra directory role is an administrator that never signs in interactively, never answers an MFA prompt and is often owned by someone who has left. Directory roles such as Privileged Role Administrator, Application Administrator or User Administrator are assigned to applications and managed identities for automation, and the assignments tend to outlive the project that needed them. Anyone who can add a credential to that application, including its owners, can act with the role. This runbook finds every service principal with an active or eligible directory role, expands the people who control each one, ranks the findings and reduces them with a rollback. It is for Entra administrators and identity security engineers. For removing unused applications in general, see How to find and remove stale service principals in Entra ID, which this page does not repeat.

This is an independent guide from NHI Mgmt Group, based on Microsoft's public documentation as of November 2026. It is not sponsored or reviewed by Microsoft. Product features change, so confirm settings against Microsoft's current documentation.

Key takeaways

Microsoft treats these apps as Tier 0. Its privileged roles guidance names service principals or applications that hold highly privileged roles as part of the control plane, to be administered only from equally trusted systems.
One query finds them. List /roleManagement/directory/roleAssignments with $expand=principal and keep rows whose @odata.type is #microsoft.graph.servicePrincipal.
Rank by isPrivileged. The role definition's isPrivileged flag marks roles with at least one sensitive action in the microsoft.directory namespace; fix those first.
The owners are the real attack path. Microsoft documents that an app may have more permissions than its owner, an elevation of privilege; an owner who can add a secret can use the role.
Narrow before you remove. Replace tenant-wide roles with a scoped or custom role, record every assignment you change, and alert on Add member to role for service principals.

When you need this

Your privileged assignment count is high: Microsoft recommends fewer than 10 privileged role assignments and shows a warning on Roles and administrators above that. Service principals often make up the hidden part of the count.
After an application compromise elsewhere in the tenant: you need to know which applications could change roles, credentials or authentication policy if their secret were stolen.
For audit: NIST SP 800-53 AC-2(7) asks for privileged accounts to be managed separately and AC-6 asks for least privilege. A role-holding service principal is a privileged account under both.
Before a tiering or zero trust programme: Tier 0 cannot be defined until you know which non-human identities sit in it.

Where privilege comes from

A service principal can gain administrative power in Entra in three ways. This runbook covers the first and the people who control it; the second has its own runbook, and the third is covered in step 4.

Route	What it is	Where to see it	Coverage
Directory role assignment	A built-in or custom Entra role assigned to the service principal, tenant-wide or scoped	Roles and administrators; Graph `roleAssignments`	This page
Microsoft Graph application permission	An app role such as `RoleManagement.ReadWrite.Directory` granted with admin consent	Enterprise applications > Permissions; Graph `appRoleAssignments`	High-privilege Graph application permissions runbook
Membership of a role-assignable group	The service principal is a member of a group that holds a role	Group members; `roleAssignments` where the principal is a group	Step 4

What a role-holding service principal can do

Role family	Examples	Why it matters for a service principal	Typical narrower option
Role and policy control	Global Administrator, Privileged Role Administrator, Privileged Authentication Administrator	Can grant itself or others any role, or change authentication for administrators	Almost never justified for automation; redesign the process
Application control	Application Administrator, Cloud Application Administrator	Can add credentials to other applications and act as them	Make the service principal an owner of only the apps it manages, or use a custom role scoped to those apps
User and group control	User Administrator, Groups Administrator, Authentication Administrator	Can reset credentials or change membership for many accounts	Scope the assignment to an administrative unit
Read roles	Directory Readers, Global Reader	Broad read of directory data; lower risk but still sensitive	Least privileged Graph read permission for the exact data needed

Before you start

Roles: discovery needs only read access. Microsoft lists Directory Readers, Global Reader or Privileged Role Administrator as the delegated roles for listing role assignments, and RoleManagement.Read.Directory as the least privileged permission. Use Global Reader with RoleManagement.Read.Directory and Application.Read.All for discovery. Keep Privileged Role Administrator for the change steps, through PIM where you have it.
Licensing: PIM eligibility and role access reviews need Microsoft Entra ID P2 or Microsoft Entra ID Governance; administrative unit scoped roles need P1. Check before you plan around them.
Record format: service principal name, object ID, app ID, servicePrincipalType, appOwnerOrganizationId, role name, isPrivileged, directoryScopeId, assignment type (active or eligible, direct or group), owners, credential types and expiry, last sign-in, business owner and decision.

Step-by-step

Steps 1 to 6 are read-only. Steps 7 and 8 change access and can be reversed from your records.

List privileged role definitions. Pull the role catalogue once so you can join on it:
```
GET https://graph.microsoft.com/beta/roleManagement/directory/roleDefinitions?$select=id,displayName,isBuiltIn,isPrivileged
```
isPrivileged is documented on the beta resource as read-only and filterable with eq, so treat its availability as subject to change and fall back to the Privileged column on Roles and administrators. Include custom roles: Microsoft labels a custom role privileged when it contains a privileged permission.
Find every active role assignment held by a service principal. List assignments with the principal expanded:
```
GET https://graph.microsoft.com/v1.0/roleManagement/directory/roleAssignments?$expand=principal
```
In Graph PowerShell use Get-MgRoleManagementDirectoryRoleAssignment -All -ExpandProperty principal. Keep the rows where [email protected] is #microsoft.graph.servicePrincipal, and record roleDefinitionId and directoryScopeId. A scope of / is tenant-wide; /administrativeUnits/{id} limits the role to that unit; an application object ID as scope limits it to one app. In the admin center the same data is on each role's Assignments page, but the API gives you the whole tenant at once.
Add eligible assignments. Where PIM is in use, list /roleManagement/directory/roleEligibilityScheduleInstances and keep principals that resolve to service principals. Record any you find, because eligibility is still standing privilege for a non-human identity that activates through automation.
Expand role-holding groups. For assignments whose principal is a group, list GET /groups/{id}/members and keep service principal members. Record the group owners too, because an owner can add members and so grant the role.
Classify each service principal. Fetch servicePrincipalType, appOwnerOrganizationId, accountEnabled, passwordCredentials and keyCredentials for every hit:
- Managed identity: servicePrincipalType is ManagedIdentity. No secret to steal, but whoever controls the Azure resource controls the role. See the over-privileged managed identities runbook.
- Your own application: appOwnerOrganizationId is your tenant ID. Check the application object's credentials as well as the service principal's, and record expiry dates.
- Third-party multi-tenant application: another tenant ID. The vendor controls its credentials, so the role extends trust to the vendor's security. Ask the vendor which role their product needs and why.
- Microsoft first-party service: appOwnerOrganizationId is f8cdef31-a31e-4b4a-93e4-5f571e91255a. Some Microsoft services hold roles by design; record them, confirm against Microsoft documentation for that service, and leave them unchanged unless Microsoft guidance says otherwise.
Expand who controls each one. List owners of both the service principal and its application (Get-MgServicePrincipalOwner, Get-MgApplicationOwner). Microsoft states that owners have the same permissions as application administrators, scoped to that app, and that an app with more permissions than its owner is an elevation of privilege. So every owner of a Privileged Role Administrator app is, in effect, one secret away from that role. Then list who holds Application Administrator or Cloud Application Administrator tenant-wide, and any custom role with microsoft.directory/servicePrincipals/credentials/update: they can add credentials too. Check federated credentials as a further control path; the federated credentials audit covers that.
Score and decide (reversible). Rank each finding: privileged role at tenant scope, held by an app with client secrets, with human owners who are not themselves Tier 0 administrators, comes first. For each, choose one of: keep with justification, narrow, move to a dedicated Tier 0 owner group, or remove. Confirm usage with the app's sign-in activity; the stale service principal runbook explains the sign-in activity reports.
Narrow or remove (reversible from records). Before any change, export the assignment (principal, role definition, scope). Then replace a tenant-wide role with an administrative unit scope or a custom role scoped to the specific applications, or replace an application management role with ownership of only the apps the automation manages. Remove extra owners so that only Tier 0 administrators, or a dedicated owner group's members, remain, keeping at least two as Microsoft recommends. Move secrets to certificates or federated credentials. To roll back, recreate the exported assignment with POST /roleManagement/directory/roleAssignments using the same principalId, roleDefinitionId and directoryScopeId.

Verify it worked

Count falls: re-run step 2; service principals with privileged roles at / are only those with a recorded justification.
Owners are Tier 0: every remaining privileged service principal has owners who are themselves protected as privileged administrators.
Automation still runs: the app's sign-in activity continues and its owner confirms the job succeeded after the narrowed role took effect.
Warning cleared: the privileged assignments warning on Roles and administrators no longer appears, or the count is explained.

Rollback and common errors

Situation	Fix
Automation fails after a role was removed	Recreate the exported assignment, then find the narrowest role with the "least privileged role by task" documentation
Role scoped to an administrative unit does not apply	Check that the target users or groups are members of that unit, and that P1 licensing is in place
A service principal holds a role but is not in your step 2 results	It holds the role through a group or an eligible assignment; run steps 3 and 4
Expanded principal is missing	`$expand=principal` was omitted; without it the response has no principal property
Vendor app breaks after narrowing	Restore the role and ask the vendor for the documented minimum; record the exception with an expiry

Common failure patterns

Reviewing people only: role access reviews and PIM alerts are configured for users, and the service principals holding the same roles are never in scope.
Ignoring owners: the role is reviewed, but the three developers who own the app and can add a secret are not treated as privileged.
Application Administrator as a convenience: granted so an automation can update one app, it lets the app add credentials to every app in the tenant.
Forgetting group routes: a service principal added to a role-assignable group does not appear when you filter role assignments by principal.
Secrets on Tier 0 apps: long-lived client secrets on a role-holding app turn any secret leak into a directory takeover. See the Azure Entra Client Secrets Security Guide.

Detection and hardening afterwards

Alert on new assignments: in the Entra audit log, alert on Add member to role, Add eligible member to role and Add scoped member to role where the target is a service principal. See the Entra ID Sign-In and Audit Log Detection Guide.
Alert on credential changes: Add service principal credentials and Update application - Certificates and secrets management on any app in your privileged list should page the identity team.
Review on a schedule: run steps 2 to 6 monthly and include role-holding service principals in role access reviews where your licence supports them.
Record the owner team: set serviceManagementReference on each application so a contact survives staff changes, as Microsoft suggests.

Small tenant or large enterprise

A small tenant usually finds a handful of service principals and can fix them in one change window from the admin center and a single Graph query. A large enterprise should schedule the query, load it into its NHI inventory, treat every privileged service principal as a Tier 0 asset with named owners, and require a change ticket for any new role assignment to a non-human identity. See the Privileged Identity Management (PIM) Guide for the human side of the same controls.

Metrics

Metric	Direction
Service principals with privileged roles at tenant scope	Falling, each justified
Owners of privileged service principals who are not Tier 0 administrators	Zero
Privileged service principals using client secrets	Zero
New role assignments to service principals without a ticket	Zero
Days from new assignment to review	Under 7

Framework mapping

Framework	Reference	Relevance
NIST SP 800-53 Rev 5	AC-2(7) Privileged User Accounts; AC-6 Least Privilege; CM-8 System Component Inventory	Role-holding service principals as privileged accounts with minimal scope and an inventory record
NIST CSF 2.0	PR.AA-05; ID.AM-02; DE.CM-03	Permission review; inventory; monitoring of role and credential changes
MITRE ATT&CK	T1098.003 Additional Cloud Roles; T1098.001 Additional Cloud Credentials; T1078.004 Cloud Accounts	Granting roles to apps, adding secrets to them, and using them as valid cloud accounts

Practitioner checklist

Pull role definitions and mark privileged roles, including custom ones.
List role assignments with $expand=principal and keep service principals.
Add PIM eligible assignments and role-assignable group members.
Classify each hit as managed identity, own app, third-party app or Microsoft service.
List owners of the app and service principal, and everyone who can add credentials.
Rank by privilege, scope, credential type and owner tier.
Export each assignment before you narrow or remove it.
Replace tenant-wide roles with scoped or custom roles, and secrets with certificates or federation.
Alert on role and credential changes for every service principal on the list.

Privileged Service Principal Check: Find and reduce apps holding Entra roles