Guide

How to find and remove service principals with Global Administrator

An application that holds Global Administrator can do everything a human Global Administrator can, with a certificate or secret instead of a person behind it, so this guide shows how to list every service principal with a privileged Entra role, what to check before you touch it, and how to remove the role with a way back.

Global Administrator on a service principal is the assignment nobody remembers making. A migration tool needed it for a weekend, a vendor's setup script asked for it, or an automation account was given it because a narrower role failed once. Microsoft classes service principals and applications that hold highly privileged roles as control plane (Tier 0) assets, to be isolated and administered only from equally trusted systems. This guide covers how to list them, what to check before you remove the role, how to remove it so it can be restored inside a defined window, and where to see what the service principal has been doing. It is one of the Orbitra guides on privileged identity response.

Why a service principal with Global Administrator is a different problem

A service principal is the security principal for an application in your tenant: it defines the app's access policy and permissions, and it is the object that actually gets authenticated at sign-in. Microsoft describes three types: Application (the local instance of an app object), Managed identity (no app object, cannot be edited directly, but can be granted access and permissions), and Legacy (created before app registrations existed). Any of them can hold a directory role. PIM assignments can be made to users, groups, service principals, or managed identities, as either eligible or active, with a scope and a duration.

Give one of them Global Administrator and it has access to all administrative features in Microsoft Entra ID and to the services that use Entra identities, including Exchange Online and SharePoint Online, and it can reset the password for any user and every other administrator. It signs in with a certificate or secret rather than a person, so a leaked credential is a working Global Administrator sign-in. Microsoft's guidance to keep Global Administrators under five and total privileged role assignments under ten applies here too; the Entra Overview alert card fires at five or more Global Administrator role assignments, and it counts assignments, not people. See how many Global Administrators a tenant should have.

Step 1: list every service principal holding a privileged role

In the admin center

Open Entra ID, then Roles and administrators. The page has a Privileged column and lets you filter to privileged roles, and the Assignments column shows how many assignments each role has. Open Global Administrator and read the list: any principal that is an application rather than a person is what you are looking for. Then do the same for the other privileged roles. Microsoft flags about 30 built-in roles as privileged, and Privileged Role Administrator deserves the same attention as Global Administrator, because Microsoft's own callout says it can manage assignments for every Entra role including Global Administrator, and holders can grant themselves additional privilege. A service principal holding it is a Global Administrator one step removed.

With Microsoft Graph

Programmatically, a role definition is privileged when its isPrivileged property is true, and role assignments can be filtered with roleDefinition/isPrivileged eq true. Microsoft's documented examples use the beta endpoint, for example Get-MgBetaRoleManagementDirectoryRoleDefinition -Filter "isPrivileged eq true", so expect to work in the beta Graph PowerShell module. The pattern is:

  1. List role assignments filtered to privileged role definitions. For each result keep the assignment id, the role definition, the scope, and the principal id.
  2. Resolve each principal id. A service principal resolves through the service principal collection (Get-MgServicePrincipal, which Microsoft documents with an appId filter for finding the service principals of a given app); a user or group does not. Keep every principal that resolves as a service principal, and remember that managed identities are a service principal type.
  3. Repeat for eligible assignments if you use PIM. Microsoft states there is no difference in the access given to someone with a permanent versus an eligible assignment; eligible holders simply do not hold it all the time. A listing of active assignments will not show a PIM-eligible assignment, and Global Administrator or Privileged Role Administrator is needed to manage them.
  4. Expand role-assignable groups. Privileged Role Administrator can create groups that are assignable to roles, and when a role is assigned to such a group the assignment lists the group as the principal, not its members. Read the membership of any role-assignable group that holds a privileged role and check whether any member is a service principal.

The result is a short table: service principal, type, role, active or eligible, direct or through a group.

Step 2: check before you remove anything

Four questions, in this order. Answer them from Microsoft's own data and write the answers down; they become the before-state you restore from if removal breaks something.

Who owns it

Open the service principal under Enterprise applications, which lists its permissions, user-consented permissions, who consented, and sign-in information, then check its owners and the owners of the matching app registration in the home tenant. An owner can tell you what the role is for. No owner means nobody will notice when it stops working, and nobody will tell you when its secret leaks.

When and where it signs in

Entra sign-in logs contain four types: interactive user, non-interactive user, service principal, and managed identity. The legacy sign-in experience shows only interactive user sign-ins, so switch to the service principal tab. Note the last sign-in, the source addresses, and the target resources. The section on sign-in logs below covers the portal, Log Analytics, and Graph paths.

What depends on it

Microsoft lists "Which of my Azure resources were accessed by managed identities and service principals?" as a question the sign-in logs are designed to answer. The resources the service principal reaches tell you which workloads stop if it loses the role. If it only calls Microsoft Graph, look at what it does there; an application that needs Graph application permissions does not need a directory role for them.

How old its credentials are

Microsoft's own remediation for a compromised workload identity starts with inventorying all credentials on both the service principal and the application object. Do that now, before there is an incident, and check the Application credential activity report under Usage & insights to see which credentials are actually used. A privileged service principal with several secrets, some never used, is a credential exposure before it is anything else. The client secrets guide covers the inventory in detail.

Is it already flagged

If your tenant has workload identity risk detection, the riskyServicePrincipals and servicePrincipalRiskDetections collections in Graph show whether Microsoft has already noticed something. A hit there changes step 3 from cleanup to response.

