That distinction makes this more useful, and less alarming, than the headline might suggest. Microsoft is not creating indestructible accounts. It is placing a mandatory waiting period between a recoverable deletion and an irreversible one. For identity administrators, the benefit is breathing room. The corresponding obligation is to choose protected objects carefully.
What has changed—and what “permanent” means
Microsoft’s configuration documentation, updated November 5, 2026, identifies Hard Deletion Protection as a preview feature within Microsoft Entra Backup and Recovery. That documentation date establishes when the guidance was updated, not an exact service launch date. The inspected documentation does not provide a general-availability timetable.
The feature separates two decisions that can otherwise follow each other quickly: deleting an object and permanently removing the possibility of recovering it.
Once protection is enabled:
- The object can still be soft-deleted.
- Permanent deletion is blocked during the first seven days following that soft deletion.
- After seven days, an authorized administrator can permanently delete it.
- Restoring the object does not remove its protection.
- If the restored object is soft-deleted again, another seven-day protection window starts.
The setting is permanent; each deletion-blocking window is temporary. Restoring an object is therefore not a loophole for clearing the setting. Nor does an object become unprotected merely because seven days have passed since protection was originally enabled: the clock starts with soft deletion.
This is a recovery safeguard, not an availability guarantee. Because soft deletion remains possible, organizations still need to detect and respond to unwanted changes rather than assuming the protected identity cannot be disrupted.
Three clocks administrators should not confuse
Entra’s recovery documentation describes three different time periods, each serving a separate purpose.
| Mechanism | Documented period | What it provides |
|---|---|---|
| Hard Deletion Protection | Seven days after soft deletion | Blocks permanent deletion of a protected object |
| Soft-delete retention | 30 days for the listed supported object types | Allows recovery while the object remains soft-deleted |
| Backup history | Up to seven days, with daily backups | Provides earlier states of supported properties and links |
Microsoft documents these periods separately. The new protection does not turn 30-day soft-delete retention into seven-day retention, and backup history is not the same thing as the deletion-blocking timer.
Consider a hypothetical protected application that is soft-deleted on a Monday afternoon. The protection window runs from that deletion time. During the next seven days, permanent deletion is blocked. Afterward, permanent deletion becomes possible; it is not described as automatically happening when the protection window expires. If the application is restored and later soft-deleted again, the timer starts afresh. This example follows Microsoft’s documented behavior.
The practical takeaway is simple: seven days is the enforced intervention window, not permission to postpone incident response for a week.
Which objects qualify?
The preview supports more than user accounts. Microsoft lists:
- Users, excluding users synchronized from on-premises Active Directory.
- Cloud-only groups.
- Applications.
- Service principals.
Microsoft Entra Agent ID objects are supported through their underlying user, application, and service-principal object types. There is no separate blanket promise covering every conceivable agent-related resource.
That broader coverage matters when planning protection. An organization should evaluate important application identities alongside human accounts, rather than treating this exclusively as a safeguard for employee deletion.
However, administrators must not confuse the protection list with the broader Backup and Recovery inventory. That service also handles supported properties of objects such as Conditional Access policies and named locations; their presence in the backup documentation does not establish that they qualify for this particular deletion protection.
Hybrid environments need special attention. Microsoft says changes to synchronized objects can appear in difference reports, but recovery of on-premises-managed objects must occur in on-premises Active Directory. Visibility in an Entra report is not evidence that the cloud service can recover the object.
Roles, tenant eligibility, and licensing
Microsoft’s feature-specific prerequisites require an active Entra account with the Microsoft Entra Backup Administrator role. The configuration page also says no additional license is required for the currently supported object types.
There is an important service-level qualification. The broader Backup and Recovery overview requires a workforce tenant with Microsoft Entra ID P1 or P2 licenses. External ID and Azure AD B2C tenants are not supported by that service. “No additional license” should therefore not be expanded into a claim that the entire backup-and-recovery capability is available to every tenant without prerequisites.
The overview also distinguishes administrative roles:
- Backup Reader can inspect backups, comparisons, and recovery history.
- Backup Administrator can additionally initiate difference reports and recovery.
- Global Administrator includes the Backup Administrator permissions.
For rollout planning, verify the tenant and role requirements before preparing a protection list. This is an Entra administrative configuration, not a Windows client patch: Microsoft’s setup instructions use the Entra admin center rather than a Windows build requirement or KB installation.
How to enable Hard Deletion Protection
The portal procedure is short. The decision behind it deserves more attention than the number of clicks.
Before starting, identify the intended objects and confirm that their owners understand the permanent setting. That is an operational recommendation based on the feature’s irreversibility, not an additional Microsoft prerequisite.
Microsoft documents these steps:
- Sign in to the Microsoft Entra admin center as at least a Microsoft Entra Backup Administrator.
- Navigate to Backup and recovery > Hard deletion protection.
- Select Add protection.
- Choose one supported object type.
- Search for and select up to 20 objects of that type.
- Read the permanent-protection warning, then select Save.
- Check the protected-object counts. Select the corresponding object-type link to inspect the protected objects.
The 20-object restriction applies to each operation and its selected object type. Microsoft does not describe it as a tenant-wide maximum of 20 protected objects. Objects already protected are unavailable for selection again.
Success should be verified through the protected-object listing, not merely assumed after clicking Save. Microsoft also records protection enablement in Entra audit logs, providing a separate record of the configuration action.
As a practical safeguard, compare the resulting list against the approved object inventory. A permanent setting is a poor place to discover that two similarly named applications were confused.
What to check when something appears wrong
Several behaviors that might look like faults are documented parts of the design.
An object is missing from the selection list. Check whether it already has protection, whether the selected object type is correct, and whether it falls outside the supported scope. Already protected objects cannot be selected again, and on-premises-synchronized users are excluded.
A bulk permanent-deletion action is blocked. Microsoft says the action is blocked when the selected set includes a protected object. Administrators should inspect the selection and protection state before treating this as a general permissions problem.
A restored object remains protected. That is expected. Restoration recovers the object; it does not reverse the protection choice.
Protection was enabled accidentally. Microsoft’s stated route to permanently deleting that object is to soft-delete it and wait seven days. This is not a way to disable protection while retaining the same active object. For an object the organization still needs, accidental enablement calls for an operational review—not reflexive deletion.
These checks help separate an intentional safety barrier from a broken workflow. Repeatedly attempting the same deletion will not make the waiting period disappear.
Graph automation has the same one-way switch
Microsoft’s Graph beta service-principal update documentation exposes the Boolean property isHardDeleteProtectionEnabled. Setting it to true enables protection on an existing service principal; afterward, it cannot be changed to false or null. Microsoft also says it cannot be enabled during service-principal creation: creation must be followed by a separate update.
The documented operation requires HardDeletionSetting.ReadWrite.Enable, with the caller also holding the Microsoft Entra Backup Administrator role. Standard application-management roles alone do not authorize enablement.
This is beta documentation, not a stable v1.0 integration promise. Microsoft warns that beta APIs can change and are unsupported for production applications. Administrators evaluating automation should preserve that distinction.
There is also a useful diagnostic detail in Microsoft’s beta permanent-deletion documentation: its example of attempting to purge a protected object during the waiting period returns HTTP 409 Conflict, with error code Request_ConflictingRequest. That documents enforcement beyond the portal interface.
For automation designers, the implication is to recognize a protection conflict separately from a transient failure. A retry loop is not a recovery plan.
Why backups alone do not close this gap
Microsoft’s Backup and Recovery service automatically takes daily backups of supported objects and retains up to seven days of history. Microsoft says even highly privileged signed-in users and applications cannot disable, delete, or modify those backups. Nevertheless, the service cannot recover or recreate hard-deleted objects.
That last limitation explains why deletion protection matters. Backup integrity and object recoverability are related, but they are not interchangeable. Preserving a backup does not remove the documented barrier to recovering a permanently deleted directory object.
Hard Deletion Protection addresses the earlier stage: it keeps permanent deletion unavailable while responders investigate and choose a recovery action. It does not perform restoration itself.
The wider service also has a defined boundary. It backs up Entra directory objects, not Microsoft 365 mailboxes, OneDrive content, SharePoint sites, or Azure resources. Protecting an identity should not be advertised internally as comprehensive protection of everything that identity can access.
This is an additional identity-recovery control, not a replacement for workload-specific recovery planning.
Turn the waiting period into a response plan
The most useful rollout pairs protection selection with a documented response process. Based on Microsoft’s stated behavior, administrators should establish:
- Who reviews unexpected deletion events.
- Who can authorize restoration.
- Which protected identities support important services.
- How legitimate decommissioning accommodates the seven-day delay.
- How protection enablement is recorded in change-management records.
These are operational recommendations, not new product requirements. Their purpose is to make the time Microsoft preserves usable.
Where Backup and Recovery is used, Microsoft recommends reviewing a difference report before deciding what to recover. Its recovery model can restore soft-deleted objects or revert supported properties, but it can also soft-delete objects added after the selected backup. A broad recovery operation therefore deserves more scrutiny than simply pressing “undo.”
Recovery scheduling matters too. Microsoft allows only one difference-report or recovery job at a time. A report already running can prevent a recovery job from starting until it finishes. That is another reason to prepare the process before an incident, rather than assuming every recovery operation begins immediately.
The bottom line
Hard Deletion Protection makes a consequential administrative action deliberately slower. Its value is not that administrators lose all control; it is that neither an authorized mistake nor an unwanted deletion can immediately progress to permanent removal of a protected object. The protection setting survives restoration, while the enforced delay remains seven days per soft-deletion event.
For Entra teams, the sensible next step is a carefully reviewed protection inventory, followed by verified configuration and a workable recovery procedure. The irreversible setting deserves caution, but the objective is straightforward: preserve an opportunity to recover before a deletion becomes final.