Add, test, or remove protected actions in Microsoft Entra ID

Protected actions in Microsoft Entra ID are permissions that have been assigned Conditional Access polices that are enforced when a user attempts to perform an action. This article describes how to add, test, or remove protected actions.


You should perform these steps in the following sequence to ensure that protected actions are properly configured and enforced. If you don't follow this order, you may get unexpected behavior, such as getting repeated requests to reauthenticate.


To add or remove protected actions, you must have:

Step 1: Configure Conditional Access policy

Protected actions use a Conditional Access authentication context, so you must configure an authentication context and add it to a Conditional Access policy. If you already have a policy with an authentication context, you can skip to the next section.

  1. Sign in to the Microsoft Entra admin center.

  2. Select Protection > Conditional Access > Authentication context > Authentication context.

  3. Select New authentication context to open the Add authentication context pane.

  4. Enter a name and description and then select Save.

    Screenshot of Add authentication context pane to add a new authentication context.

  5. Select Policies > New policy to create a new policy.

  6. Create a new policy and select your authentication context.

    For more information, see Conditional Access: Cloud apps, actions, and authentication context.

    Screenshot of New policy page to create a new policy with an authentication context.

Step 2: Add protected actions

To add protection actions, assign a Conditional Access policy to one or more permissions using a Conditional Access authentication context.

  1. Select Protection > Conditional Access > Policies.

  2. Make sure the state of the Conditional Access policy that you plan to use with your protected action is set to On and not Off or Report-only.

  3. Select Identity > Roles & admins > Protected actions.

    Screenshot of Add protected actions page in Roles and administrators.

  4. Select Add protected actions to add a new protected action.

    If Add protected actions is disabled, make sure you're assigned the Conditional Access Administrator or Security Administrator role. For more information, see Troubleshoot protected actions.

  5. Select a configured Conditional Access authentication context.

  6. Select Select permissions and select the permissions to protect with Conditional Access.

    Screenshot of Add protected actions page with permissions selected.

  7. Select Add.

  8. When finished, select Save.

    The new protected actions appear in the list of protected actions

Step 3: Test protected actions

When a user performs a protected action, they'll need to satisfy Conditional Access policy requirements. This section shows the experience for a user being prompted to satisfy a policy. In this example, the user is required to authenticate with a FIDO security key before they can update Conditional Access policies.

  1. Sign in to the Microsoft Entra admin center as a user that must satisfy the policy.

  2. Select Protection > Conditional Access.

  3. Select a Conditional Access policy to view it.

    Policy editing is disabled because the authentication requirements haven't been satisfied. At the bottom of the page is the following note:

    Editing is protected by an additional access requirement. Click here to reauthenticate.

    Screenshot of a disabled Conditional Access policy with a note indicating to reauthenticate.

  4. Select Click here to reauthenticate.

  5. Complete the authentication requirements when the browser is redirected to the Microsoft Entra sign-in page.

    Screenshot of a sign-in page to reauthenticate.

    After completing the authentication requirements, the policy can be edited.

  6. Edit the policy and save changes.

    Screenshot of an enabled Conditional Access policy that can be edited.

Remove protected actions

To remove protection actions, unassign Conditional Access policy requirements from a permission.

  1. Select Identity > Roles & admins > Protected actions.

  2. Find and select the permission Conditional Access policy to unassign.

    Screenshot of Protected actions page with permission selected to remove.

  3. On the toolbar, select Remove.

    After you remove the protected action, the permission won't have a Conditional Access requirement. A new Conditional Access policy can be assigned to the permission.

Microsoft Graph

Add protected actions

Protected actions are added by assigning an authentication context value to a permission. Authentication context values that are available in the tenant can be discovered by calling the authenticationContextClassReference API.

Authentication context can be assigned to a permission using the unifiedRbacResourceAction API beta endpoint:

The following example shows how to get the authentication context ID that was set on the permission.


Resource actions with the property isAuthenticationContextSettable set to true support authentication context. Resource actions with the value of the property authenticationContextId is the authentication context ID that has been assigned to the action.

To view the isAuthenticationContextSettable and authenticationContextId properties, they must be included in the select statement when making the request to the resource action API.

Troubleshoot protected actions

Symptom - No authentication context values can be selected

When attempting to select a Conditional Access authentication context, there are no values available to select.

Screenshot of Add protected actions page with no authentication context to select.


No Conditional Access authentication context values have been enabled in the tenant.


Enable authentication context for the tenant by adding a new authentication context. Ensure Publish to apps is checked, so the value is available to be selected. For more information, see Authentication context.

Symptom - Policy isn't getting triggered

In some cases, after a protected action has been added, users may not be prompted as expected. For example, if policy requires multifactor authentication, a user may not see a sign-in prompt.

Cause 1

The user hasn't been assigned to the Conditional Access policies used for protected action.

Solution 1

Use Conditional Access What If tool to check if the user has been assigned policy. When using the tool, select the user and the authentication context that was used with the protected action. Select What If and verify the expected policy is listed in the Policies that will apply table. If the policy doesn't apply, check the policy user assignment condition, and add the user.

Cause 2

The user has previously satisfied policy. For example, the completed multifactor authentication earlier in the same session.

Solution 2

Check the Microsoft Entra sign-in events to troubleshoot. The sign-in events include details about the session, including if the user has already completed multifactor authentication. When troubleshooting with the sign-in logs, it's also helpful to check the policy details page, to confirm an authentication context was requested.

Symptom - Policy is never satisfied

When you attempt to perform the requirements for the Conditional Access policy, the policy is never satisfied and you keep getting requested to reauthenticate.


The Conditional Access policy wasn't created or the policy state is Off or Report-only.


Create the Conditional Access policy if it doesn't exist or and set the state to On.

If you aren't able to access the Conditional Access page because of the protected action and repeated requests to reauthenticate, use the following link to open the Conditional Access page.

Symptom - No access to add protected actions

When signed in you don't have permissions to add or remove protected actions.


You don't have permission to manage protected actions.


Make sure you're assigned the Conditional Access Administrator or Security Administrator role.

Symptom - Error returned using PowerShell to perform a protected action

When using PowerShell to perform a protected action, an error is returned and there's no prompt to satisfy Conditional Access policy.


Microsoft Graph PowerShell supports step-up authentication, which is required to allow policy prompts. Azure and Azure AD Graph PowerShell aren't supported for step-up authentication.


Make sure you're using Microsoft Graph PowerShell.

Next steps