Does Microsoft back up Microsoft Entra External ID?

No. Microsoft keeps the identity platform running, replicated, and highly available — but it does not keep a restorable copy of your tenant's configuration. There is a limited 30-day recycle bin for a specific list of object types, and for everything outside that list, deletion is immediate and permanent. This article explains exactly where the line falls, so you can decide what you need to protect yourself.

The short answer

Microsoft operates the service. You own the configuration inside it.

That distinction is the whole of it. Microsoft guarantees Entra will be available, durable, and geo-replicated. None of that helps when the problem is a change you made — a deleted user flow, an overwritten Conditional Access policy, an identity provider whose configuration was replaced. Replication faithfully copies the mistake.

What Microsoft does give you

Entra ID has a soft-delete mechanism: deleted objects enter a suspended state, keep their properties, and can be restored for 30 days. After that they are permanently deleted.

Soft delete applies to exactly these object types:

That list is genuinely useful, and it has grown — Conditional Access policies and named locations gained soft delete relatively recently. If you deleted a CA policy this morning, check Entra ID → Conditional Access → Deleted policies before doing anything else. Microsoft recommends restoring policies in report-only mode first, then reviewing before enabling.

What Microsoft does not give you

Everything not on that list is hard deleted — removed immediately, with no recycle bin and no support path. Microsoft's own documentation is unusually blunt about this:

All other item types are hard deleted and can't be restored. They must be re-created. Your administrators and Microsoft can't restore hard-deleted items.

For a customer identity tenant, the objects outside the soft-delete list include much of what actually defines your sign-in experience:

• User flows — the sign-up and sign-in journeys themselves
• Identity providers — your Google, Apple, Facebook and SAML/OIDC federations
• Company branding — logos, colors, layout, and per-language variants
• Custom user attributes and attribute definitions
• API connectors used mid-journey
• Authentication methods and authorization policy settings
• Claims mapping and token lifetime policies
• Terms of use documents

Delete any of those and there is nothing to restore from. They have to be rebuilt by hand, from memory or documentation, while sign-in is broken.

Three gaps soft delete does not close

Even for the object types it covers, soft delete is a recycle bin — not a backup. Three differences matter.

It only covers deletion, not modification. This is the big one. If someone edits a Conditional Access policy, changes a user flow's attribute set, or points an identity provider at the wrong client ID, nothing was deleted, so nothing enters the recycle bin. There is no undo, and no record of the previous value. Configuration drift is far more common than outright deletion, and soft delete is blind to all of it.

There is no point in time. A recycle bin restores an object as it was at the moment of deletion. It cannot answer "put this tenant back the way it was on Tuesday," because no copy of Tuesday exists.

The window is 30 days, and it is a hard stop. Deletions are often discovered long after the fact — a partner federation that only breaks at renewal, a user flow used by a seasonal application. Once 30 days pass, the object is gone even for Microsoft Support.

So what should you protect?

Microsoft's own recoverability guidance is to document your known-good state, monitor deletions in the audit log, and prepare processes to re-create what cannot be restored. That is sound advice, and it is also an admission: for most of your tenant configuration, the recovery plan Microsoft expects you to have is rebuild it yourself.

A practical baseline for an External ID tenant:

1. Know what you would have to rebuild. Inventory the objects outside the soft-delete list — the user flows, identity providers, branding, and custom attributes your applications depend on.
2. Keep versioned copies of that configuration, taken often enough that the most recent one is never far from current.
3. Detect unexpected change quickly, since modification is invisible to the native recycle bin.
4. Be able to restore selectively — one object, one resource type, or the whole tenant — and to see what a restore would do before it does it.

That is what EIDGuard exists to do: it exports your tenant's configuration into versioned recovery points held in your own Azure storage, compares them against the live tenant to surface drift, and restores in dependency order with a read-only preview first. See Getting started with EIDGuard for how it deploys, and Building a disaster recovery plan for Microsoft Entra External ID for how to decide what to protect and how often.

Microsoft's soft-delete behavior changes over time — this article reflects Microsoft's published guidance as of August 2026. Verify the current list in Microsoft's Recover from deletions in Microsoft Entra ID documentation before relying on it.