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. 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
For mail and files the gate sits on restores that write into the live location: when the MSP restores side by side into a staging folder, the restore runs straight away, because it cannot overwrite anything. Directory objects, roles, policies and group memberships change the security posture of a live system, which is why a restore request from a VentraID snapshot is approved before anything is written. Two narrower tools sit outside that gate and are written to the audit trail instead: reverting fields of a live object to their values in a snapshot, and recovering an object from Microsoft's own recycle bin.
If you are evaluating platforms, the question is narrow: for an identity restore, who approves, and is the approval recorded separately from the request?
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.