Glossary

Non-human identity: what it means in Microsoft Entra ID and Azure, and what a lean team should do about it

A plain-English definition of the identities in your tenant that are not people, where each kind appears in Microsoft Entra ID and Azure, why Microsoft says they are harder to protect, and the first steps a small security team can take.

A non-human identity is any identity that is not a person, including service principals, app registrations, managed identities, OAuth grants, and agent identities. Microsoft's own taxonomy divides identities into human and machine (non-human); machine identities are device and workload identities, and in Microsoft Entra the workload identities are applications, service principals, and managed identities. Each one can sign in and hold permissions, and none of them carries a phone that prompts for MFA. Privileged identity response has to cover them alongside admin accounts.

Why it matters to a lean team

Microsoft names three reasons workload identities are harder to manage and at higher risk: they cannot perform multifactor authentication, they often have no formal lifecycle process, and they must store their credentials somewhere. Two facts sharpen this on Business Premium or E3. Microsoft's PIM overview lists Entra roles, Azure resource roles, and groups as what PIM manages, so application API permissions, OAuth consent grants, and service principal credentials sit outside its role-activation model. And Microsoft treats a service principal or application holding a highly privileged role as a control plane (Tier 0) asset; a service principal with Global Administrator is a Tier 0 problem.

How it shows up in Entra ID and Azure

  • App registrations lists your application objects, the templates that hold an app's credentials. See app registration.
  • Enterprise applications lists the service principals with their permissions, who consented, and sign-in information, in three types: Application, Managed identity, and Legacy. See service principal.
  • Managed identities are service principals with no app object and credentials the customer never sees. System-assigned ones are deleted with their Azure resource; user-assigned ones are standalone resources deleted explicitly. Changes land in Azure Activity logs, sign-ins in Entra sign-in logs.
  • Agent identities (Microsoft Entra Agent ID, which Microsoft says is generally available) are single-tenant service principals with an "agent" subtype. Their blueprint holds the credentials, and Microsoft warns that a compromised blueprint credential affects every agent identity under it. The audit log attributes them by agentType and blueprintId.
  • Sign-in logs (Entra ID, Monitoring & health) hold four types: interactive user, non-interactive user, service principal, and managed identity. Reports Reader is the least privileged role that can view them; retention is 30 days on P1 or P2 and 7 days on Free.

In Microsoft Graph the objects are application and servicePrincipal; Entra ID Protection adds riskyServicePrincipals and servicePrincipalRiskDetections.

What to do about it

  1. Inventory. For every application and service principal record its credential types (certificates, client secrets, federated identity credentials), what it can reach, and who owns it. Find expiring client secrets in Entra ID gives the query.
  2. Retire secrets. Microsoft says client secrets should not be used in production; use a certificate, or a managed identity as the app's federated identity credential so nothing is stored or rotated.
  3. Read the quiet logs. Service principal and managed identity sign-ins are absent from the legacy sign-in view; Usage & insights adds "Service principal sign-in activity" and "Application credential activity" reports.
  4. Know the runbook. Microsoft's remediation for a compromised workload identity: inventory all credentials on the service principal and application object, add a new certificate credential, remove the compromised ones, and rotate any Key Vault secrets it can reach. Deactivating the application blocks new tokens while keeping both objects for investigation.

Worked example: a reporting script registered three years ago signs in with a client secret and holds Directory.ReadWrite.All; its creator has left. The inventory surfaces it; the fix is a certificate or federated credential, a narrower permission, and a named owner. If the secret has leaked, step 4 is the runbook, and a grant to an app nobody can vouch for belongs under illicit consent grant.

Where Orbitra fits

Orbitra maps human and non-human identities (service principals, app registrations, OAuth grants, managed identities) in one graph with blast radius traversal, and roughly 40 percent of its deterministic detection rules target applications, service principals, consent grants, and app credentials. 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