SaaS backup for Entra ID now centers on recovery gaps

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Cayosoft's research: SaaS backup for Microsoft Entra ID is shifting from an assumed provider responsibility to a governed recovery requirement as native recovery proves limited for deletion, corruption, misconfiguration, and malicious change.

Why it matters: Identity teams cannot treat Entra ID state as self-healing when policy changes, object deletion, and role relationships may outlive native recovery windows and break dependent access paths.

By the numbers:

• Entra ID’s Recycle Bin covers a limited set of object types for 30 days.
• Native audit logs retain policy updates for 30 days by default.

Context

A recovery gap emerges when an identity platform can record that something changed but cannot reliably restore the prior access state after the fact. In Microsoft Entra ID, that matters because users, groups, policies, app role assignments, and privileged access relationships are all part of the control plane, not just the data plane.

For identity and access teams, backup is therefore a governance issue as much as a technical one. If restore scope, retention, and ownership are undefined, the organisation is depending on native limits it may not have mapped explicitly. SaaS backup governance becomes critical when directory state and policy state drive downstream access across Microsoft 365.

Key questions

Q: What should teams do first when Entra ID objects are deleted or misconfigured?

A: Teams should restore the last known-good state first, starting with the deleted or misconfigured directory object, its assignments, and any linked policies or groups. In Entra ID, object deletion, broken group membership, or changed app registrations can disrupt authentication and authorisation even when the tenant still exists. Preserve a clean restore point before changing anything else.

Q: Why does restoring a deleted directory object not always fix access?

A: Restoring a deleted directory object does not always fix access because the object may come back with the same display name but a different identity relationship, while object IDs, policy scope, and app assignments can still be broken or stale. Access decisions often depend on exact identifiers, group membership, consent, and conditional access targeting, not just the object’s presence.

Q: How should teams back up identity policies in Microsoft Entra ID?

A: Identity policies in Microsoft Entra ID should be backed up as a recoverable configuration that captures the settings, assignments, scopes, and dependencies needed to recreate access behaviour. That includes conditional access rules, role assignments, group memberships, app registrations, and privileged access settings, because policy state is often distributed across multiple objects rather than stored in one file.

Q: How do organisations test SaaS backup for identity recovery?

A: Organisations test SaaS backup for identity recovery by running restore tests that verify directory objects, group memberships, application registrations, and policy settings can be recovered into a working state. A useful test checks whether users can authenticate, applications can be authorised, and privileged roles and conditional access behave as expected after the restore.

Technical breakdown

Why native Entra ID recovery stops at the retention window

Entra ID’s native recovery model is bounded by object type and time. Soft-deleted objects can be recovered only for supported objects and only while they remain in the recycle window; hard-deleted objects fall outside that path entirely. Once the object is purged, any recreation produces a new object ID, which breaks references that were bound to the original identity state. That distinction matters because access control in Entra ID is relational, not just object-based. Policies, app roles, and privileged access eligibility all point to specific IDs, so recovery is as much about preserving relationships as it is about restoring records. See the Identity Recovery Guide.

Practical implication: Treat restore testing as a relationship-preservation exercise, not just an object-return exercise.

How policy and role drift turn recovery into an access problem

A deleted user or group is only one failure mode. The more operationally expensive case is when a policy change, break-glass exclusion, or privileged role assignment is altered in a way that changes who can authenticate or what they can reach. Native logs may show that a policy changed, but they rarely preserve enough before-and-after context to reverse the exact state quickly. In a mature Microsoft identity environment, the hard part is not noticing that change happened. The hard part is reconstructing the intended authorization posture after the original state has been overwritten or lost. See the Active Directory and Entra ID Hardening Guide.

Practical implication: Map rollback requirements to policy objects and privileged assignments, not only to directory objects.

Why bulk directory events outgrow manual recovery

Directory sync errors, scripting mistakes, and large deletion events create a scale problem that native recovery tools are not built to solve. Restoring objects one at a time is workable for a single mistake and unrealistic when hundreds or thousands of objects are affected. The recovery challenge then shifts from correctness to throughput: the business needs a way to identify the last known-good state and return to it quickly across identities, groups, and configuration. That is why recovery architecture for identity systems has to be designed for point-in-time rollback, not only for incident-by-incident repair. See the Backup Security and Immutable Backup Guide.

Practical implication: Design recovery workflows for mass-change scenarios, not just isolated deletions.

Threat narrative

Attacker objective: The practical objective is to disrupt or alter identity-controlled access so that users, policies, or privileged relationships cannot be restored cleanly with native tooling.

1. Entry occurs through a legitimate administrative or automation change that deletes, corrupts, or misconfigures Entra ID objects or policies.
2. Credential or access impact follows when the original object ID, role assignment, or policy binding is lost and downstream authorization references no longer resolve.
3. Escalation appears when the affected state cannot be reconstructed within native retention limits, forcing manual rebuilds across related objects.
4. Impact is tenant-wide access disruption, prolonged recovery, or compliance exposure when identity state and control state cannot be restored together.

