NHI origins in Microsoft Azure tenants
Every service principal in your Entra tenant has an origin. Most CIEM tools surface them as a flat list with no context. Permafrost classifies each non-human identity by where it came from so analysts can act on the right ones first.
What an NHI is
A non-human identity is any directory principal that signs in without a person attached to it. Microsoft Entra surfaces three flavours.
- Service principal. The tenant-local representation of an application. Holds credentials, role assignments, and consent grants. Created by an app registration in your tenant or by consenting to an external multi-tenant app.
- Managed identity. A service principal whose credentials are provisioned and rotated by Azure. Bound to an Azure resource — a VM, a Function App, an AKS pod identity — and disappears when that resource is deleted.
- Agent identity. A principal provisioned by the Microsoft Entra Agent ID service for AI agents and copilots. Inherits permissions from a blueprint and ships with a Microsoft-controlled lifecycle.
Why origin matters
Decommission safety is the load-bearing reason. Disabling the wrong service principal takes a production workload offline. Disabling the right one shrinks the attack surface. The difference between “the right one” and “the wrong one” is almost always origin.
One concrete shape per identity type:
- A service principal owned by Microsoft (the Graph API, the Azure Portal) cannot be removed and does not need to be. Treating it as a candidate for cleanup wastes analyst hours.
- A managed identity bound to an AKS cluster cannot be safely disabled without breaking the cluster. The decommission path for an MI runs through the bound resource, not the principal.
- A third-party multi-tenant app consented in three years ago by a former admin, with no recent sign-in, is a textbook decommission candidate. The action is to revoke the consent grant in Entra Enterprise applications.
The seven origin tiers
Permafrost classifies every NHI top-down, first match wins. The tier appears on the inventory row and on the identity detail page Lineage section.
Microsoft-managed
Signal. appOwnerOrganizationId matches Microsoft's tenant GUID and identityType is servicePrincipal.
Action. Leave alone unless the principal holds unexpected role assignments. Sign-in activity is not surfaced through tenant logs; a long-blank sign-in column is not dormancy.
Azure managed identity
Signal. identityType is managedIdentity. The Graph servicePrincipalType is ManagedIdentity.
Action. Trace alternativeNames[0] back to the bound ARM resource. Decommission the resource, the identity follows.
Entra agent identity
Signal. identityType is agentIdentity. The Graph servicePrincipalType is ServiceIdentity. Provisioned by the Entra Agent ID service.
Action. Treat the parent blueprint as the unit of governance. Sponsor the blueprint, set tier-aware policies, never disable individual agent rows.
Gallery SSO integration
Signal. applicationTemplateId is set on the SP, or the SP carries the Gallery primary tag.
Action. Review the SSO config in Entra Enterprise apps. Disable if the integration is no longer in use.
Registered in your tenant
Signal. appOwnerOrganizationId matches one of your connected tenants. The app registration lives inside your directory.
Action. Locate the app registration owner. Rotate credentials if expired. Right-size the role assignments through Permafrost's UPRS.
Third-party app (consented in)
Signal. appOwnerOrganizationId is set, but does not match Microsoft or any of your connected tenants. The app belongs to an external vendor; an admin consented it into your directory.
Action. Review the consent grant in Entra Enterprise apps Permissions. Revoke if the app is unknown, unused, or no longer trusted.
Legacy / unattributed
Signal. A service principal with no traceable app registration. Microsoft labels these servicePrincipalType=Legacy; some predate modern app registrations entirely.
Action. Investigate before acting. Confirm no recent sign-in, no active role assignments, no live credentials. Remove only after the audit clears.
The three risky patterns
Origin is the lens; severity comes from what each tier holds. Three patterns produce the bulk of NHI-driven incidents on Azure.
- Third-party consented apps with privileged ARM RBAC. A multi-tenant app that received Owner or Contributor at the subscription scope. Permafrost surfaces these on the inventory row with the third-party origin badge plus the privileged-role chip. Revoking the consent grant is usually the right action.
- Tenant-registered SPs with no known owner. App registrations created by a former employee, with no current owner in the directory. Credentials drift, secrets stay live past the human lifecycle. Origin tier 5 plus owner-unknown on the inventory row is the signal.
- Legacy SPs with active credentials. Tier 7 principals predate modern app registrations. They carry passwordCredentials or keyCredentials that no current workflow updates. These are the highest-risk decommission candidates and need an audit pass before removal.
What Permafrost does not classify
Origin classification covers the NHI population in Entra. UPRS scoring covers ARM RBAC role assignments only. Microsoft Graph application permissions are surfaced on the identity detail page but are not folded into the UPRS number. Conflating Graph app permissions and ARM RBAC into one score collapses two distinct authorization planes and produces a misleading metric. The two stay distinct on every Permafrost surface.
Catalog credit
The well-known Microsoft application catalog Permafrost uses to resolve first-party app GUIDs into human-readable names is derived from the public Microsoft Learn list of first-party applications, with the structure inspired by merill/microsoft-info (MIT license). Permafrost bundles a hand-curated subset covering the most common first-party apps an Azure CIEM reviewer encounters.