Glossary

Service principal

The tenant-local object that represents an application, managed identity, or agent in Microsoft Entra ID and holds its role assignments, permission grants, and sign-in activity.

A service principal is the tenant-local object that represents an application, managed identity, or agent in Microsoft Entra ID and holds its role assignments, permission grants, and sign-in activity. Microsoft describes it as the security principal for an application in a specific tenant: it defines the app's access policy and permissions there, and it is what actually gets authenticated at sign-in and authorized at resource access. The app registration is the template in the publishing tenant; the service principal is the identity that acts in yours.

Why it matters to a lean team

The controls a small team leans on are built around people: MFA, Conditional Access on interactive sign-in, password resets. A service principal authenticates with a secret or certificate and no person present, so those controls do not apply, and its access lasts until the credential or grant is removed. Microsoft counts service principals that hold highly privileged roles as control plane (Tier 0) assets. In Microsoft's taxonomy, workload identities in Entra are applications, service principals, and managed identities, so this one object type covers most of the non-human identities in a directory. A one to five person team cannot review hundreds of them; the goal is knowing which ones can change the tenant.

How it shows up in Entra ID and Azure

In the Microsoft Entra admin center, Enterprise applications lists service principals with their permissions, who consented, and sign-in information; App registrations lists application objects, a different list. Over Microsoft Graph the resource is servicePrincipal, found with Get-MgServicePrincipal -Filter "appId eq '{AppId}'" or az ad sp list. Microsoft documents three types: Application, Managed identity (no app object, cannot be edited directly but can be granted permissions), and Legacy. A multitenant app gets a service principal in every tenant where someone consented, so a vendor's app has a principal in your tenant while its application object stays in the vendor's. Agent identities under Microsoft Entra Agent ID are single-tenant service principals with an "agent" subtype, so a service principal inventory sees them too.

Sign-ins are logged apart from users. Monitoring & health > Sign-in logs holds four types (interactive user, non-interactive user, service principal, managed identity), readable with the Reports Reader role. Retention is 7 days on Entra ID Free and 30 days on P1 or P2. Through Graph, the filter signInEventTypes/any(t: t eq 'servicePrincipal') exists only on the beta endpoint, which Microsoft says is unsupported for production. Privileged Identity Management can assign roles to service principals and managed identities as well as users, which is how one ends up holding Global Administrator.

What to do about it

  • Inventory the service principals that hold directory roles, high-privilege Graph permissions such as Directory.ReadWrite.All, or Azure role assignments, and name an owner for each.
  • Read the service principal sign-in log, not only the user one. Microsoft lists "Which of my Azure resources were accessed by managed identities and service principals?" as a question the logs are designed to answer.
  • Treat credentials as the attack surface. Microsoft's remediation for a compromised workload identity: inventory every credential on the service principal and the application object, add a new one (certificates recommended), remove the compromised ones, and rotate any Key Vault secrets it can reach. See find expiring client secrets in Entra ID.
  • Know the containment options. Microsoft's outcomes for a risky workload identity include "Disable service principal", and deactivating an application stops new token issuance while keeping the objects for investigation. Deleting the application object deletes the home-tenant service principal, and restoring it does not bring the principal back.
  • If the access came from a tricked consent, revoke the grant itself; Microsoft states password resets and MFA are not effective against an illicit consent grant.

Where Orbitra fits

Orbitra puts human and non-human identities (service principals, app registrations, OAuth grants, managed identities) in one graph with blast radius traversal, so each service principal appears beside the roles, permissions, and Azure resources it can reach. When one has to be contained, the response comes from an allowlisted catalog of more than two dozen governed response actions, and 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. Connect Microsoft in minutes and start read-only.

Sources

See it on your tenant

Find the privilege that can reach your critical systems.

Get a privilege exposure review Glossary