top of page

Your Microsoft Entra Tenant Isn’t as Secure as You Think – Fix It with Protected Actions!

Writer's picture: Sebastian F. MarkdannerSebastian F. Markdanner

Protecting highly critical configurations in our Entra tenants has never been easier! Join me as we explore Protected Actions in Microsoft Entra and how they help us lock down security-sensitive operations.

Futuristic garden with neon trees and flowers. A glowing box displays Microsoft Entra: Protected Actions. Vibrant digital patterns surround.

A solid Identity and Access Management (IAM) strategy based on Zero Trust principles strengthens security by enforcing separation of duties, elevating access requests, and ensuring Just-In-Time (JIT) access, among others.


But what if you need to further restrict specific high-impact actions, even for authorized admins?


That’s where Protected Actions come in.


This feature enhances security by requiring additional authentication steps or stricter access conditions before critical configurations can be modified, reducing the risk of accidental misconfigurations or malicious changes.


Any strong IAM strategy build on the Zero trust principals hardens our identity and access by utilizing tools to separating duties, elevate access requests and providing Just In Time access - but what if we want to further lock down specific critical actions? That's where Protected Actions


Today we'll look at how we can further enhance our organizations IAM strategies by utilizing Microsoft Entra


Table of Contents

 

What Is Microsoft Entra Protected Actions?

Microsoft Entra provides a load of IAM solutions and features like Conditional Access, Privileged Identity Management, and Access Reviews.


Protected Actions build on these by allowing Conditional Access policies to enforce stricter authentication and access requirements on specific high-risk actions.


For example, you can require phishing-resistant MFA before:

  • Modifying, creating, or deleting Conditional Access policies

  • Changing cross-tenant access settings

  • Updating tenant restrictions


Here are a list of the currently supported Protected Actions:

Permission

Description

Update basic properties for Conditional Access policies

Create Conditional Access policies

Delete Conditional Access policies

Update basic properties for conditional access policies

Create conditional access policies

Delete conditional access policies

Update allowed cloud endpoints of the cross-tenant access policy

Update Microsoft Entra B2B collaboration settings of the default cross-tenant access policy

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.

Update tenant restrictions of the default cross-tenant access policy.

Update Microsoft Entra B2B collaboration settings of cross-tenant access policy for partners.

Update Microsoft Entra B2B direct connect settings of cross-tenant access policy for partners.

Create cross-tenant access policy for partners.

Update cross-cloud Teams meeting settings of cross-tenant access policy for partners.

Delete cross-tenant access policy for partners.

Update tenant restrictions of cross-tenant access policy for partners.


 

Why Should We Use Protected Actions?

Managing identity and access in any organization requires multiple layers of security. At a baseline, most organizations already enforce MFA, RBAC, and approval- or time-based access restrictions to limit unnecessary risk. However, these controls alone may not be enough to protect critical configurations from accidental misconfigurations or intentional misuse.


Even when an administrator is fully authenticated and authorized, they could still make a mistake or, worse, be targeted in a social engineering attack.

Without additional safeguards, an attacker with administrative access could disable essential security measures before launching further attacks.


Protected Actions mitigate these risks by introducing an additional security checkpoint before an admin can modify critical settings.


Instead of relying solely on role-based access, Protected Actions ensure that:

  • Even authorized admins must meet stricter security requirements before making high-impact changes.

  • Highly sensitive operations require phishing-resistant authentication methods, reducing the likelihood of stolen credentials being used maliciously.

  • Insider threats—whether accidental misconfigurations or intentional misuse—are significantly reduced.


By implementing Protected Actions, you gain a higher level of control over critical security operations, ensuring that even the most trusted identities must pass additional authentication hurdles before making key changes.

This not only reinforces Zero Trust principles but also provides greater assurance that your most critical security policies remain intact.


 

Setting Up Microsoft Entra Protected Actions

Protected Actions leverage Conditional Access and Authentication Contexts. If you’re familiar with my Conditional Access series, this setup will feel familiar.


Step-by-step guide

