Entra ID backup is the kind of gap that never shows up on a status dashboard, because there is no dashboard for it. Microsoft 365 gets backed up. VMware gets backed up. Then the identity system that decides who can log in to any of it, Entra ID, sits there uncovered, because it "feels" like Microsoft's job to protect its own directory. It isn't, and the businesses that find that out the hard way usually find out during an incident, not before one.
This is a walk through what actually lives in Entra ID, what a bad deletion or a compromised admin account really costs to unwind, where Microsoft's native recycle bin does and doesn't help, and how MSPs can add Entra ID backup to a stack without turning it into a science project.
What actually lives in Entra ID
Entra ID (the product most people still call Azure AD out of habit) is not just a list of usernames and passwords. A working tenant holds users and their group memberships, role assignments that decide who has admin rights over what, administrative units that scope delegated management to a business unit or region, enterprise applications and app registrations that every SSO integration depends on, and Conditional Access policies, the rules that decide whether a login from a new country gets waved through or blocked outright.
Lose any one of those quietly and the blast radius is bigger than it looks. A deleted Conditional Access policy doesn't just misfire once, it changes how every subsequent login in the tenant gets evaluated until someone notices and rebuilds it from memory. A deleted administrative unit breaks the delegated-admin boundaries a business set up to keep regional IT teams out of each other's users. None of this is exotic; it's ordinary tenant hygiene work, done by an ordinary admin account, which is exactly what makes it risky.
What a deletion or misconfiguration actually costs
The expensive version of this problem is rarely a dramatic breach. It's a script that runs against the wrong object filter and removes forty groups instead of four. It's an offboarding process that deletes a user before someone checks whether that user owned any enterprise applications or approval flows. It's a phished admin account making changes that look, to every other admin, like routine tenant maintenance right up until something stops working.
What makes Entra ID incidents different from a deleted SharePoint file is that the damage is structural. Rebuilding a Conditional Access policy from a screenshot, if anyone thought to take one, is manual and error-prone. Rebuilding group memberships and role assignments across a few hundred users from memory is worse. There is no "restore to yesterday" button for a tenant's overall configuration state, because Entra ID was never built with point-in-time recovery in mind. It was built to run identity, not to remember what it looked like last Tuesday.
Why the native recycle bin doesn't close the gap
Microsoft does give Entra ID a recycle bin, and it's worth being precise about what it actually covers rather than assuming it behaves like the SharePoint one. Deleted users, groups and application registrations go into a soft-deleted state and stay recoverable for 30 days, with every attribute and relationship restored intact if you catch it in time. That 30-day window is fixed. Microsoft's own documentation confirms it can't be extended, not even with a premium licence, and once it lapses the object is gone for good.
The bigger catch is coverage. For a long time, Conditional Access policies had no soft-delete state at all, deleting one was simply permanent. Microsoft has since added a 30-day recovery window for Conditional Access too, but as multiple admins documenting the change have noted, it's a recovery mechanism, not a backup, a stopgap for "I clicked delete by mistake five minutes ago," not a way to reach back further or keep history beyond a month. Administrative units are a good example of an object type that still sits outside the standard recycle bin experience, so losing one isn't something a standard admin can self-serve back. And recovery of whatever is covered still needs a Global Administrator or User Administrator to action it, which is one more reason a stolen high-privilege account is such a good outcome for whoever stole it.
None of this is a criticism of Microsoft's engineering. A recycle bin is a sensible safety net for "I clicked the wrong button." It was never marketed as backup, and Entra ID backup is exactly the layer it doesn't provide: independent, retained beyond 30 days, and recoverable to a point in time rather than to "however it looked right before it was deleted."
How third-party Entra ID backup actually works
A dedicated Entra ID backup product runs on top of the tenant, not inside its recycle bin. Keepit, the platform we distribute, connects to a tenant with read-only permissions and takes independent snapshots of users, groups, role assignments, administrative units, enterprise applications, app registrations, Conditional Access policies, and the audit and sign-in logs that show who did what and when, according to Keepit's own service description. Because the copy lives outside Microsoft's infrastructure on Keepit's own storage, it survives scenarios where the problem is inside the tenant itself, a compromised Global Admin account, a Microsoft-side outage, or a ransomware actor who has already worked out how to touch native retention settings.
That independence is the entire point. A backup that lives inside the same tenant it's protecting shares its blast radius. If an attacker has enough access to do damage to Entra ID, they typically have enough access to tamper with anything sitting alongside it. Storage outside the tenant, ideally with its own immutability, is what turns "we have a copy" into "we have a copy we can actually trust after an incident."
Recovery is the part that matters when it's 2am and something's broken. Instead of manually recreating a Conditional Access policy or a group's membership list from memory or an old export, granular Entra ID backup lets an admin restore a single object, or the whole directory's state, back to a specific point before things went wrong. That's the difference between an afternoon of careful reconstruction and a recovery that's done before the help desk queue even builds up.
Adding Entra ID backup to your MSP stack
For MSPs already selling Microsoft 365 backup, Entra ID is the natural next line rather than a separate sales conversation. It sits in the same conversation as SaaS backup generally: the client already accepts that Microsoft's shared-responsibility model puts recovery on them, not Microsoft, for the mailbox and SharePoint data they use every day. Identity is the same argument, just less visible, because nobody notices Entra ID is unprotected until the day they need it to have been.
It's also an easy add technically. Where a platform like Keepit already covers Microsoft 365, adding Entra ID is usually a licensing and connector step rather than a new deployment, so it drops into an existing managed-services engagement instead of requiring its own onboarding project. The pitch to a client doesn't need to be alarmist: it's simply that the system deciding who can access everything else deserves the same recovery guarantee as the data it protects.
For partners building this into their stack, it's worth treating Entra ID backup as a standard line in every Microsoft 365 backup quote rather than an upsell reserved for security-conscious clients. The clients who'll actually need it are rarely the ones who'd have thought to ask.
If you'd like help positioning Entra ID backup for your client base, or want to see how it fits alongside the rest of a Microsoft 365 protection stack, talk to us about the partner programme. It's a short conversation, and for most partners it closes a gap they didn't realise was sitting open in every Microsoft 365 client they have.