For years, organizations have invested heavily in endpoint protection, multifactor authentication, Conditional Access, email security, and network controls. All of those technologies are important, but they can still be undermined if an attacker gains access to a highly privileged identity. That is the central problem administrative tiering is designed to solve.
Attackers do not always need to exploit a complicated vulnerability or bypass every security product in the environment. Sometimes they only need to compromise the wrong administrator account, capture a privileged credential, or gain control of a system where those credentials have been used.
Once that happens, the attacker may be able to disable security controls, create new accounts, change policies, access sensitive data, and move laterally across the organization.
Microsoft’s Active Directory Tier Model has addressed this problem for years by separating administrative access according to levels of trust. The technology around identity has changed considerably since the model was first introduced, but the fundamental principle remains just as relevant today:
Higher-trust identities should never be unnecessarily exposed to lower-trust systems.
Microsoft’s Active Directory Tier Model project provides a practical framework for applying those principles to on-premises Active Directory. EntraOps extends many of the same ideas into Microsoft Entra ID by introducing classification, automation, monitoring, and operational governance for cloud identities.
Together, the two projects provide the foundation for a more complete approach to privileged identity security across hybrid environments.
The Problem Is Bigger Than Active Directory
It is easy to think of administrative tiering as an Active Directory security model. However, the real purpose of the model is not simply to protect Domain Controllers or Domain Administrator accounts. It is designed to protect the systems and identities that control everything else.
In a traditional Active Directory environment, that control plane includes Domain Controllers, administrative groups, identity synchronization systems, certificate services, and other infrastructure capable of changing how users and computers authenticate.
In Microsoft Entra ID, the same principle applies to highly privileged roles, application permissions, workload identities, Conditional Access policies, authentication methods, and administrative accounts.
The technology may be different, but the risk is the same. If an attacker compromises an identity with enough administrative influence, many other security controls can be changed, bypassed, or disabled.
This is why privileged identity security cannot be treated as an isolated Active Directory concern. It has to include on-premises directories, cloud identity platforms, applications, automation accounts, service principals, synchronization services, and the workstations administrators use to access them.
Understanding the Tiering Model
The traditional Active Directory Tier Model separates administration into logical trust boundaries. It is not simply a method for grouping servers or organizing administrators. The more important question is not, “Which systems does this administrator manage?” It is, “What could this administrator ultimately control if their account or workstation were compromised?”
That difference is important because administrative influence is rarely limited to a single server. An administrator may manage one application, but the account they use could also have access to a management platform, virtualization environment, backup system, or identity service that provides a path to much broader control.
A simplified version of the traditional model looks like this.
Tier 0
Tier 0 contains the identities, systems, and services that directly or indirectly control the identity platform. Examples often include:
- Domain Controllers
- Active Directory administrative groups
- Active Directory Certificate Services
- Identity synchronization infrastructure
- Federation services
- Privileged identity management systems
- Enterprise administrative accounts
- Systems capable of managing Tier 0 assets
Tier 0 is not limited to Domain Controllers. Any system that can control, modify, authenticate, recover, or impersonate highly privileged identities may effectively belong in the same trust boundary.
Tier 1
Tier 1 generally covers servers, applications, and business workloads. This may include:
- Application servers
- Database servers
- SharePoint
- Exchange
- File servers
- Line-of-business applications
- Server management platforms
- Server administrator accounts
Tier 1 administrators may hold significant power over business systems, but they should not automatically have control over the organization’s identity platform.
Tier 2
Tier 2 includes end-user workstations and the systems used to manage them. Typical examples include:
- User laptops and desktops
- Help desk administration
- Endpoint management
- Desktop support
- Standard user accounts
- Workstation administrator accounts
The core objective is straightforward: higher-trust identities should not authenticate to lower-trust systems.
A Tier 0 administrator should not sign in to a normal user workstation to check email, browse the web, or troubleshoot a desktop problem. If that workstation is compromised, the attacker should not be able to harvest Tier 0 credentials because those credentials should never have been exposed to it.
Tiering Is Really About Containment
One of the biggest misconceptions about the tiering model is that it exists to prevent compromise.
It does not.
The model assumes that compromise will eventually happen somewhere. A user may open a malicious attachment. A workstation may be infected. A server may contain an unpatched vulnerability. An application credential may be leaked.
No security architecture can guarantee that every attack will be stopped.
What tiering does is limit how far an attacker can move after gaining an initial foothold. Without clear administrative boundaries, an attacker may be able to move from a user workstation to a management server, capture a more privileged credential, compromise a server administrator, and eventually reach the identity platform.
Tiering deliberately breaks those paths. Privileged credentials are kept away from lower-trust systems. Administrative accounts are separated by function. Dedicated workstations are used for sensitive tasks. Access is restricted according to the level of trust required. Each boundary forces the attacker to find a new method of escalation rather than simply reusing credentials captured from another system.
This makes tiering less about creating an impenetrable environment and more about controlling the blast radius when something goes wrong.
That is one of the main reasons the model continues to work. It reflects the reality that security is not only about preventing attacks. It is also about ensuring that one compromised endpoint does not become a complete compromise of the organization.
Microsoft’s Active Directory Tier Model Project
Historically, Microsoft’s administrative tiering guidance was delivered through whitepapers, reference architectures, diagrams, and security recommendations. Those resources explained what organizations should build, but administrators were often left to translate the guidance into practical configuration. That usually meant designing:
- Organizational Units
- Security groups
- Delegation models
- Group Policy Objects
- Authentication restrictions
- Administrative accounts
- Privileged Access Workstations
- Logging and monitoring
- Operational processes
The result was that every implementation looked slightly different. Some organizations adopted only the parts they considered achievable. Others created a strong design but struggled to maintain it. Many remained stuck in the planning stage because the amount of manual work required was significant. Microsoft’s Active Directory Tier Model GitHub project helps make the architecture more repeatable and operational.
Rather than providing guidance alone, the project introduces automation, deployment patterns, validation, testing, logging, and configuration management. It gives organizations a practical framework for building the underlying Active Directory structure needed to support administrative isolation.
This is an important shift because it moves tiering away from being a one-time design exercise.
A secure tiering model cannot simply be deployed and forgotten. Groups change, administrators change roles, policies drift, new systems are introduced, and exceptions slowly accumulate. The model needs to be tested, validated, and maintained over time. By treating the configuration more like code, organizations gain a repeatable way to deploy the model, identify drift, review changes, and maintain a consistent security posture.
The Cloud Needs Tiering Too
Many organizations have spent years separating administrative access in Active Directory, only to flatten those boundaries when moving into Microsoft Entra ID. A single highly privileged cloud account may be used to manage users, create applications, approve permissions, configure Conditional Access, manage authentication methods, troubleshoot access, and administer Azure resources.
Technically, that approach is convenient. From a security perspective, it recreates the same problem administrative tiering was designed to prevent. Every additional task performed by a highly privileged account increases its exposure. The more places the account signs in, the more systems it interacts with, and the more frequently it is used, the greater the opportunity for compromise. Cloud administration benefits from the same separation principles as traditional Active Directory. Organizations should consider separating responsibilities such as:
- Identity administration
- Conditional Access management
- Application administration
- Privileged role management
- Azure resource administration
- Security operations
- User support
- Workload identity management
This does not mean creating unnecessary complexity or assigning a different account for every individual task. It means understanding which roles can influence the identity control plane and ensuring those identities receive stronger protection.
The terminology may have changed, but the trust model has not.
A Global Administrator, Privileged Role Administrator, application owner, automation account, or highly privileged service principal can be just as important to protect as a Domain Administrator.
EntraOps Brings the Model Into Microsoft Entra ID
This is where EntraOps becomes particularly useful. EntraOps is an open-source project designed to apply Enterprise Access Model concepts to Microsoft Entra ID through automation, classification, monitoring, and operational governance. Rather than simply producing a list of privileged users, it helps organizations understand how identities fit into a wider administrative model.
That includes both human and non-human identities.
In modern cloud environments, workload identities can be just as powerful as administrator accounts. Service principals, managed identities, automation accounts, deployment pipelines, and applications may hold permissions that allow them to read data, modify resources, manage users, or change configuration.
These identities are often harder to track because they do not behave like normal user accounts. They may not use MFA, may not sign in interactively, and may be managed by application or development teams rather than identity administrators. EntraOps helps bring those identities into the same governance conversation. Its capabilities include areas such as:
- Classification of privileged users
- Classification of workload identities
- Discovery of privileged role assignments
- Change tracking through Git
- PowerShell-based automation
- Custom Security Attribute integration
- Administrative Unit support
- Microsoft Sentinel integration
- Azure Resource Graph visibility
- Workbook-based reporting
The value is not simply in collecting more information. The value comes from organizing that information around administrative influence and trust.
Instead of only asking, “Who is a Global Administrator?”, organizations can begin asking more useful questions:
- Which identities belong to each administrative tier?
- Which users or applications can influence the control plane?
- What privileged access changed recently?
- Which workload identities have excessive permissions?
- Which assignments violate the intended model?
- Which identities need stronger monitoring or protection?
- Which changes were approved, and which require investigation?
Those are operational questions rather than documentation questions. That distinction matters because identity environments change constantly.
The Two Projects Solve Different Parts of the Same Problem
Microsoft’s Active Directory Tier Model project and EntraOps are not competing solutions. They address different parts of the identity environment.
The Active Directory Tier Model project focuses primarily on creating and maintaining administrative boundaries within on-premises Active Directory. It provides the structure needed to separate privileged administration, restrict authentication paths, and protect the systems that control the directory.
EntraOps focuses on extending similar concepts into Microsoft Entra ID. It helps classify cloud identities, identify privileged assignments, monitor changes, and apply a more automated governance model.
A simplified way to view the relationship is:
| Area | Active Directory Tier Model | EntraOps |
|---|---|---|
| Primary platform | Active Directory | Microsoft Entra ID |
| Main focus | Administrative isolation | Classification and governance |
| Human identities | Yes | Yes |
| Workload identities | Limited focus | Strong focus |
| Deployment automation | Yes | Yes |
| Configuration tracking | Yes | Yes |
| Cloud role visibility | No | Yes |
| Active Directory structure | Yes | No |
| Operational monitoring | Yes | Yes |
Used together, they provide a stronger foundation for hybrid identity security. One establishes the administrative boundaries within Active Directory. The other helps carry those ideas into the cloud, where identities, applications, permissions, and automation are often more dynamic.
Tiering Is More Than Separate Administrator Accounts
Creating separate administrator accounts is often the first step organizations take, but it is not enough on its own. An administrator may have one normal account and one privileged account, yet still use both from the same workstation. If that device is compromised, both identities may be exposed. Similarly, an organization may create separate accounts but allow unrestricted sign-in across every server, workstation, browser, and management portal. True tiering requires several controls to work together. These typically include:
- Separate administrative identities
- Dedicated administrative workstations
- Authentication restrictions
- Role separation
- Device trust requirements
- Strong sign-in controls
- Privileged access workflows
- Logging and monitoring
- Regular access reviews
- Configuration validation
The identity, device, and management path all matter. A Tier 0 account used from an untrusted workstation is no longer meaningfully isolated, regardless of how carefully the account was created.
This is why privileged access must be considered as an end-to-end process rather than simply an account design.
Identity Security Is Becoming Operational
Perhaps the biggest change in identity security is the move away from static documentation. For years, organizations created diagrams showing administrative tiers, documented privileged groups, and recorded who was supposed to have access. Those documents were useful, but they quickly became outdated. Identity environments do not stand still. Administrators join and leave. Applications receive new permissions. Service principals are created. Emergency access is granted. Automation is introduced. Projects end, but the privileges created for them remain. A diagram created six months ago may no longer represent the environment that exists today. Modern identity security therefore needs to include continuous validation. Organizations increasingly need:
- Automated discovery
- Configuration drift detection
- Version-controlled changes
- Approval workflows
- Access reviews
- Dashboards and reporting
- Security monitoring
- Alerting
- Historical visibility
- Integration with deployment pipelines
Both the Active Directory Tier Model project and EntraOps support this operational mindset. They treat administrative security as something that must be continuously maintained rather than something completed during a migration or security project. That approach is much closer to the way modern environments actually operate.
A More Holistic Identity Security Model
When these ideas are brought together, tiering becomes part of a wider identity security architecture. The goal is not simply to label accounts as Tier 0, Tier 1, or Tier 2. The goal is to understand which identities and systems can influence the organization’s control plane and then protect them accordingly. That includes examining:
- Who has privileged access
- Where privileged identities can authenticate
- Which devices they can use
- Which systems can manage them
- Which applications hold powerful permissions
- Which automation accounts can modify configuration
- How emergency access is controlled
- How changes are approved
- How drift is detected
- How suspicious activity is monitored
This is where the model becomes truly useful.
Tiering provides the architecture. Automation makes it repeatable. Monitoring makes it sustainable. Governance ensures it remains aligned with the organization’s intent.
Final Thoughts
Identity has become one of the most important security boundaries in the enterprise. Endpoints, firewalls, email protection, encryption, and monitoring all remain essential, but the identities controlling those systems require an even higher level of protection. Microsoft’s Active Directory Tier Model provides a strong architectural foundation for separating privileged administration and limiting credential exposure within Active Directory. EntraOps builds on similar principles for Microsoft Entra ID by helping organizations classify privileged identities, track changes, monitor workload identities, and introduce automation into cloud identity governance.
Together, they support a more complete and realistic approach to privileged identity security. The value of the tiering model is not that it guarantees an attacker will never gain access. Its value is that it prevents a single compromised user, device, server, or application from automatically becoming a path to everything else.
That principle worked in traditional Active Directory environments, and it remains just as important in the cloud.