Microsoft Entra ID is the front door to everything your organization runs — every sign-in, every access decision, every application handshake flows through it. Microsoft keeps that service extraordinarily available. But the contents of your tenant — the users, groups, applications, and Conditional Access policies you’ve built over years — are yours to protect. One deleted security group or one bad policy edit doesn’t take down Entra ID; it takes down you, while the platform hums along exactly as designed. 

This guide covers what Entra ID can recover natively, where the built-in safety net ends, why identity restore is harder than it looks, and how to build a backup and recovery strategy that actually holds up when something breaks. 

Does Microsoft Entra ID Have a Built-In Backup? 

No — Entra ID has no native backup, but it does have a genuinely useful 30-day recycle bin for some deleted objects. When a user, Microsoft 365 group, application, service principal, or administrative unit is deleted, it enters a soft-deleted state for 30 days and can be restored via Microsoft Graph (directory/deletedItems/restore) — with its original object ID, configuration, and relationships intact. That last part matters enormously: a natively restored user comes back with group memberships and app assignments still wired up, because the object never really left the directory. 

Credit where due: this is a better native story than most identity platforms offer, and any recovery strategy for Entra ID should use the recycle bin as its first move. But a recycle bin is not a backup — and the gaps are exactly where real incidents live. 

Where the Native Safety Net Ends 

The recycle bin catches one failure mode — deletion — for one subset of objects, for 30 days. Everything else is on you: 

• Security groups and distribution groups are not covered. Only Microsoft 365 (unified) groups support soft delete. Delete a security group — the kind that drives application assignments and Conditional Access scoping — and it is gone instantly and permanently. Recreating it produces a new object ID, which means every reference to the old group must be found and re-linked by hand. 
• Modifications aren’t deletions. The recycle bin does nothing for the far more common incident: an object that still exists but was changed. An edited Conditional Access policy, a rewritten dynamic group rule, a bulk attribute update gone wrong — there is no native “restore to how it was yesterday” for any of it. 
• Conditional Access policy restore is beta-only. Deleted Conditional Access policies have a soft-delete facility, but restoring them is currently only exposed through Microsoft Graph’s beta endpoint — not something to bet a production recovery on without a fallback. 
• The 30-day window is a hard stop. After 30 days, soft-deleted objects are purged. Discovery of a quiet deletion on day 35 means recreation from scratch — if you have a record of what the object looked like. 
• Applications and service principals restore separately. Restoring a deleted app registration does not automatically restore its service principal (or vice versa). Miss one half of the pair and single sign-on (SSO) stays broken. 
• Licenses don’t reassign themselves. A natively restored user gets memberships back, but license assignments may need to be reapplied before mail, Teams, and apps light up. 
• Some restores are Graph-only. Service principals and administrative units can’t be restored from the portal — you’ll be scripting against Graph in the middle of an incident. 

Why Is Restoring Entra ID Objects Harder Than It Sounds? 

Because identity objects are a dependency graph, not a pile of rows — and because the platform itself limits how fast you can write. Three realities shape every Entra recovery: 

• Recreated objects get new IDs. Unless the native recycle bin does the work, a recreated group or app is a different object wearing the same name. Group-based app assignments, Conditional Access include/exclude lists, and ownership references all point at the old ID. Real recovery tooling maintains an ID map and rewrites every reference — restoring objects in dependency order: users before groups, groups before memberships, apps before assignments, named locations before the policies that cite them. 
• Writes are throttled. Microsoft Graph enforces a directory write quota of 3,000 write operations per 2 minutes 30 seconds per app-and-tenant pair — roughly 20 writes per second sustained. Restoring a handful of objects is instant; recreating tens of thousands of users and re-adding hundreds of thousands of group memberships is an hours-long, potentially overnight, operation. This is precisely why recycle-bin-first orchestration matters: native restores preserve relationships and skip most of those writes. 
• The directory is eventually consistent. Microsoft’s own guidance warns that a freshly created object may not be immediately visible to subsequent calls — adding members to a just-recreated group can fail with “resource does not exist” until replication catches up. Restore tooling has to verify each wave before starting the next, with patient retries, or it collapses mid-cascade. 

And some things no backup vendor can restore, ever: passwords, MFA registrations and authentication methods, client secrets, and certificate private keys are not exportable from Entra ID by design. A restored user is a fully configured account that needs to re-enroll MFA; a restored app needs fresh secrets. Honest recovery planning builds those steps into the runbook instead of pretending they don’t exist. 

What Does a Real Entra ID Backup Strategy Look Like? 

A real Entra ID backup strategy captures configuration continuously, stores it independently of the tenant, and can restore any object with its dependencies intact — not just export CSVs to a file share. Six practices separate a strategy from a snapshot script: 

