What Counts as Privileged

Scoping a programme requires a definition. Too narrow and the interesting accounts are outside it; too broad and nothing gets done.

The workable definition

An account is privileged if using it can cause harm that the organisation could not readily detect or undo.

That covers the obvious cases and catches the ones a role-based definition misses.

The obvious categories

Domain and directory administrators.

Local administrator on servers and workstations.

Root and sudo on Unix systems.

Database administrators.

Hypervisor and virtualisation administrators.

Network device administrators.

Cloud platform administrators, which in practice exceed all the above in reach.

The categories usually missed

Service accounts, which frequently hold broader rights than any human and never change their password.

Backup accounts, which by design can read everything.

Application administrators in business systems — the finance platform, the HR system, the CRM. Not managed by infrastructure teams and holding the data an attacker wants.

Build and deployment pipelines, which can push code to production and hold credentials for everything they deploy to.

Monitoring agents, installed everywhere with elevated rights.

Directory synchronisation accounts, which bridge on-premises and cloud identity.

Certificate authorities and signing keys.

Password vault administrators, which is the account that unlocks all the others.

The paths nobody maps

Beyond accounts, the ability to become privileged.

Anyone who can modify a group that grants administrative rights.

Anyone who can reset an administrator's password.

Anyone who can deploy code that runs with elevated rights.

Anyone who can modify a scheduled task running as a privileged account.

Anyone with physical or console access.

Anyone who can restore a backup into an environment they control.

These are privilege paths rather than privileged accounts, and mapping them is the difference between a programme that works and one that secures the front door.

Tiering

Treating all privileged accounts identically makes the programme unaffordable.

Tier zero: control of the identity infrastructure itself. Directory administrators, certificate authorities, the vault, cloud tenant administrators. Compromise here is total.

Tier one: servers, databases, hypervisors, network infrastructure.

Tier two: workstation administration and application-level administration.

Protect tier zero first and completely, including a rule that tier zero credentials are never used on lower-tier systems, which is the control most often skipped and most often exploited.

Producing the list

Start from the directory: members of administrative groups, directly and by nesting.

Add local administrators from endpoint management.

Add cloud role assignments, which are the ones most likely to be sprawling.

Add service accounts from wherever they are recorded, which is usually nowhere complete.

Add application administrators by asking each system owner.

Then map the paths, which requires tooling or a determined afternoon with a graph.

Expect the count to be several times what anyone estimated, which is the normal result and the argument for the programme.

Application administration

The category infrastructure-led programmes routinely miss, and it holds the data attackers want.

Finance systems, where an administrator can create payees and alter records.

HR platforms, holding personal data on everyone.

CRM, holding the customer base.

Document platforms, where an administrator can read everything.

Ticketing systems, which accumulate credentials pasted by users.

None of these appear in a directory group. Finding them requires asking each system owner, once, and recording the answer.

Include them in the inventory even where the tooling cannot onboard them, because an unlisted risk is an unmanaged one.

Writing the definition down

The scope statement determines what the programme covers, and it should survive contact with an argument.

State the test: an account is privileged if its use can cause harm the organisation could not readily detect or undo.

List the categories it covers, explicitly, including service accounts and application administration.

List what is out of scope and why, which is the part that prevents scope disputes later.

Define the tiers and give examples of each.

Have it agreed by security, infrastructure and whoever owns the applications.

One page, reviewed annually. Without it, every onboarding conversation reopens the question of whether this counts.