Managing Privileged Roles in Microsoft Entra ID: A Pragmatic Approach

Introducing a custom model for understanding privileged roles in Microsoft Entra ID, developed by TrustedSec

Whenever our team conducts a Hardening Review of Microsoft Entra, 365, or Azure, we always emphasize protecting privileged user accounts. This inevitably leads to the question, Which Entra roles are actually privileged and need protecting? Unfortunately, looking to Microsoft for an answer is, to put kindly, confusing. So, we set out to answer the question ourselves in a way that is clear, consistent, and pragmatic. After all, if defining the privileged roles doesn't actually help you defend them, then what's the point?

In this blog, we'll do three main things:

1. Explore what Microsoft says about privileged roles in Entra, and why it wasn’t enough for us
2. Present our answer: the Entra Privileged Tier Model
3. Unpack the model a bit to explain how to use it to protect accounts with these roles and why we made some of the choices we did

Are you ready? Let's dive in.

Part I: Microsoft's Privileged Role Answers… and Questions

What does Microsoft itself have to say about privileged Entra roles? The first place to look is the Microsoft Learn article Microsoft Entra built-in roles, where we find the list of all roles built into Entra and see that some are labeled privileged. Another article, Privileged roles and permissions in Microsoft Entra ID, unpacks what is meant by this privileged label. In particular, a privileged role is:

A built-in or custom role that has one or more privileged permissions.

A privileged permission is defined as:

In Microsoft Entra ID, permissions that can be used to delegate management of directory resources
to other users, modify credentials, authentication or authorization policies, or access restricted data.

Looking at the built-in roles list, we see 28 roles marked privileged:

But we're not done yet.

Next, we turn to Security Defaults, those minimum protections that Microsoft applies to Entra tenants out of the box. With Security Defaults enabled, 16 administrator roles are required to perform MFA for every sign-in:

Finally, we can look to the Microsoft-managed Conditional Access policy, Multifactor authentication for admins accessing Microsoft Admin portals, which covers 14 roles it describes as 'highly privileged':

Looking at these sources together, we get a combined list of 33 built-in roles that seem to be 'privileged' or 'for administrators' in some way or another. Interestingly, none of the sources contains the entire list. The managed Conditional Access policy is missing two (2) roles covered by Security Defaults. The Security Defaults list contains five (5) roles not marked privileged in the Microsoft Learn built-in roles reference, including Exchange Administrator and SharePoint Administrator.

Plus, all of these lists are missing roles that we consider privileged and requiring protection, such as Directory Synchronization Accounts, Groups Administrator, and Teams Administrator.

At this point, you probably have a lot of the same questions we did when we first ran through all of these comparisons:

• Scratches head… So which roles are actually privileged?
• Why do the built-in admin protections like Security Defaults and the managed Conditional Access policy not cover all roles marked privileged?
• Why aren't Security Defaults and the managed Conditional Access policy consistent with each other?
• Why are some of the roles covered by Security Defaults and the managed policy not marked privileged in the Microsoft Learn documentation?
• What does it even mean to be 'privileged'?
• Do we really need to apply the same protections to an Application Developer as we do to a Global Administrator?
• What do we even do with this information?!

Part II: The Entra Privileged Tier Model Developed By TrustedSec

Fortunately for you, we are constitutionally incapable of leaving well enough alone. (It's part of what makes us good at our jobs!) So, we knuckled down and answered these questions, or at least most of them. (No, we still don't know why the Microsoft sources are so inconsistent.)

Our team has assessed and/or hardened over one hundred Microsoft Cloud environments, always with the goal of delivering effective and actionable recommendations to our clients.

So, in looking at these roles we focused on a single objective: To describe and classify privileged Entra roles in a way that drives protective actions and doesn't require a PhD in quantum mechanics to understand!

We analyzed all of the built-in Entra roles for the capabilities each role has in the Entra tenant or connected services, the impacts to the organization if an account with that role were compromised by a malicious actor, and the protections we would expect to be in place to prevent or mitigate such a compromise. The initial review led to three (3) broad buckets of roles, and we saw clear parallels to the AD Administrative Tier Model.

From this foundation, we crafted definitions and logical criteria for each level to ensure consistency and repeatability.

Therefore, we introduce the Entra Privileged Tier Model for Microsoft Entra ID Roles, where we categorize the roles into three (3) privileged tiers that can be summarized as follows:

• Entra Tier 0: Core administration and security control of the Entra tenant itself
• Entra Tier 1: Administrative control of major service components in the Microsoft Cloud environment
• Entra Tier 2: Limited-scope or read-only privileges

Full definitions of each Entra Privileged Tier are provided below, including the roles within each tier, expected security protections for entities with those roles, and the impacts of compromised access at that tier.

