In this blogpost we're going to talk about Microsoft Entra Protected Actions. What are Microsoft Entra Protected Actions, what are the requirements, which tasks can I protect and how do I configure and combine this with other security tools?

1. What Are Entra Protected Actions?

With Entra Protected Actions you are able to protect certain changes or deletions for your environment before being executed by performing for example, Phishing-resistant MFA before deletion. These protected actions are permissions that have been assigned to Conditional Access policies. I recommend configuring this for privileged accounts.

2. What Are The Requirements?

The following requirements are needed to be able to use and configure Entra Protected Actions:

License:

• Microsoft Entra ID P1 or P2.

Admin role:

• CA Administrator;

• Security Administrator.

3. Where Can I Use It For?

You can use Protected Actions for a variety of areas:

CA policy management:

• Create, Delete CA policies;

• Update basic properties.

Cross tenant access settings:

• Update allowed cloud endpoints of the cross-tenant access policy;

• Update Microsoft Entra B2B collaboration settings of the default cross-tenant access policy (also for partners);

• Update Microsoft Entra B2B direct connect settings of the default cross-tenant access policy;

• Update cross-cloud Teams meeting settings of the default cross-tenant access policy (also for partners);

• Update tenant restrictions of the default cross-tenant access policy (also for partners);

• Create cross-tenant access policy for partners;

• Delete cross-tenant access policy for partners.

Hard deletion (some objects):

• Permanently delete objects, which can no longer be restored.

Network locations:

• Create and delete custom rules.

Protected action management:

• Update Conditional Access authentication context of Microsoft 365 role-based access control (RBAC) resource actions.

4. Great! Now, How Can I Use It?

Now the fun part starts! Remember my latest blog regarding Entra backup and soft deletes? Let's say we want to create a protection for deleting objects in our environment. First we want to create an authentication context for the specific subject that we want to create a extra layer of security for. In our case permanently deleting objects. 

Follow these steps to first create the authentication context:

• Go to the Entra admin center (entra.microsoft.com);

• Navigate to Entra ID -> Conditional Access -> select "Authentication Contexts";

• Select "New authentication context"

In this blog we are going to add an extra MFA authentication layer when we want to permanently delete an object. I reccomend creating several auth contexts depending on your deletion/config change type. For example creating one for deleting objects and another one for changing or deleting CA policies. Configuring this way allows you to quickly perform troubleshooting for each subject.

Name the policy and select "Save":

Now that we created our auth context, we are going create a CA policy. Select "Policies", following "New policy":

CA Policy settings:

• Name: Name the policy

• Users or agents: All Users with some exclusions (breakglass);

• Target resources: Authenticaton Context -> select our just created auth context;

Access controls: Grant -> Grant access -> Require authentication strenght -> Phising-resistant MFA;

Note*: I recommend putting more guardrails in place (device health, Entra joined device, location, user/sign in risk) when performing an highly admin task. In this blog I will only deep dive this using Phishing-resistant MFA.

Now that we have created our CA policy, we need to create a protected action to ensure that when we hard delete an object, MFA kicks in. To do this:

Go to Entra ID -> Roles and administrators -> select: "Protected actions"

From the protected actions menu, select "Add protected actions":

In the add protected actions menu, select the following:

• CA authentication context: select our just created CA policy
• Permissions: Select permissions -> search for microsoft.directory/deletedItems/delete
• Save

5. Time To Test!

Now that we successfully created our protected action, we can put it to the test. I will show both examples (working and not working):

When I go to deleted users in Entra ID, I will see all of my user that have been soft deleted. When I use an admin account that only has number matching MFA, I will get the following error when I try to hard delete this account:

This error means that I don't have enough access "rights" to delete this user. This is because we configured that hard deleting an object needs to have Phishing-resistant MFA.

Now when I try to delete this same user while having a session token that has been initiated using Phising-resistant MFA, I will get a succeed message: 

Note*: If you configured protected actions for editing or removing CA policies as well, you will get the following message if your access token is still with number matching MFA only instead of Phising-resistant MFA:

6. Wrap Up

Time to wrap things up. Protected actions is a great addon to your zero thrust configuration. With protected actions in place, you are able to leverage a higher level of security throughout your environment and to be sure that high risk changes can be only performed when the correct identity and access has been granted to that specific admin account.

A couple of key take aways reagarding protected actions that I recommend:

• Create a auth context and CA policy per protected action subject;

• When configuring, only use Phishing-resistant MFA like FIDO2 or Passkey;

• In this blog I only configured allowing these tasks when using Phishing-resistant MFA as a pre requirement, but I strongly recommend putting more security guard rails before allowing these actions. For example a trusted/healthy device, user/sign risk, location, Entra joined device;

• Start with your CA change/delete and permanently deleting objects first.