The full configuration is managed in the Microsoft Entra portal:

  1. Access the Authentication Contexts Menu

    1. Open the Microsoft Entra Admin Center

    2. Navigate to Protection → Conditional Access.

    3. Click Authentication Contexts, then select New Authentication Context

      Screenshot of Microsoft Entra admin center showing "Conditional Access" and "Authentication contexts" with highlighted navigation steps.

    4. Provide a meaningful name, and optionally a description, and choose the ID for the Authentication Context

      Microsoft Entra ID interface showing "Conditional Access" setup. Right panel for adding authentication context with fields for name, description, and ID.

  2. Create a Conditional Access Policy

    1. Go to Policies → New Policy

      Microsoft Entra admin center dashboard showing Conditional Access Policies. One policy for multifactor authentication is listed as active.

    2. Name your policy using a consistent naming convention (see my Conditional Access series for best practices) Set Target Resources to Authentication Context and select the one you just created

      Conditional Access policy creation interface with fields for name, policy application, assignments, and controls. "Create" button at bottom.

    3. Configure conditions and grant controls based on your security requirements and set the policy to Report-Only mode for now

      Access policy setup screen showing options like user assignments, network configuration, and grant controls. "Require authentication strength" is checked.

  3. Configure Protected Actions

    1. Navigate to Identity → Roles & Admins Click Show more if you don’t see “Protected Actions” right away Select Protected Actions and click Add Protected Actions

      Admin interface showing "Roles and administrators" with options like "Protected actions." The "Add protected actions" button is highlighted.

    2. Choose the Authentication Context you created earlier Click Select Permissions

      UI screen titled "Add protected actions" shows a dropdown for Conditional Access authentication context. No permissions added yet.

    3. In the fly-out, choose the actions you want to protect (e.g., Conditional Access policy modifications).

      Interface for adding protected actions in Conditional Access settings. Shows permission list with checkboxes and descriptions on a white background.

    4. Once you’ve created the Protected Actions, you can review them in the Protected Actions overview. Here, you’ll see a list of all the actions you’ve secured, along with the Authentication Contexts assigned to them.

      Admin dashboard showing "Protected actions" in Conditional Access settings. Lists permissions for creating, updating, and deleting policies.

Lastly you'll need to enable the Conditional Access policy, by setting it to On. The Protected Actions feature is now enforcing stricter security controls for your selected actions!


 

User experience

Once Protected Actions are configured, any administrator attempting to perform a protected operation will receive a security prompt requiring additional authentication. This ensures that even fully authorized admins must meet stricter security controls before making critical changes.


For example, in my setup, managing Conditional Access policies requires phishing-resistant MFA. When I try to create a new Conditional Access policy, I see the following prompt:

Microsoft Entra admin center screen showing Conditional Access policies. A popup reads: "Additional steps required" with "Yes" or "No" options.

At this point, the admin must complete the necessary authentication steps before proceeding.


What Happens If You’ve Recently Authenticated?

If the admin has already authenticated with the required method within the last five minutes, they won’t be asked to go through the full authentication process again. Instead, they will only see the prompt and a quick page refresh before being allowed to continue.


This balance ensures that security remains tight without adding unnecessary friction to admin workflows.


 

Wrapping Up

Microsoft Entra Protected Actions provide a powerful way to lock down critical operations, ensuring that even authorized admins must meet strict authentication requirements before making high-impact changes.


By implementing Protected Actions, you can:


  • Reduce Security Risks – Enforce phishing-resistant Authentication, restrict session lifetimes and other security controls for sensitive admin actions.

  • Prevent Accidental or Malicious Changes – Ensure critical configurations require additional verification.

  • Strengthen Zero Trust Security – Apply stricter access policies where they matter most.


With Protected Actions in place, your tenant remains safer from both insider risks and external threats—because security isn’t just about who has access, but also what they can do with it.


And now… Another bad joke!


There are 10 types of people in the world…

Those who understand binary, and those who don’t. 😎


Stay tuned for my next post, where we’ll dive into securing identity and access—A continuation of my series on securing a Microsoft Business Premium Environment


Subscribe, follow, and keep locking down your security like a pro! 🚀

bottom of page