What happens if an Entra External ID tenant is deleted?

Tenant deletion is the one failure with no safety net at all. Individual objects inside a tenant get a 30-day recycle bin; the tenant itself does not. Once deletion completes it is permanent, and neither your administrators nor Microsoft Support can bring it back. This article covers what deletion actually involves, why it is harder to do by accident than people fear, and what recovery looks like if it happens anyway.

The short answer

There is no undo. A deleted tenant is gone, along with every object and every piece of configuration inside it that was not captured somewhere else first.

That is a different situation from a deleted user or a deleted Conditional Access policy, both of which sit recoverable for 30 days. The recycle bin operates inside a tenant. It cannot help when the container itself is removed.

Microsoft makes it deliberately hard

The reassuring part is that a tenant cannot be deleted casually. Microsoft blocks deletion until the tenant is essentially empty, and the checks are enforced rather than advisory. In broad terms a tenant will not delete while it still has:

• Any Azure subscription associated with it, including cancelled ones
• Users other than the administrator performing the deletion
• Registered applications
• Certain licences or provisioned services

The practical effect is that deleting a tenant is a deliberate sequence of actions, not a mis-click. The realistic risks are not accidents so much as decisions: a tenant retired during a migration that turns out to still matter, a consolidation that removes the wrong directory, or an administrator acting on bad information.

What is actually lost

Everything that made the tenant a working identity system, not merely the user list:

• User flows, and the sign-up and sign-in journeys they define
• Identity providers and every federation you configured
• Applications and service principals, with their IDs
• Conditional Access policies and named locations
• Company branding, including per-language variants
• Custom attributes and API connectors
• Every object ID in the tenant

That last point is the one that turns rebuilding into a project rather than a task. Even a perfect manual reconstruction produces new object IDs, so anything holding a reference to an old identifier (an application, a downstream system, a partner integration) has to be updated too.

Why a backup outside the tenant matters here

This is the scenario where the location of your backup decides whether recovery is possible at all. A copy stored inside the tenant it protects shares that tenant's fate.

EIDGuard is deployed into your Azure subscription, and protects External ID tenants that are separate from it. Recovery points are written to storage you own in that subscription, not into the External ID tenant being protected. If a protected External ID tenant is deleted, its recovery points are unaffected, they live somewhere else entirely.

That does not make deletion painless. It makes it recoverable: you have the configuration, in versioned form, and can rebuild into a new tenant rather than reconstructing from memory and documentation.

What recovery looks like

Rebuilding into a fresh tenant is a full-mode restore rather than a routine one, and it is the scenario EIDGuard's Full mode exists for. The mechanics are covered in Restoring from a recovery point; three points matter especially here:

• Dependency ordering. Attribute definitions and identity providers are restored before the user flows referencing them, so the tenant comes back wired rather than merely populated.
• New IDs, remapped references. Objects recreated in a new tenant get new identifiers. EIDGuard tracks every old-to-new mapping and rewrites references between restored objects so they point at each other correctly. References held outside the tenant are still yours to update.
• Manual actions. Client secrets, federation signing keys, per-user MFA registrations and branding image binaries cannot be exported from Microsoft Graph, so no backup contains them. They are listed explicitly after the restore rather than discovered later.

Reducing the risk before it matters

• Protect the deletion itself. Microsoft supports protected actions for sensitive directory operations, which can require step-up authentication before they proceed. Tenant-level and directory-level destruction is exactly the category that warrants it.
• Know who holds Global Administrator, and keep the number small and reviewed.
• Keep configuration backed up outside the tenant, on a schedule, so the worst case is a rebuild from a recent known-good state rather than from scratch.
• Rehearse a restore at least once, so the elapsed time is a measured number rather than an estimate. See Building a disaster recovery plan for Microsoft Entra External ID.

Microsoft's behaviour in this area changes over time. This article reflects published guidance as of August 2026; verify current tenant deletion prerequisites in Microsoft's documentation before planning around them.