Administrative tiering separates the accounts and machines used to manage critical systems from the ones used to read email. It works well when it is enforced and provides nothing at all when an administrator can connect to a domain controller from the same laptop they use for everything else. The NCSC’s guidance on secure system administration describes the model, and the gap between the diagram and the practice is where most internal findings live.
Why the boundary matters
Credentials are exposed wherever they are used. If a domain administrator signs into an ordinary workstation, their credentials are available in memory on a machine that browses the web and opens attachments, which is precisely the machine an attacker expects to compromise first. Tiering exists to stop that: highly privileged accounts are used only from dedicated administrative workstations to manage tier zero systems, and lower tier accounts never touch them. The rule is simple and the enforcement is where organisations struggle.
How the model breaks in practice
The most common failure is a jump box that anybody can reach from anywhere. If administrators connect to it from their normal laptops, the jump box becomes a place where privileged credentials are exposed to a machine at ordinary risk, and the boundary has moved rather than existed. Other failures include administrators holding both a normal and a privileged account but using the privileged one for daily work, service accounts with tier zero rights logging into application servers, and management agents installed on domain controllers that are administered by a lower tier team.
“Ask to watch an administrator do a routine task on a domain controller. If they open a remote session from the same laptop they use for Teams, you have a tiering document rather than tiering. That observation takes five minutes and tells you more than reading the policy would in an afternoon.”
William Fieldhouse, Director, Aardwolf Security Ltd
Making it enforceable
Enforce with authentication policies and network controls rather than instructions. Authentication policy silos restrict where privileged accounts may log on, so a tier zero account simply cannot authenticate to a workstation. Firewall rules should permit management protocols only from administrative workstations to the systems they manage. Require multi-factor authentication for the jump host and record sessions where the risk justifies it. Keep the administrative workstations tightly built, without email or general browsing, because their whole purpose is to be a machine that is unlikely to be compromised. Application control on those machines is worth the effort it takes to maintain.
Proving the boundary holds
Test it from below. Internal administrative access testing starts from an ordinary user or workstation and establishes whether management interfaces are reachable, whether privileged credentials can be captured from a lower tier machine, and whether a tier one administrator can reach tier zero material through a backup, a deployment tool or a monitoring platform. Those indirect routes are where a well designed model usually leaks, and an accredited penetration testing provider will look for them specifically rather than stopping when the direct path is blocked.
Frequently asked questions about administrative tiering
These questions come up whenever privileged access is being redesigned.
Is a jump box enough on its own?
Only if it cannot be bypassed and cannot be reached from an ordinary workstation. A jump box with no restriction on where connections originate moves the exposure rather than removing it.
Does cloud management change the model?
It extends it. Cloud roles that can execute commands on servers belong in the same tier as the servers themselves, so administrative tiering has to cover portal access and pipeline permissions as well as domain rights.
