Plan disaster recovery for Microsoft Entra External ID
Applies to Microsoft Entra External ID, EIDGuard
On this page
A disaster recovery plan for an application usually covers its databases, servers and storage. The identity tenant that customers sign in through needs the same treatment: Microsoft keeps the service available, but the configuration inside your tenant is yours to protect. This article describes how to decide what to protect, set recovery objectives, and prove that recovery works.
Identify the failure modes
Plan around the ways an External ID tenant actually breaks:
| Failure | Example | What recovery needs |
|---|---|---|
| Accidental deletion | A user flow or identity provider is removed | A copy of the deleted object and its dependencies |
| Unwanted change | A user flow loses an attribute, a policy is turned off | The previous value, and a record of what changed |
| Malicious change | A compromised administrator account alters access policies | A complete list of changes, and a way to reverse them |
| Broad damage | A script deletes many objects at once | Every affected object, restored in dependency order |
Only the first is a deletion. A plan that relies on Microsoft's recycle bin covers part of one row.
Understand what Microsoft recovers
Some deleted objects, such as users, groups and application registrations, can be restored for 30 days. Many objects that define the sign-in experience, including user flows, identity providers, branding and custom attributes, cannot be restored once deleted, and no object keeps its previous values after a change. For the details and Microsoft's sources, see Does Microsoft back up Microsoft Entra External ID?.
Set recovery objectives
Record two numbers for each tenant.
- Recovery point objective (RPO): the most configuration change you can afford to lose. It sets how often you back up. Configuration in a customer identity tenant tends to change around releases, so also plan to take a backup immediately before each planned change.
- Recovery time objective (RTO): how long sign-in can stay broken. Failures in customer sign-in are visible to customers at once, so this number is usually the harder one to meet. Meeting an RTO of hours requires restoring selectively from a known copy, not rebuilding from memory.
Check the objectives against what actually runs. If the RPO is 24 hours, backups must run at least daily and you must be told when one fails.
Inventory what must come back
For each tenant, record:
- the user flows each application uses, and the identity providers and attributes each flow references
- the applications and service principals your customers sign in to
- Conditional Access policies and named locations
- company branding, including each language
- custom user attributes and API connectors
- who can change each of these
The inventory turns "restore the tenant" into a list of objects you can check, and shows whether restoring one resource type is enough in a given incident.
Back up, verify, review, restore
A backup that is never checked is an assumption. A working routine has four parts:
- Back up on a schedule into versioned recovery points, so you can go back further than the latest state.
- Verify against the live tenant by comparing the newest recovery point with it, so a backup that stopped matching the tenant is found within a day.
- Review the differences and separate expected changes from unexpected ones.
- Restore selectively, after previewing what the restore will do.
EIDGuard follows this routine. Each tenant is backed up on its own schedule, by default every tenant's newest recovery point is compared with the live tenant daily, and the restore wizard previews every restore before it can be applied. See Back up tenants, Verify backups and detect drift and Restore from a recovery point.
Decide who can restore
Decide before an incident who may run a restore. EIDGuard has three roles:
| Role | Can |
|---|---|
| Viewer | View recovery points, reports and jobs |
| Operator | Run backups and comparisons, preview any restore, and apply restores that only recreate missing objects of types that cannot grant access, such as users, identity providers and Conditional Access policies |
| Admin | Everything an Operator can, plus restores that overwrite existing objects, restores of types that can grant access again (such as groups, applications, user flows and directory roles), and configuration changes |
Assign the Admin role to more than one person, so a restore does not wait for one administrator. For the full list, see Manage access.
Plan for what no backup contains
Microsoft Graph does not export some data, so no backup contains it. A restore recreates the affected objects and lists the follow-up work. Plan these steps in advance:
- Identity provider client secrets. Record where each secret is managed and who can retrieve it.
- Application client secrets and certificates. A recreated application has a new application (client) ID, so the applications that sign in with it need its new ID and a new credential.
- User passwords and MFA registrations. Recreated users must set a new password and register their MFA methods again.
- Branding images. Keep the logo, banner and background files.
For the full list, see What a restore cannot bring back.
Rehearse a restore
Rehearse in a non-production External ID tenant that is backed up the same way as production:
- Run a backup so you have a current recovery point.
- Delete a test object, such as a test user flow.
- Restore it from the recovery point, and read the preview before applying.
- Complete the follow-up work, such as entering an identity provider secret.
- Sign in through the restored flow.
- Record how long the rehearsal took. Use that time, not an estimate, as your achievable RTO.
Repeat the rehearsal after significant changes to the tenant and after changes to who holds the Admin role.
Minimum plan
At a minimum:
- back up every External ID tenant at least daily, into storage you control
- verify each tenant's newest recovery point against the live tenant daily, with alerts on failure
- back up immediately before every planned configuration change
- keep an inventory of user flows, identity providers and their dependencies
- rehearse one restore and record the time it took
- name the people who can approve and apply a restore