Table of Contents
Stop Permanent Removal of Directory Objects for Seven Days
I do wish the Entra development group would be more communicative when it has some good news to share. Not a word was said when documentation appeared on November 5 about Hard Deletion Protection, a new feature for the Entra backup system to prevent the inadvertent (or deliberate) hard deletion of a directory object within seven days of its soft deletion.
Soft deletion is what happens when an administrator removes a directory object from Entra ID via the admin center or a Graph API. Soft-deleted items remain in the recycle bin and can be recovered before Entra ID permanently removes them after 30 days. Items can be removed from the recycle bin and hard-deleted beforehand. Hard deletion is permanent and irrecoverable, and that’s what the new protection aims to control.
How Hard Deletion Protection Works
Hard Deletion Protection is implemented by setting the isHardDeleteProtectionEnabled property of a supported object to True. Protection is permanent once enabled and cannot be reversed, meaning that you shouldn’t enable hard deletion protection unless a good reason exists. The property can only be set for active objects. If a protected object is subsequently soft-deleted, a seven-day protection period starts, during which any attempt to hard-delete the object fails.
The Entra admin center greys out the Delete permanently option when viewing Deleted users (Figure 1). You can also see that the admin center highlights the setting in the Permanent deletion protection status column.
After the seven-day protection period expires, the object can be hard-deleted as normal. Objects restored after soft deletion retain Hard Deletion Protection. If an object is soft-deleted again after restoration, a new seven-day protection period starts.
Supported Objects for Hard Deletion Protection
According to the documentation, the currently supported objects are:
- Cloud-only user accounts (including guest accounts). Accounts synchronized from on-premises deployments are unsupported presumably because Active Directory controls their lifecycle rather than Entra ID.
- Cloud-only groups (Microsoft 365 groups or security groups, not mail-enabled security groups or distribution groups).
- Applications. This category is for tenant-owned app registrations.
- Service Principals. Protection can be applied to the service principals for enterprise apps like the Microsoft Graph PowerShell Command Line tools. Surprisingly, the service principals created for Azure Automation accounts cannot be protected. These seem like exactly the kind of high-value objects that warrant protection.
The intention is to protect critical directory objects from permanent removal. For example, protection can stop a disaffected privileged employee from permanently removing a bunch of user accounts on their way out the door. It can also frustrate an attacker who attempts to remove all administrator accounts except one under their control.
Applying Hard Deletion Protection to Directory Objects
Objects can be protected through the Backup section of the Entra admin center (Figure 2) or by updating the isHardDeleteProtectionEnabled property programmatically.
Selecting a bunch of objects through any administrative portal can be boring. It’s faster to set protection on more than a few objects by updating their properties through the Graph.
The current Microsoft Graph PowerShell SDK (V2.41.2) metadata doesn’t fully expose Hard Deletion Protection, so the examples use a mixture of beta SDK cmdlets and direct Graph requests. This example shows how to set the property with the Update-MgBetaUser cmdlet from the Microsoft Graph PowerShell SDK.
$Params = @{
isHardDeleteProtectionEnabled = $true
}
Update-MgBetaUser -UserId Lotte.Vetler@office365itpros.com -BodyParameter $Params
A very simple loop through all licensed user accounts will update protection for each account. This code doesn’t check whether the signed-in account has permission to update members of restricted management administrative units, so expect errors for objects that it cannot manage:
[array]$Users = Get-MgUser -Filter "assignedLicenses/`$count ne 0 and userType eq 'Member' and accountEnabled ne false" -ConsistencyLevel eventual -CountVariable UsersFound
ForEach ($User in $Users) {
Update-MgBetaUser -UserId $User.Id -BodyParameter $Params
}
The equivalent code to protect all the teams in the tenant is:
[array]$Teams = Get-MgTeam -All
ForEach ($Team in $Teams) {
Update-MgBetaGroup -GroupId $Team.Id -BodyParameter $Params
}
To check that protection is in place, fetch the properties of an object and examine its isHardDeleteProtectionEnabled property. The Get-MgBetaUser cmdlet doesn’t yet return the property, so I use a Graph API request here:
$Uri = "https://graph.microsoft.com/beta/users/Lotte.Vetler@office365itpros.com" $Data = Invoke-MgGraphRequest -Uri $Uri -Method GET -OutputType PsObject $data.isHardDeleteProtectionEnabled True
To list protected objects of a particular type, filter on the isHardDeleteProtectionEnabled property. Here’s how to find protected member accounts. Remember that Invoke-MgGraphRequest doesn’t automatically follow @odata.nextLink values, so the code must handle pagination to retrieve more than the first page of results.
$Uri = "https://graph.microsoft.com/beta/users?`$filter=isHardDeleteProtectionEnabled eq true and accountEnabled eq true and userType eq 'Member'" $Data = Invoke-MgGraphRequest -Uri $Uri -Method GET -OutputType PsObject | Select-Object -ExpandProperty Value $Data | Format-Table DisplayName, userPrincipalName
Attempts to use Graph requests to remove protected objects are blocked. For example, here’s what happened when I tried to use the Remove-MgDirectoryDeletedItem cmdlet to hard-delete a soft-deleted user account. The error text tells us that the seven-day protection period expires on 13 November 2026 at 12:31 UTC.
Remove-MgDirectoryDeletedItem -DirectoryObjectId 61d3798f-4bfd-418e-8845-d3c889bdb594 Remove-MgDirectoryDeletedItem_Delete: Hard deletion of object '61d3798f-4bfd-418e-8845-d3c889bdb594' is blocked because hard deletion protection is enabled and the lockdown window has not elapsed (window ends at 2026-11-13T12:31:20.0000000Z). Status: 403 (Forbidden)
Solid Feature with Poor Auditing
Hard Deletion Protection is a solid feature with obvious value. It’s a pity that the audit events generated when protection is enabled (and mentioned in the documentation) are so poor. Knowing that a directory object was updated delivers some basic information, but the audit event doesn’t make it easy to understand exactly what changed.
The nice thing about generative AI tools is that they can generate information based on what’s gone before. The bad thing about generative AI tools is that they can’t create new thinking or insights about how technology works (or doesn’t). When we write the Microsoft 365 for IT Pros eBooks, we depend on hundreds of years of real-world experience, knowledge, and intuition to analyze and explain how Microsoft 365 really works. If you understand the basic principles about Entra ID, Exchange Online, SharePoint Online, Teams, the Microsoft Graph, and more, you’ll be able to figure out the value of new features as Microsoft adds them to the platform. All for less than ten cups of black coffee.