Microsoft Entra Backup and Recovery is GA: what it actually protects (and what it still doesn't)

Every Entra admin has a version of the same bad memory: a Conditional Access policy gets edited during a “quick cleanup,” a security group loses its dynamic membership rule, or a service principal’s SAML config gets overwritten by an automation script gone wrong — and there is no undo button. Soft delete saves you if an object disappears; it does nothing if the object is still there but wrong. Microsoft Entra Backup and Recovery, now generally available for Entra ID P1 and P2 tenants, is Microsoft’s answer to that specific gap. It’s worth understanding exactly what it covers before you tell your team it’s “handled.”

What it actually is

Backup and Recovery takes an automatic daily snapshot of a defined set of directory objects and lets you restore them to a previous state — no configuration, no agent, no opt-in toggle to forget. Supported objects include users, groups, applications, service principals, Conditional Access policies, named locations, authentication methods policy, and authorization policy. Backups retain up to seven days of history, and nobody in the tenant — not even a Global Administrator — can disable, delete, or tamper with them; that’s by design, so a compromised admin account can’t cover its tracks by nuking the backup along with the damage.

How a restore actually works

The workflow is two steps, and Microsoft is explicit that you should always do both in order:

1. Create a difference report first — pick a backup, and it computes exactly what changed between that snapshot and the tenant’s current state, attribute by attribute.
2. Recover — scoped to all supported objects, specific object types, or individual object IDs, based on what the difference report showed you.

Skipping straight to recovery without reviewing the diff is how you end up reverting changes you actually wanted. The first time you touch a given backup, expect a fixed data- loading delay before either operation starts; running the difference report first preloads that data and makes the subsequent recovery faster.

Two dedicated roles gate access: Microsoft Entra Backup Reader (view backups, diffs, and recovery history) and Microsoft Entra Backup Administrator (can also trigger diffs and recoveries — and this permission set is already included in Global Administrator). Assign Backup Reader to your identity ops team so they can investigate without needing full Global Admin.

The gaps that actually matter

This is the part worth reading twice before you update your incident runbook:

• Hard-deleted objects aren’t covered at all. Only soft-deleted or modified objects can be restored, and soft-deleted users, Microsoft 365 groups, cloud security groups, app registrations, and service principals only survive for 30 days regardless. Backup and Recovery restores properties and links from a backup — it doesn’t re-create something that’s been hard-deleted or has aged out of soft delete.
• On-premises-synced objects are excluded from recovery, even though changes to them still show up in difference reports. If you run hybrid identity, the source of authority is AD DS, and Backup and Recovery won’t push a change back there — you need your existing on-prem backup story for that. Converting an object’s source of authority to cloud-only brings it fully into scope, but recovering from a backup taken before that conversion won’t revert the source of authority back to on-prem.
• Group ownership and manager/sponsor changes aren’t in scope, even though the group or user object itself is. Same for dynamic group membership rules — the group can be restored, but a rule edit won’t roll back with it.
• Role assignments, PIM eligibility, and PIM policies aren’t backed up at all. If you read my earlier post on PIM for Groups, none of that configuration — role-assignable group membership, activation policies, approval settings — falls under this feature’s scope today.

Where this leaves your recoverability plan

Microsoft’s own guidance calls Backup and Recovery one part of a broader recoverability strategy, not a replacement for one, and explicitly recommends regularly exporting your known-good configuration via Microsoft Graph as a complement. For the object types this feature doesn’t touch — role assignments being the obvious one — that export is still on you. A simple scheduled job covers the gap for Conditional Access as a redundant, portable copy you control:

Connect-MgGraph -Scopes "Policy.Read.All" -NoWelcome

$policies = Get-MgIdentityConditionalAccessPolicy -All
$stamp    = Get-Date -Format "yyyy-MM-dd"

$policies | ConvertTo-Json -Depth 10 |
    Out-File "ca-baseline-$stamp.json"

Run that daily alongside a similar export for PIM role assignments and eligible-role policies, drop the output in a repo or storage account with its own retention, and you’ve closed most of the practical gap — without waiting on Microsoft to extend native backup coverage to those object types.

The takeaway

Turn Backup and Recovery on (there’s nothing to configure — check that your admin center already shows the Backup and recovery blade under Entra ID) and hand Backup Reader to whoever triages identity incidents. But don’t retire whatever process you use to snapshot role assignments, PIM configuration, or anything living in on-premises AD — this feature doesn’t reach any of that yet, and a difference report is only useful if someone actually runs it before, not after, they hit “recover.”

---

Sources & further reading: Microsoft Entra Backup and Recovery overview, Supported objects and recoverable properties, Recoverability best practices in Microsoft Entra ID, Microsoft Entra Backup and Recovery is now generally available.