# Give every non-human Microsoft Entra identity an owner and an end date > Managed identities, service principals, and user-based service accounts can retain access without human visibility. Choose the safest type, record ownership and purpose, control permissions and credentials, monitor use, and retire dependencies safely. - Canonical URL: https://update.dsesecurity.com/updates/give-every-non-human-microsoft-entra-identity-an-owner-and-an-end-date/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-04T22:53:02+00:00 - Modified: 2026-08-04T22:53:02+00:00 - Last reviewed by DSE: 2026-08-04 - Resource type: Guide - DSE priority: Important - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 4 minutes ## What you need to know Managed identities, service principals, and user-based service accounts can retain access without human visibility. Choose the safest type, record ownership and purpose, control permissions and credentials, monitor use, and retire dependencies safely. ## Potentially affected Organizations using Microsoft Entra identities for applications, APIs, scripts, automation, Azure resources, Microsoft 365 integrations, or other unattended services. ## DSE recommendation Build one governed inventory and lifecycle for all non-human Entra identities, migrate away from user-based service accounts where possible, and require an owner, single purpose, least privilege, review date, and tested retirement plan. ## Article ## Source fact: Microsoft Entra has three service-account patterns Microsoft’s [cloud service-account guidance](https://learn.microsoft.com/en-us/entra/architecture/secure-service-accounts) 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](https://learn.microsoft.com/en-us/entra/architecture/service-accounts-managed-identities) 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](https://learn.microsoft.com/en-us/entra/architecture/govern-service-accounts) 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](https://learn.microsoft.com/en-us/entra/architecture/govern-service-accounts) - [Microsoft: Securing cloud-based service accounts](https://learn.microsoft.com/en-us/entra/architecture/secure-service-accounts) - [Microsoft: Securing managed identities in Microsoft Entra ID](https://learn.microsoft.com/en-us/entra/architecture/service-accounts-managed-identities) - [Microsoft: Securing service principals in Microsoft Entra ID](https://learn.microsoft.com/en-us/entra/architecture/service-accounts-principal) ## Primary reference - Name: Microsoft: Governing Microsoft Entra service accounts - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/entra/architecture/govern-service-accounts - Source publication date: 2024-02-16 ## Citation and use Preferred citation: “Give every non-human Microsoft Entra identity an owner and an end date,” DSE Security, https://update.dsesecurity.com/updates/give-every-non-human-microsoft-entra-identity-an-owner-and-an-end-date/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved.