Restrict Administrative Privileges: Separation, Not a Headcount Cull

Restrict administrative privileges is the fifth of the Essential Eight, and it asks for separation rather than subtraction. It wants three things a headcount reduction does not deliver: privileged access validated against a need that still exists and revalidated rather than held permanently, privileged accounts separated from the general-purpose activity that exposes them, and privileged use logged somewhere the privileged accounts cannot quietly edit.

Almost every team reads the name as an instruction to cull. They run a report on the domain admins group, remove six people who should not have been there, and mark the strategy done. The cull is worth doing and changes very little: ten admins whose privileged accounts also read email are a worse position than thirty whose privileged accounts cannot reach a mailbox.

It is a credential-handling programme, not an entitlement audit: how hard would it be to steal a privileged credential, and how much would it buy once stolen. Neither answer depends on the headcount, which is why a team can halve its admin population and move nowhere on the Essential Eight maturity model.

Restrict Administrative Privileges Starts With Validating Need

To restrict administrative privileges you start by validating need: somebody other than the requester agrees the access is needed for work the requester actually does. Revalidating it means that agreement expires, and the expiry is enforced by removal rather than by a reminder.

The loop is request, justify, review. Someone asks for privilege and states what they cannot do without it, a named approver who understands the system agrees, and the grant is recorded with the justification attached. That justification goes back in front of an approver on a cycle, with removal as the default outcome unless the need is restated.

The typical finding in an assessment is a privilege granted for a project three years ago. The project shipped, the person moved teams, the group membership stayed, and nobody can now say what the access was for. Recording the justification at grant time is what makes the later review possible; without it, the review degrades into asking the holder whether they still want the access. And the review has to produce removals — one that confirms every existing grant is not a review, it is a signature.

Separate Admin Accounts Are the Load-Bearing Control

Separate admin accounts are the load-bearing control in this strategy, and the one most often half-implemented. A privileged account that is also the account used to read email and browse the web gives an attacker the privilege with the first phishing click, and no amount of entitlement review compensates for that.

The mechanics are unglamorous. Mail and the web are the two routes by which someone else's code arrives on an endpoint. If the identity in that browser or mail client administers the domain, then code running in that session runs with the privilege, or with the credential material and tokens the session holds. The attacker does not need to escalate. They were handed the privilege with the initial compromise.

Separation means a named human has two identities: an unprivileged daily account for mail, browsing, documents and chat, and a distinct privileged account with its own credential, its own multi-factor enrolment, no mailbox and no sign-in to productivity services. Privilege attaches to the second and never to the first, including temporarily.

The half-measures are where this comes apart:

• A different password on the same account. One identity with two credentials is not two identities. The privilege is still reachable from the session that reads mail.
• Elevating the daily account. Adding the everyday identity to a privileged group for a change window puts the privilege back on the exposed account exactly when an attacker would want it there.
• An admin account with a mailbox. The default outcome when privileged accounts are provisioned through the same path as staff accounts, and it quietly undoes the control.
• Break-glass accounts used routinely. One that three engineers use weekly is an unattributable privileged identity.

Then put strong authentication on the privileged identity specifically. The multi-factor authentication strategy meets this one at exactly that point: a privileged account without phishing-resistant factors is the obvious target once separation is in place.

Keeping Privileged Accounts Off Email and the Web

Restricting privileged accounts from email, the web and internet services is what makes separation hold, and it works in both directions. Inbound, a privileged account with no mailbox and no web access cannot be phished, because there is no channel to deliver a lure to. Outbound, a privileged session that cannot reach the internet cannot fetch a second-stage payload or call home to a command-and-control endpoint, which turns a successful execution into a dead end.

What matters is where the restriction lives. A policy saying administrators should not browse from admin accounts is not the control. Enforcement is no mailbox provisioned, egress denied at the network or proxy layer for privileged identities, and conditional access refusing them entry to productivity SaaS — each verifiable by test rather than assertion, which is what makes it evidenceable.

The Workstation a Privileged Session Starts From

The workstation a privileged session starts from decides whether separation survives. A privileged credential typed into the laptop that reads mail has separation of accounts but not of machines — a keylogger or token thief on the general-purpose build collects it however distinct the two identities look on paper.

So the practice is for privileged sessions to originate from a controlled environment. A privileged access workstation is the usual name for it: a tightly limited application set, no mail client, no general browsing, hardening beyond the standard fleet, and a narrow set of permitted destinations. The shape varies — a dedicated hardened device, a locked-down virtual desktop or jump host reached from the daily machine, a cloud-hosted environment for control-plane work — and what matters is whether the privileged credential ever touches the general-purpose build.

Hardened administrative workstations belong to the upper end of this strategy's maturity rather than its entry point. Introduce them where the privilege is most consequential — directory administration, the cloud control plane, production database access — once separation and internet restriction are in place.

Logging Privileged Access and Actually Reviewing It

Logging privileged access is insufficient on its own, because the control is the review. Capture privileged authentication, privileged group membership changes, elevation events and administrative actions, and send them somewhere the privileged accounts under scrutiny cannot alter or delete.

The review is short if you know what you are looking for. Was anyone added to a privileged group outside the request process. Did a privileged account authenticate from the general-purpose fleet rather than the administrative environment, or reach the internet. Did a dormant privileged account wake up. Did a privileged action happen outside a change window with no change record behind it.

In a healthy environment each of those questions returns a short list of exceptions. If one returns hundreds of rows, that is the finding: the restriction it tests is not being enforced.

The Privileged Access Nobody Scoped

The privileged access nobody scoped is where this strategy is most often overstated. Teams build a careful programme around the corporate directory and leave four categories of administrative access outside it.

• Cloud control planes. An account that can create, reconfigure or destroy infrastructure is administrative access, and it lives in an identity system separate from the corporate domain. Root and organisation-level accounts in particular sit outside any review cycle.
• SaaS admin consoles. The administrator of the HR system, the CRM, the code host or the identity provider holds privileged access to the data in it. Business owners hand these out and they rarely reach an IT privileged access register.
• CI/CD systems that deploy to production. A pipeline with production deployment rights is administrative access to production, whatever the IAM model calls it. So is editing the pipeline definition, or approving a merge that deploys automatically.
• Database superuser accounts. Superuser access bypasses the application's own authorisation entirely, and the credential is often shared, static and embedded in a connection string nobody has touched in years.

The fix is to enumerate every system where one identity can reconfigure it, read all its data or destroy it, and bring each into the same request-justify-review loop as the domain. That also produces most of the access controls evidence ISO 27001 and SOC 2 auditors ask for — the same ground as implementing least privilege for SOC 2.

Service Accounts and Non-Human Identities

Service accounts and non-human identities have the worst hygiene in most environments, because nobody experiences the consequences of neglecting them. They typically have no owner, no rotation and no expiry, with privileges granted generously at creation to make an integration work on a deadline — and they are often the most privileged identities present. A service account made a domain administrator years ago because that was what got a backup agent working is still a domain administrator, with a static password nobody will change because nothing documents what would break.

Four things make them manageable: a named human owner, a record of what it does and which system uses it so the credential can be rotated without an outage, rotation on a schedule or a platform-managed identity instead, and a scope cut back to the one job it performs. Block interactive sign-in and alert on an attempt — a service account at a console is either a misconfiguration or an intrusion.

How Privileged Access Management Maturity Progresses

Privileged access management maturity progresses by depth and coverage rather than by adding controls to a list. The entry position is validating access on request, separating privileged from unprivileged accounts, and keeping privileged accounts out of mail and the browser. From there the direction of travel is consistent: coverage widens to the control planes, consoles and pipelines above; revalidation becomes a cycle that removes access; logging becomes centralised, tamper-resistant and reviewed rather than merely retained; privileged sessions originate from controlled administrative environments; and what a privileged credential can reach gets tighter, so a stolen one is worth less.

The authoritative wording for each level sits with the Australian Signals Directorate and is revised periodically, so take the specifics from ASD's own guidance rather than any secondary summary, including this one. The shape of the progression does not change: separation first, then coverage, then the environment privileged work happens in.

Privileged Access Questions Teams Ask

These are the privileged access questions teams ask most often once they realise the strategy is about separation rather than about reducing the number of administrators.

Keep privileged access evidence current between assessments

Book a demo and we'll show how Konfirmity tracks privileged access across the corporate domain, cloud control planes and SaaS consoles, with revalidation and removals recorded as evidence.

Book a demo

Separate First, Then Count

Run the cull if you have not — it is quick and it removes genuine risk. Then start the real programme: separating privileged identities from the activity that exposes them, cutting off the channels those identities can be reached through, and widening the scope until it covers every system where one account can reconfigure, read or destroy everything.

The sequence matters because the later work depends on the earlier. Hardened administrative workstations are wasted where the daily account can still be elevated, and log review is wasted if the thing you would detect is normal.

The next step is a list: every identity that holds privilege, in every system, with an owner and the reason it exists. Most teams cannot produce that in an afternoon, and finding out why is the most useful thing this strategy does for them. From there, use the Essential Eight maturity model to pick a target level — and if procurement is your reason for doing this, check what the Australian government tender in front of you asks you to state.