Give every non-human Microsoft Entra identity an owner and an end date

Source fact: Microsoft Entra has three service-account patterns

Microsoft’s cloud service-account guidance identifies managed identities, service principals, and user-based service accounts. They represent applications, APIs, and other non-human services. Microsoft recommends a managed identity for an Azure-hosted service when supported, then a service principal when managed identity is unavailable. A Microsoft Entra user account is the last choice and is not recommended as a service account.

A service principal is the tenant-local identity of an application instance and determines the application’s access. It can authenticate with a certificate or client secret; Microsoft recommends certificates when possible because a certificate cannot be accidentally embedded in code like a secret. A managed identity removes owner-managed credentials: Azure creates, protects, and rotates the credential used to obtain Entra tokens.

Source fact: managed does not mean ownerless

Microsoft’s managed-identity security guidance distinguishes two lifecycles. A system-assigned identity has a one-to-one relationship with its Azure resource and is deleted with that resource. A user-assigned identity exists independently, can be attached to multiple resources, and is not automatically deleted when one of those resources disappears. Both still receive authorization through role assignments or a target service’s data-plane controls. Microsoft tells administrators to examine their privileges and ensure they are not members of privileged groups.

This distinction creates different failure modes. A system-assigned identity can disappear when its resource is removed; a user-assigned identity can survive after all intended workloads are gone. Those are source-backed lifecycle properties. The requirement to map dependencies and plan removal is DSE’s operational response to them.

DSE recommendation: use one lifecycle record across all three types

DSE recommends one inventory for managed identities, service principals, and unavoidable user-based service accounts. For each identity, record its object and client identifiers as applicable, type, display name, accountable owner and backup owner, single business purpose, workload and repository, environments, resources reached, role assignments and application permissions, credential mechanism, creation date, next review, expected retirement, incident contact, and decommission evidence. Never place a secret value in that record.

Make the identity request prove why a managed identity cannot be used before approving a service principal, and why neither can work before approving a user account. Give one service account one purpose so usage and impact remain understandable. For an inherited user-based account, document its actual dependencies before changing it, restrict unnecessary interactive use, apply only the permissions the service requires, and establish a migration target.

Source fact: governance spans planning through deletion

Microsoft’s service-account governance model calls for an owner, purpose, expected permission scopes, linked resources and scripts, risk, review period, lifetime, and standardized name. It applies least privilege, limits credential duration, monitors sign-in patterns, recertifies continuing need, and ends in permanent deletion. Microsoft specifically recommends checking for identities that no longer sign in and for changed sign-in patterns. It advises reviewing permissions regularly and avoiding non-expiring service-principal credentials.

DSE recommendation: operate by identity type

• Managed identity: review both Azure control-plane roles and target-service data access. For a user-assigned identity, enumerate attached resources and require an owner-managed retirement date. For a system-assigned identity, include identity and downstream-access effects in the resource-deletion change.
• Service principal: prefer a certificate where supported, protect credential material in an approved vault, alert before expiration, and test rotation while the old credential still permits rollback. Monitor service-principal sign-ins and changes to credentials, owners, and permissions.
• User-based service account: treat it as technical debt. Do not share it among services. Constrain sign-in and privilege, govern its password without creating an indefinite exception, monitor it separately from human users, and migrate to a managed identity or service principal when the workload permits.

DSE recommendation: retire access without guessing

Start retirement by confirming application, script, resource, and data-owner dependencies. Remove the workload from service, then disable the identity where that type supports disabling; otherwise isolate the workload or remove its effective assignments for a defined observation period with an approved rollback path. Check sign-in and resource logs for unexpected use. Revoke role assignments and other resource access, remove credential material and automation references, then delete the identity after owner approval and the observation window. Preserve the ticket, approvers, timestamps, dependency checks, and deletion evidence.

This guide deliberately focuses on lifecycle ownership rather than duplicating detailed OAuth-consent or access-review procedures. Its central control is simpler: no non-human identity should enter production without a named owner, bounded purpose and privilege, an observable use pattern, and a planned end.

Official sources

• Microsoft: Governing Microsoft Entra service accounts
• Microsoft: Securing cloud-based service accounts
• Microsoft: Securing managed identities in Microsoft Entra ID
• Microsoft: Securing service principals in Microsoft Entra ID