Defense in depth is a concept in cybersecurity that implements a multi-layered security measure strategy to protect data and digital assets. Should a cybercriminal bypass one security control, he would still have to face multiple other security controls in order to achieve the goal. Defense in depth will increase the cost of breach for the criminal. It also gives Defenders much needed time to react and response. To a certain extent we could say that the more security controls an organization has, the more difficult the breach for the attacker and the more likely they are to trigger alerts that will expose their presence. Microsoft Entra ID Protected Actions is one such control that can be added to protect the most critical actions in Entra ID. Let’s start!

Setting the goal

In this blog we will look at what the Microsoft Entra ID Protected Actions is and how to implement it. We will ponder why it should be used and list some use cases when it is recommended to implement it. At last, we’ll list tools that you’ll use to manage protected actions and talk what there is to manage.

Protected Actions explained

I want to start by defining how conditional access works, as the two concepts are similar, but still different and will actually work together to provide added security. In general, conditional access works by defining the application, authentication context or pre-defined user action that we want to protect. Then we target the policy to users, groups, guest users or directory roles. We could add some conditions if we wanted to and then choose either to block or to grant access with certain controls that still need to be met. Currently, March 2024, the two ‘User actions’ that we have available are:

• Register security information (aka.ms/mysecurityinfo)
• Register or join devices

In contrast, protected actions are a set of pre-defined user actions, permissions actually, that can be further protected with the aid of two other features: Conditional Access and Authentication Context. Protected actions are just permissions like this one: microsoft.directory/conditionalAccessPolicies/delete. But unlike normal behavior where a user that has a role that includes this permission and can execute upon it, protected actions will protect the permission with a conditional access. What is required by the conditional access policy depends. But conditional access is only evaluated during the initial sign-in, you say. Yes they are, and to trigger the conditional access after the initial sign-in, we need authentication context. Notice that protected actions does not care how you’ve gained your permissions. If the permission matches to action that is protected then the conditional access will be evaluated!

Implementing protected actions

In high-level, the order of operations to implement protected actions is somewhat like this:

1. Create at least one authentication context for protected actions. You can create several, depending on your use cases.
2. Create conditional access policy that has ‘Target resources’ set to ‘Authentication context’ and choose your newly created authentication context.
3. Add actions that you want to protect, or choose all, and bind them to the newly created authentication context.
4. Add other conditions if you like and configure grant controls. Later in the blog, you can get inspired by some of the example use cases.

You’ll need Conditional Access Administrator or Security Administrator role to implement previous steps.

Licensing requirements

Using Microsoft Entra ID Protected Actions requires Microsoft Entra ID P1 licenses.

Permissions included by Protected Actions

What type or permissions are we able to protect then?

Four main areas can be mentioned:

• Conditional Access policy management
• Cross-tenant access settings management
• Custom rules that define network locations
• Protected action management

Here is a link to the table that outlines all the distinct permissions.

Why should you implement protected actions?

I see protected actions as one more layer in the “onion” that we build to protect our organizational assets. If your security strategy is Zero-Trust model and you implement defense-in-depth, then all the security measures you can implement will serve you (again, to an extent). Protected actions is one more security layer, and should be implemented when there’s more benefits than disadvantages. The cost on user efficiency with protected actions implemented still remains low as the policy enforcement only occurs when the user attempts to execute the action that is being protected. In this regard, I’d say there’s really low user experience friction compared to conditional access which is evaluated during each sign-in process.

So when is protected actions a good measure to implement? Simply put, when you already have purchased Microsoft Entra ID P1 licenses and you have Conditional Access in use, especially with named network locations or you have B2B collaboration with external organizations and want to protect these settings. Who would not want to protect those settings? Maybe for you the decision comes down to production vs. test/dev environment. Enable in prod, but leave out from test. Or you’re already requiring very strict conditional access conditions and grant controls and you’ve also implemented Entra ID PIM for just-in-time (JIT) access or just-enough-administration (JEA), so Protected Actions would not bring that much more security but would only bring more complexity. I still do recommend implementing protected actions as it does not require much to implement and is mostly invisible to most of the users. The enforcement of the policy makes the difference here. If it would be enforced during every sign-in or similar frequency then it would be very visible and “loud”. Now it only enforces the policy when user is performing the action, and that should not be daily, most likely not even weekly in well established tenants.

Example use cases for protected actions

The actions themselves are defined by Microsoft and we already know what these are. The scope of these at the time of writing is fairly narrow, but we don’t want to have every action being protected, because it would cause step-up authentication fatigue, so we’re good with what they are now. But what do we want to accomplish with the Conditional Access policy that is being triggered by the action? Usually we want to require something that we might not require all the time. Here are some examples:

• You’ve implemented a Privileged Access Workstation (PAW) for you most sensitive and highly privileged operations. You configure that the device must meet the requirements of the device filter

• You’ve implemented Named Network Locations. You want to require that the highly privileged operations only happen from within the trusted network location.

• You’ve enabled phishing-resistant authentication methods (like FIDO2 security keys) for a group of highly privileged users. You want to require that user will do a step-up authentication using phishing-resistant method. You configure the CA policy to grant access and require your custom authentication strength (“Passkeys/Security keys only”).

• You’ve implemented Microsoft Entra Identity Protection. You want to require that the user risk level cannot exceed “Low”. You configure User Risk condition as “Low” and Access Control as “Grant”.

All these are pinpoint examples and in the real world, you would most likely be mixing and matching some of these and making up your own requirements also.

Managing protected actions

One of the actions being protected is actually managing protected actions. So if you enable protected actions and include the management action for protected actions, then understand that also managing them will require you to satisfy the conditional access requirements. Nevertheless, there isn’t much to manage even on a monthly-basis. Basically only if Microsoft adds or updates the actions. You should already have some method or process to manage conditional access policies either through configuration code, Microsoft Graph PowerShell or portal experience. From administrator perspective Authentication contexts are low effort to maintain using the portal experience too. Today, your best admin tool to manage protected actions (that is the bind between these privileged permissions and the authentication context) is Entra Admin portal. You can do it with Graph API calls, but to be honest, unless you’re playing with Graph API calls daily or weekly, you’re most likely better of with portal experience.

Summary

In this blog, we went through how Entra ID Protected Actions co-exists and depends on Conditional Access policies and Authentication Contexts. We looked at the key differences between just conditional access and protected actions and when they enforce their policies and with what frequency. We also outlined some good scenarios when it makes sense to implement protected actions, provided some use cases and then set our eyes on the tooling of lack there of.

Protected Actions is a lightweight Entra ID P1 feature that integrates nicely into your existing Conditional Access policies and processes. It does not require much attention and upkeep, some of course. I recommend trying it out!

Stay secure!