1. Inventory what actually matters. Conditional Access policies, break-glass accounts, role-assignable groups, the security groups driving app assignments, and your enterprise apps’ SSO configurations are tier-0. Know the blast radius of each before the incident. 
2. Capture continuously, not nightly. A nightly export means losing up to a day of joiner-mover-leaver activity and policy changes. Entra’s delta query capability makes change-driven capture practical — a recovery point minutes old instead of hours. 
3. Keep an independent, encrypted copy. A backup living inside the thing it protects isn’t a backup. Store versions outside the tenant, encrypted per tenant, with access controlled and audited. 
4. Restore with dependencies, not object-by-object. Demand recycle-bin-first orchestration (to preserve IDs), automatic reference re-linking when recreation is unavoidable, and correct ordering across waves. 
5. Rehearse scoped restores. A dry run that shows exactly what a restore would change — before it changes anything — turns recovery from a leap of faith into a reviewed change. 
6. Track who changed what. Entra audit logs are retained for 30 days with a P1/P2 license (7 days on the free tier), and they record events, not full before/after object state. A version timeline with side-by-side diffs answers the question audit logs can’t: what exactly did this look like before? 

How Beam Vault Protects Microsoft Entra ID 

Enter Beam Vault — a backup and point-in-time recovery add-on for Microsoft Entra ID and Okta, built into the Cyclotron Beam platform. Vault captures your tenant’s configuration continuously and can restore any single object, set of objects, or tenant-wide configuration to a chosen point in time: 

• Continuous change capture built on Entra delta queries, with scheduled baselines and manual snapshots. Premium-tier tenants get restore points minutes apart — targeting a recovery point objective (RPO) of 15 minutes or better — plus automatic pre-change snapshots before Beam runs a migration wave or policy push. 
• Coverage for the objects that cause incidents: users (profiles, managers, custom attributes), groups with memberships and owners — including the security groups the recycle bin ignores — dynamic membership rules, enterprise applications and service principals with SSO configuration and assignments, and Conditional Access policies with their named locations. 
• Recycle-bin-first restore orchestration. Vault checks for a native soft-deleted copy before anything else, preserving original IDs and relationships; when native restore isn’t possible — a purged object, a security group — it recreates from the versioned copy and re-links every reference through a dependency-aware plan. 
• A version timeline and diff for every object, so you can see exactly what changed between any two points in time — and who changed it, with Vault distinguishing external admin edits from Beam’s own migration writes. 
• Dry-run previews and verification reports. Every restore shows the exact changes it will make before executing, and produces a verification report after. Overwrite in place or restore as a new object — your call, reviewed either way. 
• Enterprise controls: role-based access control on every Vault action, optional four-eyes (dual-approval) restores on the Premium tier, an immutable audit trail of every browse, diff, and restore, and per-tenant envelope encryption with keys held in Azure Key Vault — on the same ISO 27001 certified platform that powers Beam migrations. 

Vault is equally explicit about what it will never claim: credentials, MFA registrations, and application secrets are not restorable by anyone, and Vault’s restore flow flags the re-enrollment and regeneration steps instead of hiding them. 

Frequently Asked Questions 

Does Microsoft Entra ID have a recycle bin? Yes — deleted users, Microsoft 365 groups, applications, service principals, and administrative units are recoverable for 30 days with their IDs and relationships intact. Security groups, distribution groups, and configuration changes are not covered. 

Can you restore a deleted security group in Entra ID? Not natively — security groups skip the recycle bin and are permanently deleted immediately. Recovery means recreating the group from a backed-up definition and re-linking every membership, app assignment, and policy reference to the new object ID, which is exactly what a dependency-aware backup tool automates. 

Can you back up and restore Conditional Access policies? You can capture them fully via Microsoft Graph, and that’s the reliable path: native restore of deleted policies exists only on the beta endpoint, and modified policies have no native rollback at all. A versioned backup with diffs is the dependable way to return a policy to a known-good state. 

Does Microsoft back up Entra ID for me? Microsoft keeps the Entra ID service highly available, but operates on a shared-responsibility model: your tenant’s data and configuration are your responsibility. The recycle bin is a convenience, not a backup commitment. 

How fast can Entra ID objects be recovered? Scoped restores — a policy, a group, a set of users — complete in minutes. Tenant-wide recovery is throttle-bound: Graph’s write quota (about 3,000 writes per 2.5 minutes per app and tenant) makes recreating very large estates an hours-long operation, which is why ID-preserving native restores and dependency-aware planning matter so much. 

Back Up the Tenant You Can’t Afford to Rebuild 

Entra ID gives you a real head start — a 30-day recycle bin that genuinely preserves relationships. But it was never designed to be your backup: security groups, policy changes, bulk damage, and anything older than 30 days fall straight through it. The pattern that works is the same one that works everywhere in identity: complete visibility before something breaks, a safety net after. 

Get in touch to see Beam Vault protecting a Microsoft Entra ID tenant — and see how fast recovery can be when the restore plan already knows your dependency graph.