Entra Tier 0

Entra Tier 0 represents the most privileged Microsoft Entra ID roles and is defined as the roles that control the Entra ID Tenant, including core tenant administration, security controls configuration, and privileged user management. Roles with an inherent path to escalate to Tier 0 privileges without dependence on misconfiguration or other interventions are also considered Tier 0.

Use of Entra Tier 0 roles should be extremely limited. Assignments must be monitored and tightly governed with least-privilege assignment strictly enforced. Robust, attack-resistant authentication and session management controls must be implemented. Compromise of Entra Tier 0 access is expected to result in critical impacts to the Microsoft Cloud environment, up to full compromise of the Entra ID tenant and any downstream services, such as any connected Microsoft 365 environment and/or Azure subscriptions.

The following roles are considered Entra Tier 0:

Entra Tier 1

Entra Tier 1 is defined as the roles that are not Entra Tier 0 but match any of the following criteria:

• Provide administrative (write) capabilities in the Entra tenant
• Control services within the Microsoft Cloud environment, including Microsoft 365 service components and Microsoft Azure subscriptions
• Known indirect escalation paths to Tier 0 privileges based on common misconfigurations or combinations of factors in the environment

Use of Entra Tier 1 roles should be limited, monitored, and subject to least-privilege assignments. Attack-resistant authentication and session management controls should be implemented. Compromise of Entra Tier 1 access is expected to result in significant impacts to the Microsoft Cloud environment, up to and including disruption and partial compromise of the Entra ID tenant and/or full compromise of the impacted Microsoft Cloud services.

The following roles are considered Entra Tier 1:

Entra Tier 2

Entra Tier 2 is defined as the roles that provide limited administrative capabilities within Microsoft Cloud services and/or provide read access to sensitive security and configuration information. This sensitive information could be used to identify vulnerabilities or misconfigurations that facilitate privilege escalation or other attacks on the Entra ID tenant and Microsoft Cloud services. Compromise of Entra Tier 2 access is expected to result in moderate impacts to the Microsoft Cloud environment that are isolated to the affected services.

The following roles are considered Entra Tier 2:

*Note: For dedicated administrator accounts with Tier 0 or Tier 1 roles, we recommend that Global Reader and/or Security Reader roles be assigned to the accounts as active rather than eligible. This reduces the risk of privileged session compromise by allowing the users to perform reporting, diagnostic, and other read-only functions without first needing to elevate to a higher privilege level.

Conclusion to the Entra Privileged Tier Model

Organizations can use the Entra Privileged Tier Model to understand the security impacts of roles in Microsoft Entra ID and implement effective security controls appropriate to each tier, ensuring no sensitive roles are missed. Built-in Entra roles not listed in the tiers are considered unprivileged. Updates to the roles in each tier may be required over time as Microsoft adds or modifies roles and functionality in Microsoft Entra and Microsoft 365. Azure subscription roles are not included in the model.

Part III: Unpacking the Model

Tier-Based Security

As we said at the beginning, pragmatism matters. This work must help improve security or it is of little value. So, without going into too much detail, here are some ways the tiers inform security posture in Entra:

Privileged vs. Unprivileged

First, we draw a bright red line between privileged and unprivileged user accounts. Any users assigned roles listed in the model above are considered privileged users. Robust, attack-resistant MFA methods must be enforced for these sign-ins, and controls like session duration and browser persistence limits should be implemented as well. We also look for Entra ID P2-equivalent licensing to ensure the accounts are licensed for PIM and so proactive risk-based controls can be enforced for the users.

Next, let's walk through security controls for the tiers in ascending order, recognizing that the controls for each tier build on the controls of lower tiers:

Tier 2 Security

Role assignments for Tier 2 roles should be managed through PIM for human users, with assignments configured as eligible and only activated for limited durations. The user accounts should be separate from the individual's regular-use account, and the privileged user account should not be assigned a productivity license (e.g., access to Outlook, OneDrive, Teams, etc.). These separations significantly reduce the likelihood that a compromised regular-use account would allow an attacker to gain privileges in the Entra tenant. Note that for dedicated administrator accounts with Tier 0 or Tier 1 roles, Global Reader and/or Security Reader roles should be configured with active assignments, as was described above.

However, we're also realistic about the political considerations. Some of the users in this tier fall outside the IT vertical (e.g., the folks in Accounting that use the Billing Administrator role) and may push back on requirements like maintaining separate accounts. So, this is the privilege tier where we're okay with organizations making the risk-informed decision to relax some of these recommendations in favor of productivity and inter-departmental relationships. It's not the 'most secure' option, but it might be the right option for some cases. That said, if you do choose to assign Tier 2 roles to regular-use accounts with productivity licenses, the use of PIM and attack-resistant MFA are non-negotiable.

