When people say "back up Azure AD" they usually picture users and groups. Those matter, but they are the smallest part of the problem. The thing that actually runs your tenant is a graph of policies and relationships: who can sign in from where, which apps hold which permissions, who is eligible for which privileged role, what the conditional-access rules are, and which service principal a critical integration depends on. Lose or corrupt any of those and "restore the users" does not help.
A backup that is faithful to Entra ID has to capture the whole graph. In our snapshot that comes to thirty-three distinct object types, and this note walks through what they are and what it takes to put them back.
The directory is a graph
The reason identity recovery is hard is that objects reference each other. A conditional-access policy names groups and named locations. A role assignment points at a principal and a role definition. An app registration owns credentials and is paired with a service principal that carries the actual permission grants. Restore an object without its references and you get an orphan; restore the references in the wrong order and the write fails.
So the object model is not a flat list — it is a set of related types that have to be captured together and re-applied in the right sequence, with identifiers remapped where the platform assigns new ones on recreate.
The thirty-three object types
Principals and access: users, groups (with membership), administrative units, directory roles, and role assignments.
Privileged access: PIM eligible assignments, PIM active assignments, and PIM role-management policy settings.
Conditional access and its inputs: conditional-access policies, named locations, authentication-methods policy, authentication-strength policies, and authentication-context references.
Applications and consent: app registrations, enterprise apps / service principals, and OAuth2 permission (consent) grants.
Tenant configuration: organization settings, security-defaults enforcement, terms-of-use agreements, cross-tenant access policy, cross-tenant partner settings, and custom security-attribute definitions.
Devices and endpoint management: devices, Intune device configuration, configuration (settings-catalog) policies, compliance policies, app-protection policies, endpoint-security policies, scripts, app configuration, remediations, plus BitLocker recovery keys and Windows LAPS policy.
License-gated types — PIM without a P2 license, for instance — are recorded as not-applicable rather than as failures, and a permission-denied read is surfaced as a re-consent prompt instead of a silent gap. Delta-queried categories carry prior items forward, so a snapshot with no changes never shrinks.
Drift, with severity
Capturing the graph on a schedule means you can compare any two snapshots and see exactly what changed — and rank it. A deleted conditional-access policy or a newly created Global Administrator assignment is scored CRITICAL. A modified conditional-access policy is HIGH. A changed app registration, service principal, or PIM setting is MEDIUM; routine user, group, or device edits are LOW. The point of the severity is not decoration — it is so the one change that matters is not buried under the thousand that do not.
Four ways to put something back
From the recycle bin. Within Microsoft's 30-day window, a soft-deleted object is restored in place. Simple, and the first thing to try.
Field-level. Sometimes only one attribute is wrong — a flipped account-enabled flag, a changed UPN. You can revert a single field of a single object to its snapshot value without touching anything else.
Recreate from backup. When an object is hard-deleted or aged past the recycle bin, it is rebuilt from the snapshot, its attributes, licenses, manager, and memberships re-applied, and new identifiers remapped so the references still resolve.
Exact-state (destructive) rollback. When an attacker created objects, reverting means deleting what should not exist. This is the sharp tool, so it is fenced: it is blocked outright while a legal hold is in force, it refuses to delete the last Global Administrator, and it refuses to delete a registered break-glass account. The system will not let a "recovery" lock you out of your own tenant.
Emergency-access accounts are a first-class object: registered, health-checked for MFA and sign-in alerts, password-rotated on a schedule, with credentials held in escrow and an access log. That is what lets a destructive rollback safely refuse to touch them.
The boundary we are deliberate about
This is cloud identity protection — Entra ID. It is not on-premises Active Directory forest recovery. We capture the on-prem-reflected attributes that Entra exposes on cloud objects so a recreate is faithful, but we do not back up domain controllers, and we do not perform an AD forest rebuild. That is a genuinely different discipline, and the vendors who specialise in it do it well; if your risk model centres on an on-prem AD forest, that is the right tool for that job.
What VentraID is built for is the tenant most managed-service providers actually run: cloud-first, Entra-centred, changing every day, and sitting right next to the Microsoft 365 data we already back up. Protecting the directory and the data it governs from one platform — with drift you can rank, restores you can scope to a single field, and rollbacks that refuse to lock you out — is the job we set out to do.