A domain administrator opens an RDP session on a user's laptop to resolve a ticket. The session is disconnected without signing out, and the credential stays behind in the machine's memory. That afternoon the same laptop is hit by a phishing email, and from that point the domain controller is a few hours away. Tiered administration is the architecture designed to make that sequence impossible. Microsoft has documented it for more than a decade and France's ANSSI built its Active Directory guide around it. Few organisations apply it in full.
The current version is Microsoft's Enterprise Access Model, and the model rests on one rule: a high-privilege credential must never touch a lower-trust system. The tiers, the dedicated workstations and the authentication silos are the engineering that keeps that rule intact when someone slips.
What is the tier model and what exactly does it protect?
The AD DS tier model sorts identities, workstations and managed assets into three trust tiers. Tier 0 is the identity control plane: domain controllers, AD FS, AD CS, Microsoft Entra Connect, and the accounts and groups that administer them. Tier 1 covers member servers and enterprise applications (Exchange, SharePoint, SQL Server, line-of-business systems) and their administrators. Tier 2 covers end-user devices and the functions that support them: the help desk, device management and user-account administration.
Underneath sits a principle borrowed from the classic integrity models: a lower-trust system must never be able to influence a higher-trust one. Applied to a directory, that means a domain administrator never signs in to an application server or a laptop, because the moment the password is typed on that machine the credential is exposed to whatever the machine is hosting. Microsoft puts it precisely: trust begins at the first physical keyboard used to sign in. The credential and the keyboard set the tier; the IP address does not.
The Enterprise Access Model builds outwards from there. Tier 0 becomes the control plane and takes in every identity system and every centralised access control, including network controls where they are the only access control available, as in industrial environments.
The old Tier 1 is split into a management plane (enterprise IT tooling) and a data and workload plane (per-application administration, sometimes handled by IT and sometimes by the business). Tier 2 is split into user access and application access through APIs, to cover the surface that B2B, B2C and automation have added. The principles are unchanged; the model no longer stops at the edge of the Active Directory forest.
What belongs in Tier 0, and what should not be there?
This is where most implementations fail, by including too much and by leaving things out. Microsoft's definition of Tier 0 is any asset or identity that directly or indirectly controls the directory service.
That covers the obvious (the domain controllers, Domain Admins, Enterprise Admins) and also what almost nobody classifies correctly: the built-in Backup Operators and Server Operators groups, the federation and certificate servers, the connector to Entra ID, the hypervisors the domain controllers run on, and any backup, monitoring, patching or antivirus system whose agent has operating-system-level control over a domain controller. A jump server used to reach a domain controller is Tier 0, whatever network segment it sits in.
SpecterOps maintains a public Tier Zero table for Active Directory and Entra ID with a useful membership test: an asset is Tier Zero if a publicly known abuse technique allows takeover of the identity plane from it. For each asset the table records whether the risk exists in the default configuration or only under a common non-default one, and whether Microsoft lists it among its privileged roles. At Hard2bit we use it as the reference when a client asks us to classify their directory, because it turns a matter of opinion into a list of documented techniques.
The opposite mistake is just as common: putting everything that looks important into Tier 0. A business-critical ERP is not Tier 0 even when a domain administrator runs it; it belongs in the workload plane. Every server or application that does not control identity yet ends up in Tier 0 widens the attack surface of the control plane and dilutes the controls.
Why do so many organisations not apply it?
The objection is a fair one. The model requires every administrator to hold several accounts and, for Tier 0, to work from a dedicated administrative workstation with no email and no general browsing; it requires a review of every backup, monitoring or EDR agent that currently runs with domain privileges on hundreds of servers; and it requires splitting service accounts that have run across several tiers for years. In a directory that has grown for twenty years, that inventory surfaces dependencies nobody remembered, and the systems team feels it as daily friction for months.
On top of that sits a widespread belief that MFA, EDR and network segmentation already cover the risk. They cover some of the risk. MFA protects the sign-in and leaves the credential in memory afterwards untouched; EDR detects behaviour on the machine where it is installed, and at protocol level the replay of a stolen hash against a domain controller is not distinguished from legitimate use; network segmentation limits routes, but an administrator connecting over RDP from a user laptop has just walked through the firewall with their own password.
Evidence from the attack data
The joint report from the NSA, Australia's ASD, CISA and their partners, published in September 2024, sets out the seventeen most common techniques used to compromise Active Directory, AD FS and AD CS. They run from Kerberos ticket theft and forgery (Kerberoasting, AS-REP Roasting, Golden Ticket, Silver Ticket) to AD CS abuse and the Golden Certificate. In between sit DCSync, dumping ntds.dit, Golden SAML and Entra Connect compromise; unconstrained delegation, passwords in Group Policy Preferences and MachineAccountQuota abuse; and SID History, trust bypass, Skeleton Key and password spraying.
Apart from password spraying and AS-REP Roasting, which need no prior credential (only network reach, a list of usernames and, for the latter, accounts without Kerberos pre-authentication), every one of them requires a domain credential or a privileged position. Two groups need separating. Those that depend on a stolen Tier 0 credential (DCSync, dumping ntds.dit, Golden Ticket, Golden SAML, Golden Certificate, Skeleton Key) are the ones tiering closes: if no Tier 0 credential is ever used outside Tier 0, a compromised laptop holds nothing with which to run DCSync or forge a Golden Ticket.
The rest (Kerberoasting, misconfigured AD CS templates, passwords in GPP, MachineAccountQuota, unconstrained delegation) escalate from any domain user by exploiting configuration rather than exposed credentials, and tiering on its own does not close them. That is why attack-path analysis is part of the model and not an add-on. The report stresses that whoever controls the directory can bypass MFA and establish persistence by modifying AD data; the model's purpose is to keep them from ever getting there.
France's ANSSI arrived at the same conclusion from incident response. Its guide to the secure administration of Active Directory-based systems, published in October 2023 (166 pages, 89 recommendations), opens with a finding the agency says it makes regularly: compromises of AD-based systems that result from poor administration practice and insufficient partitioning.
Partitioning into tiers is its central architectural measure, with a chapter on why NTLM and certain uses of Kerberos break the separation even when the tiers exist on paper. That is the reason retiring NTLM and isolating Tier 0 are two halves of one job.
On operational friction, Microsoft's own guidance separates two jobs. Deploying the model's structure (organisational units, groups and policies) is often fast and can be done in minutes with the published scripts; what takes far longer is organisational alignment, roles and processes, and that is where the migration of agents and service accounts described above sits.
Which controls and evidence prove the model exists?
These are the controls that separate a working implementation from one that is merely assumed to work; alongside each, the evidence it leaves.
Inventory and classification of Tier 0
Before anything is changed, the organisation needs a written list of its Tier 0 assets with the reason for each. The SpecterOps table and an attack-path analysis with BloodHound or similar tooling find what the list is missing: the backup system's service account with replication rights, the nested group that ends in Administrators on a domain controller, the hypervisor management server administered with a Tier 1 account. The evidence is the list itself, reviewed and dated, and the number of attack paths into Tier 0 still open after each review.
Separate accounts per tier and dedicated administrative workstations
Each administrator holds one account for every tier they administer. Tier 0 work is done from a privileged access workstation (PAW): a hardened, dedicated machine with no email, no general browsing and no unmanaged software.
From that workstation the administrator can reach the domain controller directly, through a jump server that is itself Tier 0, or via a privileged access management (PAM) tool with just-in-time access, provided the session starts on the workstation itself. The evidence is the per-tier account inventory and the sign-in log of Tier 0 accounts, which should show Tier 0 machines as the only source.
Authentication policy silos and the Protected Users group
Since Windows Server 2012 R2, two mechanisms have allowed the separation to be enforced at the domain controller rather than left to each administrator's discipline. Authentication policies and silos group the Tier 0 accounts into a container and make the issue of their Kerberos tickets conditional on the request coming from a machine in the silo; if it comes from anywhere else, the domain controller refuses.
They demand two things that are often overlooked: Kerberos armouring (FAST) enabled by policy on domain controllers and clients, and the policy switched from audit mode to enforcement. And they do not touch NTLM, which is why they are deployed alongside the group below.
The Protected Users group adds restrictions to its members, among them a ban on NTLM authentication, which is precisely the mechanism an attacker holding a stolen hash needs in order to replay it.
ANSSI includes the PowerShell deployment of a Tier 0 silo as a technical annex to its guide. The evidence is silo and group membership, plus events 4820 to 4823 on the domain controllers (Kerberos ticket or NTLM authentication denied by policy or by Protected Users), which in a healthy environment should tend towards zero, with each one accounted for.
Local accounts, agents and service accounts
There are three fronts where the design alone is not enough and a specific measure is needed. Identical local administrator passwords across the fleet turn one compromised machine into all of them; Windows LAPS manages and rotates them per device.
Agents running with domain rights on Tier 1 servers open an exposure path into the control plane from each such server; the model requires each tool to operate within a single tier. Service accounts shared across tiers collapse the boundary outright: an account that runs on a domain controller and on an application server turns that server into a Tier 0 exposure point. The discipline we set out for non-human identities applies here to the directory.
Detecting violations of the model
Separation also has to be policed once it is designed. The most useful signal is simple to state: an account classified as Tier 0 signing in, interactively or over RDP, to a machine not classified as Tier 0. On the target machine it appears in the logon events (4624) of interactive, remote-interactive or service type, the ones that leave a reusable credential behind. On the domain controllers, and far more scalably, it appears in ticket requests (4768 and 4769) and NTLM authentications (4776) cross-referenced with the list of Tier 0 machines, alongside the silo rejections.
Any SIEM can run that correlation rule if it receives the right logs, and it is among the identity alerts with the fewest false positives, provided the inventory is sound. The techniques in the joint report have their own detections too, which we cover in a separate article on detecting Kerberoasting, AD CS abuse and Golden Ticket.
The cost of not doing it
Without tiered administration, the sequence this article opened with completes in hours, and its stages match the techniques in the joint report: a credential harvested on a laptop, a hop to a server, a better credential, and finally privileged access to every system in the directory, from which the ransomware is deployed. Each of those hops is a lateral movement that needs a credential, and tiering would have kept the last one, the Tier 0 credential, off every machine that is not Tier 0.
There is a compliance dimension as well. NIS2 requires access control policies under Article 21 as part of its minimum measures. Spain's National Security Framework (ENS) devotes its access-control family of measures (op.acc) to identification, segregation of duties and the management of access rights. DORA asks financial entities for access management policies that also cover privileged access. None of those frameworks names the tier model, but an audit that asks how many people hold domain administrator rights and from which machines they exercise them is asking, in other words, whether Tier 0 exists.
The decision belongs to leadership
Tiering is a leadership decision that arrives at the table looking like a technical project. Microsoft cites a common target of fewer than five people with Domain Admins-equivalent rights and no service accounts in that group. Getting down to that number, stripping domain rights from the agents that hold them for convenience and requiring administrators to work from dedicated workstations are decisions someone with authority has to take and then hold when the systems team objects, which it will, for months. What that buys is a verifiable answer: a laptop compromised tonight holds no credential that is any use for taking control of the directory.
At Hard2bit we work that route from the identity and access review through to the threat hunting that tracks down the paths still open, and we start every engagement with the same list: who holds Tier 0, and why.
This article describes an administrative architecture and configuration controls for defensive purposes, drawing on public documentation from Microsoft, SpecterOps, ANSSI and the joint NSA, ASD and CISA report available as of 14 September 2026. References to NIS2, ENS and DORA are indicative and do not replace each organisation's own legal analysis. Every control should be tested in a controlled environment before production, and the Tier 0 asset classification must be validated against each organisation's actual directory.
Frequently asked questions
How does the AD tier model differ from the Enterprise Access Model?
▾
The classic tier model (Tier 0, 1 and 2) was built to contain privilege escalation inside an on-premises Active Directory forest. The Enterprise Access Model absorbs it and extends it to an estate with several clouds, external identities and API access: Tier 0 becomes the control plane, Tier 1 splits into a management plane and a workload plane, and Tier 2 into user access and application access. The principles are unchanged; the scope no longer ends at the directory's edge.
Is a backup server Tier 0?
▾
If its agent has operating-system-level control over a domain controller or can restore the directory database, yes: whoever controls that server controls the directory. The same applies to monitoring, patching and antivirus platforms and to the hypervisors the domain controllers run on. The alternative is for those tools to operate within a single tier, with separate instances or accounts for Tier 0.
How many people should hold domain administrator rights?
▾
Microsoft cites a common target of fewer than five people with Domain Admins-equivalent rights, and no service accounts in that group. Not every Tier 0 task requires Domain Admins membership: least privilege applies within the tier itself, and audit functions are kept separate from operations.
Does a privileged access workstation help if the administrator connects over RDP from their normal laptop?
▾
No. The trust level of a session is set by the machine where the credential is typed, not by the destination. If the session originates on a user laptop, the Tier 0 credential is exposed to that laptop even when the destination is a hardened jump server. The dedicated workstation has to be the physical starting point of the session.
What do authentication policy silos and the Protected Users group do?
▾
Silos let the domain controller refuse to issue Kerberos tickets to a Tier 0 account when the request comes from a machine outside the silo; the restriction is enforced server-side and requires Kerberos armouring (FAST) to be enabled and the policy set to enforcement mode. Because silos do not touch NTLM, they are deployed together with Protected Users, which prevents its members from authenticating with NTLM (the mechanism an attacker holding a stolen hash needs to reuse it) and from being delegated in Kerberos, among other restrictions. Both have existed since Windows Server 2012 R2.
How do I detect someone breaking the tier model?
▾
With a simple correlation rule: an account classified as Tier 0 signing in, interactively or over RDP, to a machine that is not Tier 0. The scalable version is built on the domain controllers, from ticket requests (events 4768 and 4769) and NTLM authentications (4776) cross-referenced with the list of Tier 0 machines, plus the silo rejections (4820 to 4823); the per-machine version uses interactive or remote-interactive 4624 logon events on each target. With a sound inventory it is an alert with very few false positives.
Does the tier model replace network segmentation?
▾
No, it complements it. Segmentation limits network routes; the model limits where each credential may be used. An administrator opening RDP from a user device carries their credential to the far side of the firewall entirely legitimately, and segmentation does not help there. Microsoft's documentation says it in so many words: containment, not perimeter, is the boundary.
Does any regulation require the tier model?
▾
None names it. NIS2 requires access control policies under Article 21, Spain's ENS devotes the op.acc family to identification, segregation of duties and management of access rights, and DORA asks for access management policies that cover privileged access. An audit asking how many people hold domain rights and from which machines they use them is, in effect, checking whether Tier 0 exists.