Enforcing Strong MFA Through Protected Actions Might Block Bad Actors

A January 25, 2025 blog about how attackers leverage the User.DeleteRestore.All Graph permission attracted my attention. The idea advanced is that if attackers can wreak havoc if they can secure the User.DeleteRestore.All permission. There’s no doubt that this assertion is correct. Attackers being able to permanently remove soft-deleted user accounts from the Entra ID recycle bin is enough to give any tenant administrator a severe headache.

Protected actions might offer some protection against attacker destruction. When I first covered this capability in May 2023, it was early days for the feature. Essentially, a protected action is associated with a conditional access policy through an authentication context so that any attempt to perform the protected access invokes the conditions set in the policy. For instance, the condition could be that the user must authenticate themselves with a strong phishing-resistant authentication method like a FIDO2 key or passkey.

The idea here is that the attacker might not be able to satisfy the authentication challenge with the required strong method and is therefore blocked from performing the protected action. That theory falls down if the attacker has gained sufficient control over the tenant to update conditional access policies (unless you block update access to conditional access policies with a protected action).

Creating a CA Policy for Protected Actions

Microsoft’s documentation for adding a protected action is straightforward. To add a protected action to guard against unexpected removal of soft-deleted user accounts, create a conditional access policy for Entra ID to invoke when a connection attempts to us an authentication context (basically, when something happens – like accessing a sensitive SharePoint Online site). The CA policy (Figure 1) is very simple and associates an authentication context with strong authentication. You could add other policy requirements to grant access to make it harder for attackers. For instance, require the use of a compliant device.

The magic comes when you link the authentication context with one or more permissions. The set of supported permissions for protected actions has grown over time and includes microsoft.directory/deletedItems/delete, the permission to permanently delete objects from Entra ID. Deleted user accounts normally remain in a soft-deleted state in the Entra ID recycle bin for 30 days following deletion. Soft-deleted means that the accounts are recoverable. However, if the account is removed from the recycle bin, it is hard-deleted and irrecoverable.

To link the authentication context, go to the Roles & admins section under Identity in the Entra admin center and select Protected actions. Find the authentication context to link, select the permission, and save (Figure 2).

You can’t link a protected action to multiple authentication contexts. If you make a mistake and link the protected action to the wrong authentication context, you must remove the protected action and add it to the correct authentication context.

Testing the Protected Action

To test the effectiveness of the protected action, you need an account that holds an administrative role that would normally allow the holder to permanently remove soft-deleted user accounts that doesn’t meet the requirements of the CA policy. I used an account holding the Global administrator role that used SMS to satisfy an MFA challenge. Entra ID doesn’t consider SMS to be an authentication strength that meets the criteria of passwordless MFA, so any attempt by this global administrator to remove a soft-deleted account fails (Figure 3).

The block also works if an attempt is made to remove an account using the Graph Permanently delete an item API or the Remove-MgDirectoryDeletedItem cmdlet from the Microsoft Graph PowerShell SDK.

Get-MgDirectoryDeletedItemAsUser | Format-Table Id, displayname

Id                                   DisplayName
--                                   -----------
63699f2f-a46a-4e99-a068-47a773f9af11 Annie Colonna
f13e62ff-b43c-44e7-a821-48db196b84d9 Cathy Lin
889bad5f-d7f7-4731-bf07-af2894f345b2 Joanne Crispa

Remove-MgDirectoryDeletedItem -DirectoryObjectId f13e62ff-b43c-44e7-a821-48db196b84d9

Remove-MgDirectoryDeletedItem_Delete: Operation requires conditional access and client does not support it. Client must be configured to support conditional access claims challenges to proceed.

Insisting on Stringent Conditions is Sometimes Good

Any organization that has deployed conditional access policies should consider using protected actions. The necessary policies are easy to implement, and it makes sense to insist on stringent conditions before destructive actions like permanent removal of user accounts are possible.

The only issue I encountered during testing was that Entra ID didn’t respect the disabling of the CA policy used for protected actions. No matter what, the policy remained in force until I removed the protected action. It’s possible that the underlying cause was a timing issue generated by multiple changes to settings over a short period and that everything would have worked more smoothly if I was more patient. In any case, the issue shouldn’t be a problem in practical terms because it’s highly unlikely that anyone will disable and enable a CA policy to turn protected actions off and on several times in quick succession, but it’s definitely something that the developers should investigate.

Insight like this doesn’t come easily. You’ve got to know the technology and understand how to look behind the scenes. Benefit from the knowledge and experience of the Office 365 for IT Pros team by subscribing to the best eBook covering Office 365 and the wider Microsoft 365 ecosystem.