Recovering objects in Microsoft Entra has historically been one of those tasks that is theoretically possible but practically painful. Soft-deleted users have a 30-day window, hard-deleted objects are gone for good.
For years, admins have gotten around this gap with third-party tools, Graph API snapshots, and scripts. Microsoft is now addressing part of it directly with Entra Backup and Recovery, which entered preview on March 19, 2026. Here are my early impressions after running a couple of real recovery test.
What It Actually Does
Entra Backup and Recovery takes daily automated snapshots of your tenant and retains the last five days. Supported object types include users, groups, applications, service principals, Conditional Access policies, named locations, authentication method policies, and authorization policies. When something changes, you can compare the affected objects against a backup, see exactly what changed, and roll back the specific attributes that were modified…. AWESOME !
The workflow follows three steps. First, you view available backups in the Entra admin center under Backup and Recovery. Second, you create a difference report comparing a chosen backup against the current state of the tenant. The report shows only changed objects, filtered by object type or specific object ID if you know what you are looking for. Third, you trigger a recovery for the objects or attributes you want to restore.
This is a different approach, but i actually like it – well apart from the wait… more on that later.
The recovery model is worth understanding upfront, if an object was updated since the backup, recovery rolls it back to the backup value. If an object was added since the backup, recovery soft-deletes it. If an object was soft-deleted since the backup, recovery restores it.
Two things the service will never do: hard-delete an object as part of recovery, and recover an object that has already been hard-deleted. Hard deletion is a one-way door, and Entra Backup and Recovery does not change that… sadly !
If a user was hard-deleted before you caught the problem, this tool cannot help…. a major shortcoming in my mind.
One prerequisite worth noting upfront: you need Microsoft Entra ID P1 or P2 licensing.
Running a Real Recovery
For my test I used a straightforward scenario: a cloud-only user account with a single attribute change.
The recovery itself was not the interesting part. Once the difference report confirmed what had changed and I initiated the recovery, the job completed in seconds… easy peasy.
What I had not accounted for was the time to get there. The difference report, which has to run before you can make any recovery decisions, took one hour and twenty-three minutes. For a tenant with one changed attribute on one user… an in my tiny test tenant with ca 20 users.
I will be honest: sitting and waiting for that report felt absurd. I kept checking back, wondering whether something had gone wrong.
It is documented behavior, but nothing in the interface communicates that this is expected… bit of googling learned me that the reason it takes so long is that the first time you access a particular backup through a difference report, the service has to load the entire tenant snapshot before the comparison can even start, for tenants with up to 50,000 objects, Microsoft documents up to one hour for this initial data loading alone…. but just to be clear, in my tests – its not just the first job.
The loading step is a fixed cost regardless of how small the change you are looking for actually is. One attribute change on one user still requires the full snapshot to be loaded first.
The important nuance is that this cost is paid once per backup. If you run a difference report against a backup and then initiate a recovery from the same backup, the data is already loaded and the recovery runs almost instantly, which is exactly what I experienced…. but how often will that play out in the real world… with 5 retained backups only.
If you go into a real incident expecting to pull up a backup and act quickly, the first hour will blindside you.
This needs to be in your incident response playbook before you need it.
The Five-Day Retention Problem
The daily backup with five days of retention is the part that deserves the most scrutiny.
Five days covers the obvious, fast-moving scenarios: an admin makes a configuration change that breaks something, a Conditional Access policy gets modified incorrectly, someone accidentally alters user attributes during a provisioning run, Ii you catch it within the week, the backup window is fine.
The problem is that many significant directory changes are not caught within five days, security incidents involving identity compromise often sit undetected for weeks.
A threat actor who quietly modifies service principal permissions or adjusts authorization policies as part of a longer campaign will not be discovered in time…. and that is my main pain point here-..
An admin error that changes something subtle may not surface until a user raises a ticket days later. In those scenarios, the backup you need no longer exists.
Microsoft acknowledges this directly in the documentation, noting that the feature should be used as part of a broader approach to recoverability.
Where This Actually Fits
For smaller organizations running cloud-only or predominantly cloud-managed Entra environments, this feature is genuinely useful and fills a gap that previously required third-party tooling or custom Graph API work.
They get real value from this, the workflow is straightforward, the coverage is meaningful for that environment, and the absence of a native backup option has always been a legitimate complaint
For larger enterprises, particularly those running hybrid identity with on-premises Active Directory synchronization, the picture is significantly more limited. On-premises synced objects appear in difference reports, which is useful for tracking, but they cannot be recovered through this tool….the source of authority is still on-premises AD, and recovery has to happen there. In a typical enterprise environment where most user and group objects are synced from AD, this makes Entra Backup and Recovery largely theoretical for the object types you most need to protect. You can see what changed, you cannot fix it here.
If your estate is hybrid and AD-heavy, the native tool covers your Conditional Access policies, authentication method configurations, and cloud-native objects, which still has value. But calling it enterprise-grade identity backup would be overstating it at this stage.
My takeaway
Entra Backup and Recovery is a real step forward for cloud-native environments.
The gap between promise and reality right now comes down to two things: the difference report wait time is genuinely painful and will catch people off guard in a real incident, and the five-day retention window combined with the hybrid identity limitation means most enterprise environments cannot rely on this as a primary recovery strategy.
Run the difference report before you need the recovery. Understand what the wait actually means. And if you manage a hybrid environment, do not mistake having this feature enabled for having a real identity recovery capability…. Good old AD backups including recovery tests are vital
And while we talk AD , remember to activate the recycle Bin, I still see surprisingly many customers without this ancient feature enabled.
Have a good day 🙂
Relevant documentation:
- Microsoft Entra Backup and Recovery overview: Feature overview, prerequisites, and licensing
- Backup, difference report, and recovery model: Timing expectations and recovery model details
- Supported objects and recoverable properties: Full list of what is and is not in scope
