Privileged accounts

A privileged account is any account that can change the security of a system: who can get in, what they can do, what gets logged, and which keys and certificates are trusted. Attackers go after these accounts because one of them can undo every other control. This page covers how to recognize privileged accounts (including the ones nobody thinks of as admin accounts), why administrators need separate accounts, how tiering and clean sources keep high-value credentials out of low-trust places, and what an inventory should record.

What makes an account privileged

SP 800-53 Rev. 5 defines privilege by what an account can do. The AC-2(7) discussion describes privileged roles as roles that let individuals perform "security-relevant functions that ordinary users are not authorized to perform". It lists key management, account management, database administration, system and network administration, and web administration. AC-6(10) lists privileged functions, including disabling or altering security controls, establishing system accounts, performing system integrity checks and administering cryptographic keys.

A useful test follows from those definitions: an account is privileged if it can grant privilege, change security controls, or read or alter data at a scale or sensitivity ordinary users cannot. By that test, the list is longer than the "Domain Admins" group:

Separate administrator accounts

AC-6(2) asks that users who hold security functions use non-privileged accounts or roles "when accessing nonsecurity functions". The reason, from its discussion: it "limits exposure when operating from within privileged accounts or roles". In practice, email, web browsing and chat are where malicious content arrives. If the person reading a phishing email is signed in as a global administrator, a single click can hand over the tenant.

AC-6(2) accepts either a separate account or a change of role, as long as switching role gives the same assurance as switching between a privileged and a non-privileged account. Common implementations:

• A second account (for example adm-jdoe) with no mailbox and no internet browsing, used only for administration.
• One identity with no standing admin rights that elevates into an admin role for a limited time. See just-in-time access.

Either way, protect the privileged path with stronger authentication. IA-2(1) requires multi-factor authentication for access to privileged accounts. CISA's phishing-resistant MFA fact sheet names system administrators as high-value targets and suggests IT administrators and help-desk staff as a first phase for phishing-resistant MFA. See phishing-resistant MFA.

Admin tiering and the clean-source principle

Tiering is a common practice, not a requirement in the NIST documents cited here. It is widely used because it addresses a real attack pattern. An attacker compromises an ordinary workstation, waits for an administrator to sign in to it, and steals the administrator's credentials or session from memory.

The idea is to group assets by how much control they give:

Control plane (often called tier 0)

Systems that control identity and trust for everything else: directory services, the identity provider, PKI and certificate authorities, the PAM tool, secrets managers, and the administrative consoles of the cloud tenancy.

Management plane (tier 1)

Systems that administer workloads: server and database administration, hypervisor and container platform management, deployment pipelines.

Workloads and user devices (tier 2)

Applications, user workstations and mobile devices. This is where most untrusted content is handled.

Two rules follow:

1. Clean source: anything that controls a system must be at least as trustworthy as that system. A workstation used to administer the directory is part of the directory's security boundary.
2. No downward exposure: never sign in to a lower tier with higher-tier credentials. A tier-0 administrator does not log in interactively to a user's laptop or an application server, because that machine could expose the credential.

Privileged access workstations

A privileged access workstation (PAW) is a device used only for administration. It is hardened, has no email or general web browsing, and can reach only the management interfaces it needs. It is the "clean source" for admin sessions. Variants include dedicated physical machines and locked-down virtual desktops that are themselves managed from a clean source. The trade-off is cost and convenience. Many organizations reserve full PAWs for control-plane administrators and use lighter controls for the other tiers.

Logging and monitoring privileged use

AC-6(9) asks you to log the execution of privileged functions. Its discussion names insider threat and compromised accounts as the reason. AC-2(12) adds monitoring for atypical use: unusual times, unusual locations, and reporting it to named people. For privileged accounts, the events worth alerting on include:

• Sign-in to a privileged account from a device or network that is not an admin workstation.
• Changes to privileged group membership or admin role assignments (AC-2(7)(b) and (c): monitor privileged role assignments and changes to them).
• Changes to authentication policy, federation trust, MFA settings or audit configuration.
• Any use of an emergency account.

An inventory you can use

You cannot reduce what you have not counted. AC-2 asks you to define allowed account types, assign account managers and specify authorized users, roles and privileges for each account. For privileged accounts, a useful inventory record looks like this:

Illustrative data. Record the owner as a person or role that can answer for the account, not a team mailbox.

Common mistakes

• Counting only accounts named "admin" and missing service accounts, sync accounts and anyone who can reset an admin's MFA.
• Giving administrators a single account for both email and administration (AC-6(2)).
• Using the same local administrator password on every machine, which turns one compromised host into all of them.
• Signing in to user workstations or application servers with control-plane credentials "just this once".
• Protecting admin accounts with SMS or push approval when phishing-resistant MFA is available. See MFA strength.
• No owner, no last-used date, no review date: the account cannot be safely removed, so it never is.

Sources

1. NIST SP 800-53 Rev. 5: Security and Privacy Controls for Information Systems and Organizations, NIST. Public domain (U.S. government work).
2. CISA fact sheet: Implementing Phishing-Resistant MFA (October 2022), CISA. Public domain (U.S. government work).
3. NIST SP 800-63-4: Digital Identity Guidelines, NIST. Public domain (U.S. government work).