Building a disaster recovery plan for Microsoft Entra External ID

Most disaster recovery plans cover databases, application servers, and storage — and stop at the identity layer, on the assumption that the cloud provider has it handled. For customer identity that assumption is only half true: Microsoft keeps the platform running, but your tenant's configuration is yours to protect. This article walks through building a recovery plan for an External ID tenant: what to protect, how fast you need to recover, and how to know the plan works.

Start from the failure modes

A useful plan is built from the ways things actually break, not from a generic template. For a customer identity tenant there are four.

Accidental deletion. Someone removes a user flow, an identity provider, or a Conditional Access policy that turns out to be load-bearing. This is the most common by a wide margin, and it is usually discovered by customers failing to sign in rather than by the person who made the change.

Unwanted modification. A change is made deliberately but has consequences nobody predicted — an attribute removed from a user flow, a policy scope widened, a claims mapping altered. Nothing was deleted, so nothing shows up in any recycle bin.

Malicious or insider change. A compromised or departing administrator alters the configuration that governs access. The response requires knowing precisely what changed and being able to put it back.

Broad tenant damage. Bulk deletion via a script, an automation that ran with the wrong scope, or a migration that went badly. Rare, but it is the scenario that determines whether your plan needs full-tenant rebuild capability.

Notice that only the first is a deletion. Any plan built solely around a recycle bin covers one of four.

Understand what the platform already covers

Microsoft Entra soft-deletes a specific list of object types for 30 days: users, Microsoft 365 Groups, cloud security groups, application registrations, service principals, administrative units, Conditional Access policies, and named locations. Everything else is hard deleted and cannot be restored by you or by Microsoft.

For an External ID tenant, the material outside that list is substantial — user flows, identity providers, branding, custom attributes, API connectors, and authorization policy settings among them. Does Microsoft back up Microsoft Entra External ID? covers the boundary in detail. Read it before deciding what your plan needs to own, because it determines the size of the gap you are filling.

Set an RPO and an RTO you can defend

Two numbers drive every other decision.

Recovery point objective (RPO) — how much configuration change you can afford to lose. For most External ID tenants, configuration changes in bursts around releases rather than continuously, so a daily backup is often appropriate. The sharper question is whether you can take an on-demand backup immediately before a planned change; that turns a risky change window into a recoverable one.

Recovery time objective (RTO) — how long you can afford sign-in to be broken. This is usually the more demanding number, because customer identity failures are customer-visible immediately. An RTO measured in hours implies you must be able to restore selectively and confidently, without a rebuild-from-memory step.

Write both down and check them against reality: if your RPO is 24 hours, your backup must actually run daily and you must know when one fails.

Inventory what has to come back

A plan is only as good as its inventory. For each protected tenant, record:

• The user flows each application depends on, and which identity providers and attributes each flow references
• The applications and service principals your customers authenticate to
• Conditional Access policies and named locations that gate access
• Branding, including per-language variants
• Custom attributes and any API connectors invoked mid-journey
• Which administrators can change all of the above

This inventory is what turns "restore the tenant" into a set of verifiable steps, and it is also what tells you whether a partial restore is sufficient in a given incident.

Design the loop, not just the backup

A backup nobody verifies is an assumption. The working pattern is a loop:

1. Back up on a schedule into versioned recovery points, so you have more than the most recent state.
2. Verify against the live tenant — compare the newest recovery point to what is actually deployed, so you find out that a backup stopped matching reality within a day rather than during an incident.
3. Review drift and sort it into expected and unexpected. Tenants are supposed to change; the value is in the complete list.
4. Restore selectively when something is wrong, previewing before applying.

EIDGuard implements this loop directly — scheduled backups, nightly verification, a drift report, and a restore wizard that previews first. See Drift detection and daily operations.

Decide who can do what, before the incident

Recovery is a privileged operation and the plan should say who holds it. EIDGuard separates three roles: Viewer can read recovery points and reports, Operator can run backups, comparisons, previews and missing-only restores, and Admin additionally can apply overwriting (Full-mode) restores, rotate certificates, and change settings.

The useful property of that split is that the destructive capability — a restore that overwrites live objects — is deliberately separated from the everyday one. Decide during planning who holds Admin, and make sure it is more than one person.

Rehearse the restore

The step most plans skip. A restore you have never performed is a hypothesis.

A low-risk rehearsal that fits in a change window:

1. Take an on-demand backup, so you have a clean point to return to.
2. Pick a non-critical object — a test user flow or an unused policy — and delete it deliberately.
3. Restore it from the recovery point, reading the preview before applying.
4. Confirm it came back correctly, including any manual follow-ups such as re-entering an identity provider secret.
5. Record how long the whole thing took. That number, not an estimate, is your real RTO.

Repeat after significant changes to the tenant, and after any change to who holds the Admin role.

Know what no plan can restore

Some material cannot be exported from Microsoft Graph, so it is in no backup — anyone's. Passwords, application client secrets and certificate private keys, per-user MFA and passkey registrations, identity provider client secrets, federation signing keys, and branding image binaries all fall into this category.

Your plan should treat these as explicit manual steps rather than surprises: know where the source of truth for each secret is, and who can retrieve it. A restore that recreates an identity provider with a placeholder secret is only complete once someone pastes the real value in from the provider's console. Restoring from a recovery point lists the full set.

A minimum viable plan

If you do nothing else:

• Daily backups of every External ID tenant, into storage you control
• Nightly verification against the live tenant, with alerting on failure
• An on-demand backup immediately before any planned configuration change
• A written inventory of user flows, identity providers, and their dependencies
• One rehearsed restore, with the elapsed time recorded
• A named list of who can approve and perform an overwriting restore

That is enough to turn most identity incidents from a rebuild into a restore.