Privileged access management: removing standing admin rights

Almost every serious intrusion follows the same arc: get a foothold, then acquire privilege. Which means the practical question is not whether an attacker gets in, but what they can reach once they do. Privileged access management is the discipline of making that as small as possible.

What counts as privileged

Broader than "domain admin", and the omissions are where the risk hides:

• Domain and local administrators
• Cloud console root, owner and global administrator roles
• Database administrators with access to production data
• Application administrators who can change permissions or export data
• CI/CD service principals that deploy to production - often the most powerful identity in the estate
• Break-glass and emergency accounts
• Service accounts and API keys, which typically outnumber human accounts and are rarely reviewed
• Third-party and vendor support accounts

The pipeline identity deserves special attention. It can usually deploy anything, anywhere, and it is frequently excluded from access reviews because nobody thinks of it as a user.

The core practices

1. Separate administrative identities

Administrators should have a distinct account for privileged work, never used for email or browsing. This one change breaks the most common path from a phished document to domain compromise.

2. Eliminate standing privilege

Just-in-time elevation - request, approve, time-bound, logged - means a stolen credential is usually a credential with no current privilege. This is the single highest-value control in the list, and modern identity platforms make it achievable without a heavyweight product.

3. Vault the credentials

Privileged credentials in a vault with checkout, automatic rotation and no shared knowledge. If administrators know the password, you cannot evidence who used it.

4. Monitor and record sessions

For the most sensitive systems, session recording provides both deterrence and investigation capability. At minimum, log every privileged action attributably.

5. Enforce phishing-resistant MFA

On every privileged authentication, without exception - and prefer hardware-backed factors for administrators.

Service accounts - the neglected majority

These fail audits repeatedly because nobody owns them. Minimum viable governance:

• Every service account has a named human owner and a documented purpose.
• Scoped to the least privilege the function requires - not administrator "to be safe".
• Credentials in a secret manager, never in code or configuration files.
• Rotation on a schedule, with the process tested so rotation does not break production.
• Included in access reviews - most are not.
• Decommissioned when the service is retired.

Break-glass accounts

You need them, and they need controls proportionate to their power: strong credentials split or vaulted, excluded from conditional access policies that could lock you out, alerting on any use, mandatory post-use review, and periodic testing that they actually work. An untested break-glass account is a false comfort.

What auditors ask for

• A list of all privileged accounts, human and non-human.
• Evidence of approval for each grant.
• Access review records for privileged accounts, typically quarterly.
• Elevation logs showing request, approver and duration.
• Evidence that leavers with privileged access were removed promptly.
• Break-glass usage records and post-use reviews.

Key takeaways

• Privileged is broader than admin - include pipelines, service accounts and vendors.
• Just-in-time elevation is the highest-value control available.
• Separate administrative identities from everyday accounts.
• Service accounts need named owners and inclusion in access reviews.