Step 3: remove the role with a way back

  1. Capture the before-state. Assignment id, role, scope, principal id, active or eligible, plus the owner list and credential inventory from step 2. Store it outside the tenant with a timestamp and the name of the person who approved the removal.
  2. Define the window. Agree how long the before-state stays ready for restore (24 hours is a reasonable default) and who can approve a restore. If a workload fails inside the window, you re-add the same assignment from the record instead of debugging under pressure.
  3. Remove the assignment, not the object. Deleting the application object deletes the home tenant service principal, and restoring the application object through the App registrations UI does not restore the service principal. If you need the app to stop entirely, Microsoft documents deactivation as the way to suspend it: it prevents new token issuance while preserving the application object and service principal for investigation or later reactivation.
  4. Run the removal as a person. For PIM assignments, only Privileged Role Administrators or Global Administrators can manage assignments for other administrators. A Global Administrator cannot remove its own Global Administrator assignment, so do not script the cleanup under the service principal you are cleaning up.
  5. Grant what the app actually needs. If the app must keep working, replace the role with the least privileged Graph application permission it uses. Only a Privileged Role Administrator or Global Administrator can consent to application permissions, so this is a second approval, not a side effect of the first.
  6. Check Azure separately. Entra role assignments do not grant access to Azure resources and Azure role assignments do not grant access to Entra ID; the two systems are secured independently. If the same service principal holds Owner or Contributor on a subscription, that is a second inventory and a second removal. Azure Resource Graph returns only active assignments and omits PIM eligible ones, which must be listed separately. See elevate access for how the two systems connect for human Global Administrators.
  7. Verify by re-reading, not by the response code. Run the step 1 listing again; the assignment should be gone and the Assignments count on Roles and administrators one lower. Then watch the service principal sign-in log through the window. Removing a role does not remove the app's credentials, so its sign-ins continue; a dependent workload shows up as failures at the resource it calls. See containment verification for the general pattern.

Where Orbitra fits

Orbitra keeps human and non-human identities (service principals, app registrations, OAuth grants, managed identities) in one graph with blast radius traversal, so a service principal holding Global Administrator shows up with the roles, permissions, applications, and downstream assets it can reach before anyone acts. Removing an Entra directory role is one of more than two dozen governed response actions; every supported response is governed by tenant policy, Orbitra tells you which steps are permanent before you approve them, and Entra directory role removals can be restored within the undo window (24 hours by default). Orbitra independently re-reads Microsoft after supported response actions to verify the final state. In Recommend mode, your team executes the response; in Approve mode, a named person signs off before Orbitra executes. See how it works.

Where to see service principal sign-in logs in Entra

Admin center

Entra ID, then Monitoring & health, then Sign-in logs. Reports Reader is the least privileged role to view sign-in and audit logs; Security Reader and Global Reader can also read them. Service principal and managed identity sign-ins have their own tabs, and managed identity sign-in activity appears in the same logs. Under Usage & insights there is a Service principal sign-in activity report and an Application credential activity report next to the application activity reports. Sign-in logs are available on Entra ID Free as well as P1 and P2, but retention in the portal and API is 7 days on Free and 30 days on P1 or P2, which is what Business Premium and E3 tenants have.

Log Analytics

Anything longer than 30 days, or any query you want to run more than once, needs diagnostic settings: send the logs to a Log Analytics workspace for KQL queries, archive to a storage account, or stream to an event hub for a SIEM. Security Administrator is the least privileged role to configure diagnostic settings. Microsoft recommends streaming to Log Analytics and querying there to avoid the request throttling that affects admin center and Graph queries, which matters when you are walking through every sign-in a service principal made in the last month.

Microsoft Graph

The v1.0 endpoint is GET /auditLogs/signIns with AuditLog.Read.All as the least privileged permission, and a P1 or P2 license is required to download sign-in logs through the API. The catch: the v1.0 signIn resource does not expose servicePrincipalId, servicePrincipalName, or signInEventTypes. Those properties exist only on the beta resource, where signInEventTypes takes the values interactiveUser, nonInteractiveUser, servicePrincipal, and managedIdentity. Microsoft's documented beta filter is $filter=signInEventTypes/any(t: t eq 'servicePrincipal'), with Get-MgBetaAuditLogSignIn -Filter "(signInEventTypes/any(t: t eq 'servicePrincipal'))" as the PowerShell form. Beta also carries servicePrincipalCredentialKeyId and servicePrincipalCredentialThumbprint, which tell you which credential a sign-in used. Microsoft states beta APIs are subject to change and unsupported in production, so treat this as an investigation tool and use Log Analytics for anything you keep running.

A service principal signs in from a new location

Work Microsoft's own investigation checklist for a risky workload identity: suspicious sign-in activity, unauthorized credential changes, suspicious configuration changes, and unauthorized application role acquisition. The beta credential key id tells you which secret or certificate the new sign-in used, which narrows the leak. If you conclude it is compromised, follow Microsoft's remediation steps: inventory all credentials on both the service principal and the application object, add a new credential (x509 certificates recommended), remove the compromised credentials (all of them if the account is believed at risk), and rotate any Azure Key Vault secrets the service principal can reach. If it holds Global Administrator, run step 3 in the same session; the credential rotation ends the attacker's sign-in, and the role removal caps what any remaining access can do. Disable service principal is the documented outcome when you need it stopped outright.

A service principal has not signed in for 90 days

On P1 or P2 you cannot see 90 days natively, so the honest statement is "no sign-in in the 30 days we can see" unless the logs go to Log Analytics. Either way, a privileged service principal with no observed sign-in is exactly what Microsoft's recurring access reviews are meant to remove: role assignments no longer needed. Remove the role first (step 3, with the window), leave the credentials in place through the window, then deactivate the application rather than deleting it. Delete only after the window closes with nothing broken.

Sources

See it on your tenant

Find the privilege that can reach your critical systems.

Get a privilege exposure review Guides