Understanding AD Tiering: what Tiers 0, 1 and 2 protect
The Tier 0/1/2 model traditionally separates the administration of identity infrastructures, that of servers and applications, and that of user workstations. This separation follows a precise principle: a compromise in a lower-trust environment must not make it possible to exercise an administration capability in a higher-trust environment.
| Tier | Usual scope | Security objective |
|---|---|---|
| Tier 0 | Domain controllers, identities and components able to control AD | Protect the organisation's root of trust |
| Tier 1 | Member servers, applications and their administrators, without Tier 0 control capability | Contain the compromise of infrastructures and applications |
| Tier 2 | User workstations, everyday identities and local support | Prevent a user compromise from exposing higher privileges |
This classification should not be confused with a business criticality scale. A server containing particularly sensitive financial data may fall under Tier 1, while a less visible technical console must be protected at Tier 0 if it can run privileged commands on a domain controller.
The Tier 0 scope therefore includes indirect control paths. An AD CS certification authority, an identity synchronisation mechanism, a hypervisor hosting domain controllers or a backup system able to restore their data must be analysed according to the actual powers they confer. The objective is to keep the Tier 0 surface as small as possible without ignoring its dependencies.
Classic Tiering and the Enterprise Access Model: two complementary models
In 2026, Microsoft continues to document the AD DS Tiering model. The Enterprise Access Model, or EAM, extends its reasoning to hybrid systems, cloud environments, applications and new access paths.
The EAM distinguishes in particular the Control Plane, which governs identities and access control mechanisms, the Management Plane, which administers systems, and the Data/Workload Plane, which carries business applications and data. It also takes into account user and application access paths, including APIs and non-human identities.
For an organisation running Active Directory and Microsoft Entra ID, both representations are useful. AD DS Tiering structures the protection of the on-premises directory and its dependencies, while the EAM makes it possible to study control relationships between on-premises identity, cloud administration, management tools and applications.
This is not about automatically replacing Tiers with new names. It is about extending the analysis to every capability that can modify an identity, an access policy or the systems that control them.
A four-phase deployment method
Phase 1 — Map control capabilities and attack paths
The first step is to identify the components that actually have the power to control Active Directory. The analysis covers privileged groups, delegations, ACLs, GPOs, technical accounts, certification systems, management tools and the infrastructures that administer domain controllers.
An asset inventory is not enough to produce this map. You must be able to explain how an identity or a system could act on a higher-trust resource. A deployment console able to modify a service running on a domain controller, for example, is a control path to be qualified, even if its operations team does not belong to the Active Directory team.
The expected deliverable is a reasoned map of trusted resources, technical dependencies and identified attack paths. It must distinguish confirmed capabilities, potential risks requiring investigation and accepted dependencies.
Phase 2 — Build a genuinely enforceable Tier 0 boundary
Isolating Tier 0 starts with separating administrative and office accounts, reducing standing rights and choosing trusted administration environments. Tier 0 accounts must not be used to administer Tier 1 servers or Tier 2 workstations.
Privileged access workstations, or PAWs, meet this requirement by separating sensitive tasks from exposed uses such as web browsing and email. Administration intermediaries must preserve this trust level: a bastion used to administer a domain controller itself becomes a Tier 0 dependency.
Logon restrictions, Windows policies, secret protection mechanisms and network filtering make the separation effective. Their deployment requires progressive testing to preserve the legitimate flows Active Directory needs to operate, notably authentication and directory services.
Phase 3 — Extend the model to servers, applications and technical identities
Tier 0 separation does not automatically resolve dependencies between servers, applications and user workstations. You need to identify the maintenance accounts, automations, cross-cutting tools and third-party access that could reintroduce higher-level privileges into less trusted environments.
This phase examines in particular local accounts, service accounts, technical secrets, deployment pipelines and shared consoles. Least privilege, just enough administration and temporary rights activation mechanisms can reduce exposure where technical constraints allow.
The model must remain workable for administrators. An architecture that is theoretically watertight but bypassed to carry out day-to-day operations does not achieve its security objective.
Phase 4 — Test the boundaries and maintain their effectiveness
A Tiering architecture must undergo functional and technical verification. Controlled logon attempts, privilege analyses and administration path tests make it possible to observe whether the intended prohibitions are actually enforced.
Results are documented together with exceptions, required fixes and residual risks. Changes to Active Directory, new agents installed on domain controllers and changes to administration platforms must then trigger new verifications.
For organisations wishing to place this work within a broader AD security programme, our 90-day Active Directory security method details a complementary approach to prioritisation, remediation, detection and evidence production.
Before remediation
- Support account · lower trust
- Excessive permission on a GPO
- GPO applied to Tier 0 resources
- Control path to the identity infrastructure
After remediation
- Support account · lower trust
- Excessive delegation on the GPO removed
- Tier 0 resources · separate administration, approved origins
Before remediation, an excessive delegation on a GPO applied to Tier 0 resources opens a control path from a lower-trust support account. Once this delegation is removed, administration identities are separated and logon origins are controlled, this identified path is closed. This does not demonstrate that every other possible path has disappeared.
The challenge of service accounts and legacy applications
Service accounts are a particular difficulty in a Tiering project. They run tasks without human intervention, sometimes hold legacy privileges and may be used by several applications or servers. Their membership of a sensitive group or their ability to modify a Tier 0 resource can create an attack path that the separation of human administrator accounts does not address.
gMSAs can make secret management and rotation easier in some Windows environments. They do not, however, remove the need to control which machines are allowed to use these accounts, their permissions and the resources they give access to.
Legacy applications sometimes impose protocols, shared accounts or automation mechanisms that are hard to change. Rather than abruptly removing these uses, a Tiering approach must inventory them, identify their owner, qualify the privileges actually required and define a remediation path compatible with operations.
When an exception cannot be removed immediately, it must have an owner, a justification, compensating controls, a review date and exit conditions. An exception left without governance gradually becomes a permanent feature of the architecture.
Administration forest, bastion and PAM: choosing according to real paths
Building a separate administration forest, sometimes referred to as Red Forest or ESAE, is not a universal prerequisite for securing Active Directory. The ANSSI-PA-099 guide recommends avoiding its deployment, except where there is a sufficiently significant need to pool Tier 0 administration across several forests, with a prior analysis of the constraints and risks introduced.
Bastions and PAM are possible tools for controlling privileged access, without replacing identity separation, the security of source devices and control of dependencies. A vault can protect a secret without preventing a privileged session from being hijacked from a compromised source workstation.
The right architecture therefore depends on the complete path: source device, identity used, authentication mechanism, intermediaries, authorisation, target and monitoring. Recording a session improves traceability, but is not proof that the session could not have been hijacked.
How do you demonstrate that Tiering is actually effective?
A Tiering project must produce verifiable evidence, not just architecture documentation. Acceptance criteria must correspond to the risks identified at the start and be replayable after each significant change.
| Control | Expected verification |
|---|---|
| Out-of-tier logon | A controlled Tier 0 logon attempt on a lower-trust workstation or server is denied |
| Administration origin | Tier 0 operations are allowed only from approved environments |
| Indirect dependencies | Consoles and agents able to control DCs are identified and protected at the required level |
| Service accounts | Secrets and permissions do not create unjustified cross-tier dependencies |
| Hybrid identity and PKI | AD CS and synchronisation control paths are mapped and addressed |
| Emergency access | A recovery procedure is protected, documented and tested |
| Detection | Sensitive changes and boundary-crossing attempts generate the expected events and alerts |
The relevant measure is not to declare that 100% of servers are assigned to a Tier. It is to demonstrate which known attack paths have been neutralised, which control capabilities remain and why the remaining exceptions are accepted.
A security audit score remains a useful posture indicator. It replaces neither the analysis of permissions and dependencies, nor the tests used to verify trust boundaries.
From theoretical Tiering to operational remediation
Tiering projects often encounter a difficulty that goes beyond technical configuration: several teams administer interdependent components without a shared view of their responsibilities and risks. Yet directory security depends as much on the team administering a backup platform or a deployment console as on the one managing Domain Admins accounts.
In an engagement with an organisation in the transport sector, Ariovis supported the recovery of a PAM programme whose foundations lacked structure, particularly regarding AD Tiering and the application onboarding method. The work covered clarifying the model, defining the Tiering, hardening servers and industrialising integrations. This experience illustrates the importance of addressing architecture, usage and operations together, without claiming that a theoretical model or the installation of a tool is enough.
Operational support must leave the teams with reusable assets: dependency map, Tiering policy, logon rules, exception matrix, acceptance tests, operating responsibilities and a recurring control plan. It is on these results that the progress of Active Directory security should be assessed.
Technical references
Microsoft Learn — Tier model for Active Directory Domain Services. Documentation of the AD DS Tier 0/1/2 model, its trust boundaries and how it fits with the Enterprise Access Model.
Microsoft Learn — Enterprise Access Model. Overview of the control, management and data planes, and of user and application access paths.
ANSSI — Recommandations relatives à l'administration sécurisée des systèmes d'information reposant sur Microsoft Active Directory. ANSSI-PA-099 guide (in French), version of 2 October 2023. Recommendations R5 to R8 notably cover path analysis and partitioning; R80 covers Tier 0 administration workstations and R85 to R86 administration forests.