Backup vendors optimise restores for speed, and the instinct is right for files. A user deleted a spreadsheet; the faster it comes back, the better, and a mistake costs almost nothing because the worst case is a duplicate document.
Identity is not files. A restore into a live directory is a write against the system that decides who can do what, and the failure mode is not "nothing happens".
Four restores that work perfectly and are wrong
Each of the rows below is a technically flawless restore. Each reverses a decision somebody made deliberately. None of them produces an error, an alert, or a ticket.
| Object restored | Intended state | Who notices, and when |
|---|---|---|
| Terminated employee account | Deleted on the offboarding date | Nobody. It authenticates normally |
| Revoked administrative role | Removed after an incident | Nobody, until the next privileged action |
| Deleted Conditional Access policy | Retired as too permissive | Nobody. The gap reopens silently |
| Removed group membership | Access withdrawn deliberately | Nobody. Licences and data follow the group |
The gate, and why the slowness is the feature
A restore here is raised as a request, scoped to specific objects and a specific snapshot. An administrator approves it before anything is written. Request, approval and outcome are recorded together.
This is the least popular thing about the platform in a demo and reliably the most appreciated thing about it eighteen months in. It adds minutes to an operation that happens rarely, in exchange for removing an entire class of silent, unattributable change to a production directory.
There is a second control alongside it: the platform refuses to restore anything a snapshot recorded as already deleted. A point-in-time restore therefore cannot resurrect a terminated account as a side effect of recovering something else — which is the specific failure that makes row one of the table above so unpleasant.
Where the gate belongs, and where it does not
Applying this to file restores would be obstructive, and we do not. The distinction is whether the restore changes the security posture of a live system. Mail and documents do not; directory objects, roles, policies and group memberships do.
If you are evaluating platforms, the question is narrow: for an identity restore, who approves, and is the approval recorded separately from the request? A single account that can both ask and act is not an approval workflow, however the UI describes it.
The offboarding case is the one to think through. A restore run to recover an unrelated object, at the wrong scope, reinstates a leaver. Nothing alerts, because from the directory's point of view a valid administrator restored a valid object.