Restoring from a recovery point
Applies to: EIDGuard for Microsoft Entra External IDEvery EIDGuard backup is a full recovery point. From the dashboard you can restore a single deleted object, one resource type, or the whole tenant — and every restore starts as a preview, so you always see exactly what would change before anything does.
The two rules every restore follows
- Preview first. The restore wizard always runs a read-only preview (WhatIf) and shows you the exact list of actions. Nothing is written until you review that list and explicitly apply it.
- Missing-only by default. A standard restore only creates objects that no longer exist; objects still present in the tenant are left untouched. Overwriting existing objects is a separate, deliberate choice that requires the Admin role.
Running a restore
Open Recovery points, choose the tenant, and pick the recovery point to restore from — usually the last one taken before the problem. Select Restore to start the wizard, which moves through four steps:
1 — Resources
Choose what to restore: everything, or just the affected resource types (for example, only Conditional Access policies). Whatever you select, EIDGuard restores in dependency order — attribute definitions and identity providers before users and apps; user flows, Conditional Access, and role assignments after the objects they reference.
2 — Mode
| Mode | What it does | Who can apply it |
|---|---|---|
| Missing only (default) | Recreates objects that are gone; never touches existing ones. | Operator or Admin |
| Full | Also overwrites existing objects whose configuration differs from the recovery point. | Admin (Operators can preview, but not apply) |
Missing-only is the right choice for accidental deletions — the common case. Full mode is for rolling back unwanted changes or disaster recovery, and the dashboard treats it with matching seriousness: the apply button becomes Apply disaster recovery and asks for confirmation.
Tenant-wide singletons (such as authorization policy settings and default branding) are only restored in Full mode, since restoring them always means overwriting.
3 — Preview
Select Run preview (WhatIf). The preview runs as a job you can watch live, and produces the full list of intended actions — object by object: create, update, or already present. Nothing has changed in your tenant yet. Review the list; if it isn't what you expected, adjust the resource selection or pick a different recovery point and preview again.
4 — Apply
Apply starts the restore job. Progress and per-object results stream to the screen, and the job is kept in Jobs for your audit trail. The results page shows two things:
- Restore results — every object, with the action taken and its outcome.
- Manual actions required — the follow-ups EIDGuard can't do for you (see the table below), listed explicitly so nothing is forgotten.
Built-in safety behavior
- Restored Conditional Access policies are always created disabled, so a restored policy can never lock anyone out before you've reviewed it. Re-enable each one deliberately after checking its assignments.
- Restores are idempotent. Running the same restore twice doesn't create duplicates — existing objects are matched and reported as already present.
- References are remapped automatically. Objects recreated in a tenant get new IDs. EIDGuard tracks every old-to-new mapping during the restore and rewrites references — group members, policy scopes, user-flow app links, role assignments — so restored objects point at each other correctly.
- The restore identity is separate. Restores are the only operation that uses the read-write app; backups and comparisons run read-only.
What a restore can't bring back
Microsoft Graph does not allow some material to be exported, so no backup contains it. EIDGuard restores these objects with placeholders and lists each one under Manual actions required:
| Not restorable | What happens on restore |
|---|---|
| User passwords | Users are recreated and must reset their password on first sign-in. |
| App client secrets & certificate private keys | App metadata is restored; issue new credentials afterwards. |
| Per-user MFA / passkey registrations | Users re-register their methods. |
| Identity provider client secrets | The provider is recreated with a placeholder secret — paste the real one from the provider's console. |
| Federation signing keys | Re-establish federation with the partner. |
| Branding image binaries | Text and color settings are restored; re-upload logo images. |
Before you restore: find the right recovery point
Not sure which recovery point predates the damage? Use the Drift page to compare recovery points against the live tenant (or against each other) and pinpoint when the unwanted change appeared — then restore from the last clean point. You can also click into any recovery point to browse the objects it contains before committing to it.
