For years the argument for third-party Entra ID backup was easy, because Microsoft did not offer one. That argument is now obsolete. Microsoft Entra Backup and Recovery is generally available, it is on by default, and any MSP still selling against "Microsoft gives you no undo" is selling against a product that no longer exists.
So the honest question is narrower and more useful: given what Microsoft now ships, what is left for an independent copy to do?
Everything quoted below comes from Microsoft own documentation, retrieved 15 August 2026. Microsoft changes this product often, and the page itself says so, so check the current version before you make a decision on it.
What Microsoft actually shipped, stated fairly
It is a good product and it deserves to be described accurately rather than minimised.
Microsoft describes it as "a built-in backup and recovery solution that lets you recover critical Microsoft Entra directory objects to a previously known good state after accidental changes or security compromises." Supported objects are "users, groups, apps, service principals, Conditional Access policies, named locations, authentication method policy, and authorization policy (selected properties)", plus Agent ID.
Backups run "automatically, once a day, retaining up to seven days of backup history." Administrators can view available backups, generate difference reports comparing a backup against current tenant state, recover all supported objects or specific object IDs, and review recovery history.
One capability deserves particular credit, because very few backup products can claim it: "No signed-in user or application, even with the highest admin privileges, can turn off, delete, or modify backups in the tenant." A compromised Global Administrator cannot destroy these backups. That is a stronger guarantee than most third-party tools offer, and if your objection to native backup was "an attacker with GA just deletes it", that objection is answered.
If you are protecting a single tenant with P1 or P2 licences, against the failure mode of somebody changing something they should not have and noticing within the week, this is sufficient. Say so to your clients. Credibility you spend defending an outdated claim is credibility you do not have when it matters.
Limit one: seven days
Retention is "up to seven days of backup history". That is the number that determines what class of incident you can actually recover from.
Seven days is generous for a fat-fingered change on Tuesday found on Wednesday. It is not enough for the failure mode that actually hurts in identity: slow drift. A Conditional Access exclusion added quietly, a service principal granted a permission it should not hold, a policy relaxed during an incident and never restored. These are found during a quarterly review, an audit, or a breach investigation, and by then the known-good state you want is months behind you.
It is also not enough for a dwell-time compromise. Median attacker dwell time is measured in weeks, not days. If the state you need to compare against is older than seven days, the built-in solution cannot show it to you, because it no longer exists.
Limit two: hard deletes are explicitly out of scope
Microsoft is direct about this: "Microsoft Entra Backup and Recovery doesn’t support the recovery or re-creation of hard-deleted objects."
Soft deletion still works as it always has. Microsoft notes that "soft-deleted users, Microsoft 365 Groups, cloud security groups, application registrations, and service principals can be restored for 30 days." So the ordinary accidental deletion is well covered by two mechanisms.
What is not covered is the object that was hard-deleted, or that was soft-deleted and then aged past its 30-day window before anyone noticed. That is precisely the shape of a malicious deletion, where the attacker intends the object not to come back, and of the quiet cleanup that nobody notices until an application stops authenticating months later.
Limit three: it lives in the same blast radius
Microsoft states that "backup data resides securely in the same geo-location as the Microsoft Entra tenant, determined during tenant creation."
This is the structural point, and it has nothing to do with how good the product is. A backup that lives inside the thing it protects shares that thing’s fate. It is excellent protection against changes within a healthy tenant. It is not a second copy in the sense a disaster-recovery plan means the phrase.
The scenarios it does not answer are the ones that end a business rather than ruin a morning: tenant-level lockout, a licensing or billing dispute that suspends access, a subscription lapse, a tenant migration or merger, a regulator or auditor asking for evidence of state on a date you can no longer reach, or the client leaving you and taking their tenant with them while you still owe them a records obligation.
This is a standard resilience argument, not a criticism of Microsoft. Nobody argues that a RAID array is a backup, and for the same reason.
Limit four: licence and tenant-type prerequisites
The tenant "has Microsoft Entra ID P1 or P2 licenses". If a client is on Business Premium without the relevant identity licensing, or on a plan you have not upgraded, the safety net you assumed was there is not there.
The tenant must also be a "workforce tenant" — Microsoft states that "External ID and Azure AD B2C tenants aren’t supported." If you run customer identity for a client, the built-in solution does not cover it.
Worth an inventory pass across your estate before you rely on it: which of your tenants actually qualify, and which have silently had no identity backup at all.
Limit five: hybrid, and where Microsoft sends you elsewhere
For organisations synchronising from Active Directory Domain Services, Microsoft says difference reports can identify changes to synchronised objects, and that for some object types you can move the source of authority to the cloud.
Then it says this, in its own documentation: "Use an alternative solution to back up and recover objects managed in AD DS."
That is Microsoft telling you the built-in product does not cover the on-premises side. Their limitations page is more specific still: changes to on-premises synced objects, group memberships aside, appear in difference reports but are “automatically excluded from recovery”. So for a hybrid tenant you can see what changed and still not be able to roll it back. If your client is hybrid, and most mid-market clients still are, a meaningful part of the identity estate is outside its scope by design.
What is not on the supported list
Be careful here, because this is where vendors overreach and get caught. Microsoft publishes a list of supported objects. Some things an identity administrator would care about are not on it as of 15 August 2026 — directory role assignments, Privileged Identity Management configuration, and administrative units among them.
Absence from a published list is not the same as a documented exclusion, and Microsoft states plainly that it "regularly improves and expands the solution to support more directory objects and more attributes." What is on that list will very likely be longer next quarter.
The practical instruction is simply to read the current supported-objects page against your own recovery requirements rather than assuming either direction. And note the parenthetical Microsoft attaches to authorization policy: "(selected properties)". Coverage of an object type is not always coverage of everything on it.
So what is an independent copy actually for?
Not as a replacement. Microsoft’s own guidance is to "use Microsoft Entra Backup and Recovery as part of a broader approach to recoverability that helps your organization be more resilient." That is the correct framing and we would not put it differently.
An independent copy earns its place on four things the built-in product does not attempt. Retention long enough to reach the state you actually want, rather than seven days. Storage outside the tenant, so the copy survives the tenant. Coverage that includes what you are told to look elsewhere for. And an evidence trail that is meaningful to a third party, because "we restored it from the tenant that was compromised" is a weaker sentence in front of an auditor than it sounds in an incident call.
If none of those four matter for a given client, the built-in product is enough and you should tell them so.
How to have this conversation with a client
Lead with what Microsoft gives them, accurately. Then ask three questions, and let the answers decide it rather than the pitch.
How far back would you need to go to prove what your identity configuration looked like? If the honest answer is longer than a week, seven days does not cover it.
If you lost access to the tenant itself, where is the copy? If the answer is "in the tenant", there is no second copy.
What is in your estate that Microsoft says to cover another way — hybrid objects, External ID tenants, tenants without P1 or P2? That is the gap, and it is stated by the vendor rather than argued by us.
Every claim in this article is quoted from Microsoft documentation retrieved 15 August 2026. Microsoft revises this product frequently; verify against the current pages before making a purchasing decision either way.