Does Microsoft back up Microsoft Entra External ID?
Applies to: Microsoft Entra External IDNo. 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:
| Object type | Restorable for |
|---|---|
| Users | 30 days |
| Microsoft 365 Groups | 30 days |
| Cloud security groups | 30 days |
| Application registrations | 30 days |
| Service principals | 30 days |
| Administrative units | 30 days |
| Conditional Access policies | 30 days |
| Named locations | 30 days |
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 about Microsoft Entra Backup and Recovery?
This is the obvious follow-up, and the answer is specific: it does not apply to External ID tenants.
Microsoft Entra Backup and Recovery became generally available in 2026. It is a genuinely useful product: daily backups of supported directory objects, seven days of history, difference reports before you recover, and backups no administrator can switch off. It is included with Entra ID P1 and P2.
Its prerequisites are explicit, though. From Microsoft's own documentation:
The tenant is a workforce tenant. External ID and Azure AD B2C tenants aren't supported.
So Microsoft has built first-party backup for identity, and scoped it to workforce tenants. If you run a customer identity tenant, it is not available to you.
Two further limits are worth knowing even for the workforce tenants it does cover, because they shape what "backup" means here:
- Seven days of history. It is a rollback window, not an archive. A change made eight days ago has no backup to compare against.
- It builds on soft delete, so it inherits soft delete's boundary: Microsoft states plainly that it "doesn't support the recovery or re-creation of hard-deleted objects."
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:
- 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.
- Keep versioned copies of that configuration, taken often enough that the most recent one is never far from current.
- Detect unexpected change quickly, since modification is invisible to the native recycle bin.
- 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 behaviour here changes over time. This article reflects Microsoft's published guidance as of August 2026, including the general availability of Entra Backup and Recovery and its workforce-tenant-only scope. Verify the current position in Microsoft's Recover from deletions in Microsoft Entra ID and Microsoft Entra Backup and Recovery overview documentation before relying on it.
