How do you clean up unmanaged Microsoft Entra accounts created through self-service sign-up?

What makes a self-service sign-up account “unmanaged”?

These accounts are tenant identities that were created outside normal admin provisioning, usually through a user-initiated trial or self-service flow, and then left without a clear owner, lifecycle, or governance process. The practical issue is not creation alone, it is whether the account still has a legitimate business purpose, an accountable owner, and a known set of permissions.

Because these identities can outlive the project, person, or application that created them, cleanup starts with inventory and ownership review. That means separating active tenants from abandoned ones, checking whether the tenant still supports a real business function, and deciding whether the account should be brought under management or retired.

When ownership is unclear, the account should be treated as a governance gap first and a technical cleanup second. A useful anchor point is Active Directory and Entra ID Hardening Guide, because unmanaged Entra tenants often sit in the same identity boundary as other privileged Microsoft identity assets and deserve the same discipline around ownership and review.

How should you decide whether to convert or remove it?

The decision is usually based on three questions: does the account still support a business process, is there a named owner who can accept responsibility, and does the account still need its current access. If the answer is yes to all three, convert the tenant into a managed account and assign clear administration, review, and renewal controls. If not, retire it.

Conversion is appropriate when the identity is still legitimately in use but has simply never been folded into standard governance. Removal is appropriate when the account is orphaned, inactive, or duplicated by a better-controlled tenant. In both cases, the goal is to eliminate shadow identity sprawl rather than preserve every historical signup.

For teams that struggle to answer those questions consistently, the NHI Ownership and Accountability Guide is useful because the same accountability problem appears whenever an identity exists without a clear business or technical owner.

What else needs to be checked before cleanup is complete?

Removing or converting the tenant is only part of the job. You also need to review linked applications, delegated access, consented permissions, stale sessions, and any credentials or tokens that were issued to the tenant before it was governed. If those bindings remain active, the old identity can continue to authenticate or authorize activity even after the account looks “cleaned up.”

That is why cleanup should include a search for related service principals, app registrations, and externally shared access paths. In Microsoft identity environments, the account often has more reach than the visible user object suggests, so cleanup needs to follow the trust relationships, not just the directory entry.

The Service Account Security Guide and Human vs Non-Human Identity are both relevant here because they reinforce the practical point that linked machine access and human-created identities often have different owners, lifecycles, and revocation paths.

Risk and Threat Considerations

Unmanaged self-service sign-up accounts create persistent exposure because they may retain access long after the original use case has ended. The main risk is not just forgotten cost or clutter, it is unowned identity sprawl, stale authorization, and a larger attack surface for account abuse, consent abuse, and hidden application access.

Failure mechanism: The account remains trusted by the tenant, linked apps, or delegated permissions even after the original business owner has disappeared, so access persists without oversight.

Impact: An attacker, or simply a former user with retained access, can exploit the orphaned identity to reach data, apps, or admin paths that the organisation no longer expects to be live.

Practitioner Guidance

What to prioritise: Start with accounts that have no documented owner, no recent business activity, or linked applications with broad permissions. Those are the identities most likely to be both abandoned and still risky.

What to verify: Before deletion, confirm whether the tenant is referenced by production apps, external collaborations, or automation that would break if the identity disappeared. If the tenant is still required, convert it into an owned and reviewed account rather than leaving it in limbo.

Practitioner takeaway: The key judgement is to treat unmanaged Entra sign-up accounts as lifecycle and ownership problems, not just directory cleanup, because revocation is only safe after you have traced every live access path.

Related resources from NHI Mgmt Group

• How do you find and clean up stale devices in Microsoft Entra ID?
• How should teams reduce the risk of orphaned service accounts and stale tokens?
• How should teams design self-service onboarding so users can sign up and reach the application without manual hand-offs?
• How should security teams govern temporary service accounts that are created for one-off tasks but end up with excessive permissions?