Breaches seen in the wild

• Storm-1283 OAuth apps abuse 2023: Storm-1283 added secrets to new and existing OAuth apps in Entra ID and used them to run Azure cryptomining VMs, costing victims up to $1.5 million.
• Entra ID actor token flaw (CVE-2025-55241): Hidden Actor tokens plus an Azure AD Graph validation flaw could have let attackers become Global Admin in any Entra ID tenant (CVE-2025-55241).

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Identity recovery is now a governance control, not a backup side issue. When Microsoft Entra ID underpins authentication and authorization for the broader SaaS estate, the ability to restore directory state becomes part of access governance itself. The question is not simply whether data can be recovered, but whether policy objects, role bindings, and object relationships can be restored together. Organisations that have not defined ownership for those recovery paths are already operating with an ungoverned control plane.

Native recovery limits create a hidden blast radius in directory administration. A soft-deleted object, a hard-deleted object, and a policy that has been altered are three different recovery problems, but many teams still treat them as one. That assumption breaks because Entra ID access decisions are tied to object identity, not just object existence. The governance gap is hybrid identity recovery that stops at reconstruction instead of state restoration, which leaves downstream entitlements broken even when the object name returns.

Recovery scope must include configuration state, not just directory objects. The article’s most important point is that identity recovery is relational: a recreated object without the original policies, group links, and privileged assignments is not the same operational state. That means recovery design has to account for how access is referenced, not only where the object lives. Practitioners should treat access state as recoverable configuration, or they will continue to discover gaps only after an incident forces restoration.

From our research library:

• 1 in 3 organisations encountered suspicious AI agent activity in 2025, and 99.4% experienced a SaaS or AI ecosystem incident.
• Read next: Identity Recovery Guide

What this signals

Configuration state is the recovery unit of measure for identity systems. In Entra ID, a policy change or deleted object is only half the problem if the tenant cannot reconstitute the access relationships that depended on it. Programme owners should measure recovery success by restored authorisation context, not by object counts alone.

When native recovery ends at a retention boundary, incident response inherits the gap. That pushes identity teams to separate what the platform can reverse natively from what the organisation must retain and test itself, especially for privileged assignments and control-plane changes.

For practitioners

• Define restore ownership for identity state Assign clear responsibility for users, groups, policies, privileged assignments, and related access bindings so that recovery is not left to ad hoc administration. See the Backup and Recovery Policy Template.
• Test point-in-time rollback on directory objects Validate that a restored object returns with the relationships that matter, including app role assignments, policy scope, and privileged eligibility.
• Inventory hard-deleted object classes Map which Entra ID object types cannot be recovered natively so incident response knows where manual rebuilds begin and where backup coverage is required.
• Validate policy and role restoration Include Conditional Access rules, break-glass exclusions, and privileged role changes in recovery tests so restoration covers access control state, not just directory records.

Key takeaways

• Entra ID recovery failures are not limited to deleted objects. Policy changes, role assignments, and broken references can leave access in an inconsistent state even when the directory entry returns.
• The operational risk is amplified by native limits on retention, scope, and object-type coverage. Once those limits are crossed, restoration becomes a manual reconstruction exercise.
• Practitioners should test recovery as a state-restoration problem, with policy objects and access relationships included in every restore scenario.

Related NHI Mgmt Group resources: SaaS Backup Buyer's Guide · Backup Security and Immutable Backup Guide · Active Directory and Entra ID Hardening Guide · Identity Recovery Guide

Key terms

• SaaS Backup: SaaS Backup is the process of copying data and configuration from software-as-a-service platforms into a separate recovery store. It protects against deletion, corruption, ransomware, and vendor or admin error. Defenders should confirm coverage for all critical tenants, test restores, retain data appropriately, and verify that backups are isolated from the primary SaaS account.
• Microsoft Entra ID: Microsoft Entra ID is a cloud identity and access service used to authenticate users, applications, and devices across Microsoft and integrated SaaS environments. It centralises identity policy, sign-in control, and access decisions, so security teams must monitor configuration, roles, and authentication activity closely to reduce takeover and misconfiguration risk.
• Conditional Access: Conditional access is a policy model that decides whether an action should proceed based on context such as posture, resource sensitivity, timing, and scope. For AI agents, it must be evaluated at request time so a valid credential does not automatically equal permitted behaviour.
• ObjectId: ObjectId is MongoDB’s 12-byte identifier format, built from a timestamp, a process-specific random component, and a counter. It is useful for uniqueness, but not designed to be secret or unpredictable enough to serve as an access control boundary for sensitive objects.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.