I've seen it happen more than once. An admin switches off a Conditional Access policy by accident, or someone edits a named location without thinking through what it affects, and suddenly the tenant is wide open. With several admins and responsibilities that keep shifting, that's just waiting to go wrong. Protected actions in Microsoft Entra ID address this directly. They add an extra Conditional Access check to certain high-impact changes, such as creating, modifying or deleting Conditional Access policies or named locations. You can require admins who perform these actions to satisfy a specific authentication context, for example phishing-resistant MFA or a compliant device.

Protected actions put a second check on sensitive operations

Protected actions give you extra assurance around sensitive operations in Entra ID. You don't have to trust that admins always come in with the right protection. You can force an explicit step-up to an authentication context for a small but important set of actions. That set covers creating, editing and deleting Conditional Access policies, named locations and trust framework policies (see the Microsoft documentation). In practice, a compromised admin account can't do serious damage without passing that additional check. I still regularly come across tenants with no guardrails like this, which leaves attackers a lot to work with.

The behaviour is similar to just-in-time access. Whenever an admin attempts a protected operation, Entra checks whether the extra requirement has been met. If it hasn't, the admin gets prompted, even if they're already signed in to the portal.

The setup needs an authentication context and a matching policy

Before you can use protected actions, you need an authentication context in Entra ID. If you haven't worked with this yet, my guide on migrating the authentication methods policy is a good starting point. Then create a Conditional Access policy that targets this context and requires, say, FIDO2 keys, certificate-based auth or a compliant device for these sensitive actions. One thing matters here: the policy targets the authentication context, not users or groups directly.

This tip has saved me a lot of trouble:

Pro tip: When testing, create a dedicated CA policy for the authentication context and run it in report-only mode first. This lets you see the impact without locking yourself out.

With the authentication context and the policy in place, go to the Microsoft Entra admin center → Roles & admins → Protected actions → Add and assign the action you need (e.g., “Create or edit Conditional Access policy”) to your authentication context. Microsoft's guide to adding protected actions walks through it.

The diagram below shows the flow, and it matches what I see in customer tenants:

flowchart TD
    Start["Admin signs in to Entra portal"] --> Action["Tries to edit CA policy"]
    Action --> Check["Is this a protected action?"]
    Check -- "No" --> Allow["Action allowed"]
    Check -- "Yes" --> StepUp["Trigger CA policy for auth context"]
    StepUp --> Success["Requirement met?"]
    Success -- "No" --> Deny["Action denied"]
    Success -- "Yes" --> Allow

Figure: How a protected action triggers the authentication context step-up

Protected actions close real gaps in production tenants

In many of the tenants I work in, protected actions close gaps nobody would otherwise notice. This matters even more in hybrid teams or organizations with a lot of delegated admin access, because accidental or malicious changes to access control become much less likely. Once every change to Conditional Access policies depends on strong authentication or a compliant device, a compromised admin account can't simply rewrite the tenant's security. Named locations, which attackers like to abuse as a backdoor, get the same protection.

Licensing is barely an obstacle, since the affected admins only need Entra ID P1. What does need attention is the design of the Conditional Access policy behind the authentication context. Don't allow weak MFA and don't add legacy app exclusions. The CA documentation has more on building secure policies.

Protected actions work best alongside PIM and break-glass accounts

Protected actions get much stronger when you combine them with Privileged Identity Management (PIM) and emergency access accounts. PIM limits how long an admin role stays active, which adds another layer on top of the step-up requirement. Your break-glass accounts, of course, have to be excluded from these controls, or you could lock yourself out in an emergency. I always recommend documenting these exceptions and testing them regularly. I cover this in more detail in my post on emergency access accounts in Entra ID.

I consider protected actions a must for every production tenant

To me, protected actions aren't optional. Any serious tenant should have them, especially one with multiple admins. They make an attacker's job much harder and hardly get in the way of daily admin work. Setting them up does take some care, and the policy for the authentication context has to be strict. Weigh that against an attacker deleting all your Conditional Access policies within minutes, though, and the decision is easy. If you already use strong authentication and PIM, you can roll this out today and make your tenant a lot more resilient.