The roadmap says tenants will be able to enable the extended protection through the Microsoft 365 Backup app in the Microsoft 365 admin center or through Microsoft 365 Backup Storage platform APIs. It also says recovery will restore supported Entra objects to a last known-good state selected from a rolling 30-day history. The feature remains marked In development, however, so December is a target rather than a service-level commitment, and Microsoft has not yet published pricing, licensing changes, or a complete API and object-support matrix for the expanded tier.
Microsoft’s current Entra documentation makes clear why the extra retention matters. The existing service automatically takes one backup snapshot each day, and Microsoft Graph documentation currently describes retention of up to five days. That does not match the roadmap entry’s statement that the existing P1/P2-backed recovery is a seven-day capability. Administrators planning around this should treat five days as the documented operational limit until Microsoft updates the product documentation or clarifies the discrepancy.
Thirty days of backups are different from thirty days of soft delete
The headline figure needs careful reading. Microsoft Entra already offers a 30-day soft-delete period for several objects, including users, Microsoft 365 Groups, cloud security groups, application registrations, and service principals. Soft deletion is primarily an undelete mechanism: it helps when a supported object was deleted and has not been permanently purged.
The planned backup feature is broader in purpose. It is intended to roll supported objects and policies back to their earlier state, which is useful when the object still exists but its configuration has been changed. A malicious actor who alters a Conditional Access policy, modifies an application registration, changes a named location, or damages an authentication-method policy may leave nothing in the recycle bin to restore. A retained backup is the recovery path Microsoft is building for that class of failure.
Microsoft’s published Entra Backup and Recovery documentation currently lists users, groups, applications, service principals, Conditional Access policies, named-location policies, authentication method policy, authorization policy, and organization settings among the supported object categories. The recovery model also supports difference reports, which compare a selected backup against the tenant’s present state before an administrator initiates a rollback.
That preview step is more important than it sounds. Microsoft warns that recovery acts directly on the live tenant and cannot be automatically undone. A report is therefore an operational safeguard, not merely an audit convenience: it gives identity teams a chance to see whether a proposed restore would reverse legitimate changes made after the incident.
The current product has hard boundaries
Microsoft’s own recovery guidance puts limits around what Entra Backup and Recovery can do, and the 30-day roadmap entry does not say that those boundaries will change. The service protects Microsoft Entra directory objects; it does not back up Exchange mailboxes, SharePoint sites, OneDrive data, or Azure resources. Those workloads remain separate backup and recovery problems, even when the incident starts with an Entra identity compromise.
Hybrid tenants face an especially consequential exception. Microsoft says on-premises synchronized objects cannot be recovered through Entra Backup and Recovery because on-premises Active Directory remains the source of authority. Such objects can appear in difference reports, but restoration must happen in Active Directory and then synchronize back to Entra ID. Trying to use cloud-side rollback as the answer to an on-premises directory mistake risks having Entra Connect simply reapply the unwanted change.
Hard deletion is another line the service cannot cross. Microsoft’s documentation says objects that have been permanently deleted cannot be recovered by Backup and Recovery. For an application registration, for example, that can occur after the 30-day soft-delete period expires or when an administrator invokes a hard-delete operation directly. Microsoft recommends Protected Actions to reduce the chance of unauthorized purges, but organizations still need exports and tested reconstruction procedures for critical objects that could fall outside the built-in recovery scope.
The published guidance also notes that application recovery may not restore every property. Application secrets, custom settings, and dependency-specific configuration may require separate handling. For sysadmins, that means a successful Entra restore should not be treated as proof that a line-of-business application will immediately work again. Secret rotation, certificate replacement, API permissions, and downstream service dependencies belong in the recovery runbook.
APIs make this more than an admin-center feature
Roadmap item 567885 specifically calls out Microsoft 365 Backup Storage platform APIs and independent software vendor applications. Microsoft Graph’s backup-and-recovery overview already documents Entra-focused API capabilities for listing backup snapshots, running preview jobs, initiating recovery jobs, and reviewing changes that could not be applied.
That integration path is significant for managed service providers and large tenants that do not run recovery through an ad hoc portal workflow. It opens the door to ticket-driven restore approval, automated evidence capture, change-management records, and incident response tooling that can request a difference report before a privileged operator executes a recovery. But the roadmap says advanced recovery will initially remain limited to the Entra admin portal, while the Microsoft 365 Backup app is expected to expose only some user-recovery actions.
In practice, administrators should not assume December’s release will make every recovery operation scriptable or available from the Microsoft 365 admin center. Microsoft’s wording separates enabling the service from performing advanced restoration. The Entra portal will remain the place to handle the consequential work, at least initially.
The one-backup-per-day cadence is another constraint. A 30-day window would mean roughly 30 recovery points, not continuous rollback. An administrator responding to a policy change at 4 p.m. may need to select the prior day’s snapshot, potentially reversing valid work performed between the backup and the incident. Difference reports and narrowly scoped restores will be central to limiting that collateral reversal.
Licensing, access, and readiness work now
Microsoft’s current documentation requires Microsoft Entra ID P1 or P2 licensing for Backup and Recovery, along with the Microsoft Entra Backup Administrator role to conduct recovery. The roadmap says the extended capability can be enabled through the Microsoft 365 Backup app or APIs, but it does not state whether the 30-day window will be included in existing licensing, billed through Microsoft 365 Backup storage, or require a separate entitlement.
That omission is material. Microsoft 365 Backup for Exchange, OneDrive, and SharePoint has its own storage-based commercial model and much more frequent recovery points, while the Entra service currently sits behind Entra licensing and daily snapshots. The roadmap groups the new capability with the Microsoft 365 Backup app and platform APIs, but does not establish how Microsoft will price identity backup retention. Organizations should avoid treating the December date as a purchasing answer.
There are still useful steps teams can take before the release:
- Document which Conditional Access policies, application registrations, service principals, break-glass accounts, and authentication policies would need urgent restoration after an administrative or security incident.
- Assign and test the Microsoft Entra Backup Administrator role without relying on the same privileged account that could be affected by a tenant-wide policy failure.
- Export critical policy and application configuration to an external, access-controlled repository, particularly for unsupported properties and hard-deletion scenarios.
- Test recovery in a nonproduction tenant and verify downstream applications after any restore, rather than measuring success solely by whether the Entra object reappears.
- Keep Entra audit and sign-in logs in a longer-lived external destination, because a recovery point can show what state to return to without establishing who made the damaging change.
Microsoft’s own recoverability guidance recommends externally retaining configurations beyond the built-in windows, and warns against circular dependencies in which the repository holding recovery scripts is protected by the same Entra tenant being repaired. That is a practical concern for organizations that keep their policy exports in Azure DevOps, GitHub Enterprise, or another service gated by Conditional Access in the affected directory.
A useful expansion, not a tenant disaster-recovery substitute
A rolling 30-day Entra restore history would give administrators far more room to detect and remediate identity damage than the service’s currently documented five daily snapshots. It should be especially valuable for accidental policy changes and slower-moving incidents that escape immediate detection. But it remains a rollback mechanism for a defined set of Entra objects and attributes, not a full backup of Microsoft 365, Azure, hybrid Active Directory, or every application dependency connected to the tenant.
The immediate planning point is simple: organizations should compare their current recovery objectives against the documented five-day snapshot history, not against the roadmap’s future 30-day promise. If Microsoft ships Roadmap ID 567885 on schedule in December 2026, the new window will improve the recovery margin; it will not remove the need for external configuration records, protected deletion controls, long-term logs, and a tested path for the objects Microsoft cannot restore.