Tier 1 Security

At Tier 1, the pendulum between 'secure' and 'easy to use' swings definitively toward 'secure'. Privileged accounts must be separate from regular-use accounts and must not have a productivity license assigned. Eligible role assignments through PIM, attack-resistant MFA, and Conditional Access session controls are also expected for human users.

Tier 0 Security

At minimum, accounts with Tier 0 role assignments must be subject to all of the controls for Tier 1 accounts.

Additionally, least-privilege analysis is critical for this tier. Too often, we find users granted (or enabling) Global Administrator or other Tier 0 roles out of expediency when lower-tier roles would be sufficient. Therefore, regularly evaluate these role assignments and usage by asking the question: Does this account need this level of access, or can lower tier roles be used instead?

Administrators assigned highly privileged roles should also be assigned less-privileged roles and should be trained to activate only the minimum necessary roles at any given time. There is no good reason for someone to activate Global Administrator to edit mail flow rules, modify a SharePoint site, or even provision an unprivileged user account. This is also why assigning Global Reader and/or Security Reader roles to Tier 0 or 1 user accounts is beneficial, because doing so reduces the times that administrators need to elevate privileges further. Microsoft provides a couple of good resources for determining the least-privileged roles required to do different tasks:

• Privileged roles and permissions in Microsoft Entra ID: Who can reset passwords
• Least privileged roles by task in Microsoft Entra ID

Although these controls may be sufficient for many organizations, let's consider things one step further. Organizations that are larger, have a higher risk profile, or have a more mature IAM security program should implement dedicated privileged access workstations (PAWs) to more fully isolate all highly privileged administrative activity from unprivileged workstations and accounts. Use reputable guidance such as the Microsoft learn articles Securing devices as part of the privileged access story and Legacy privileged access guidance. (Microsoft may call it 'legacy', but it is still relevant for organizations not pursuing Microsoft's full Enterprise Access Model approach.)

That's probably far enough down the rabbit hole for the scope of this article. For what it's worth, we devote an entire section of the Microsoft Cloud Hardening Review to evaluating privileged account security for our clients' Entra tenants.

But Why is This Role in That Tier?

Once we articulated the privilege tier definitions, assigning each role to a tier was mostly a clear-cut process. However, our team did go back and forth on a few of the roles, and we think explaining some of our rationale will be helpful:

• Exchange Administrator
  • Argument: Given how much damage could be done to an organization through malicious takeover of the email tenant, shouldn't Exchange Administrator be considered Tier 0?
  • Rationale: The financial damages from business email compromise and related frauds are inarguable, not to mention the privilege escalation and sensitive data theft opportunities that could arise from a compromised Exchange Administrator account. Ultimately, though, this role fits exactly into the definition of Tier 1. It controls a service within the Microsoft Cloud environment. The role does not directly affect core tenant administration, security configuration, or privileged user management. The role can be used in conjunction with misconfigurations, social engineering, or other TTPs to attack and possibly gain Tier 0 access, but it does not have Tier 0 access natively. In this, the role is no different than something like SharePoint Administrator. The Exchange Administrator role absolutely merits strong protections, and that's why it is in Tier 1.
• Intune Administrator
  • Argument: Shouldn't Intune Administrator be Tier 0? A compromised Intune Administrator account could cause damage across a wide array of assets and could use workstation access to capture higher tier credentials. Plus, if PAWs are managed through Intune then Intune Administrators manage the workstations dedicated for Tier 0 use.
  • Rationale: The potential impacts of a malicious Intune Administrator on Tier 1 or lower assets are what make this a Tier 1 role. For PAWs, we recommend not managing the devices through Intune, thus removing the devices from Intune Administrator control entirely. If your organization takes a different approach, then you may need to make tiering adjustments based on your context.

This was just a preview of our discussions around the role tiering, but we hope seeing behind the curtain a bit is useful.

Conclusion

To recap:

Roles in Entra can be categorized into three (3) privileged tiers, not unlike the AD administrative tiers many of you are already familiar with. The tiers are:

• Entra Tier 0: Core administration and security control of the Entra tenant itself
• Entra Tier 1: Administrative control of major service components in the Microsoft Cloud environment
• Entra Tier 2: Limited-scope or read-only privileges

The tiers inform practical, actionable security controls and pragmatic, risk-informed decision making about configurations and access controls in Entra.

With this Entra Privileged Tier Model, we hope you are more empowered to understand, manage, and secure privileged roles and users in Entra and Microsoft 365 so that your tenant, and ultimately your organization, are better protected.

* * *

We are grateful to Sean Metcalf, Edwin David, and Paul Sems for their inputs and review.