Zero Standing Privileges: A Practical Guide to Killing Always-On Admin

A privileged account that is admin only when it is actively being used is dramatically harder to weaponize than one that is admin 24 hours a day. That is the entire thesis of Zero Standing Privileges (ZSP): membership in powerful groups is granted at the moment of need and revoked at the moment of completion. Everything else flows from that.

Why standing privileges keep killing organizations

Look at the post-mortems of the last decade of major intrusions and a pattern repeats: the initial foothold is often boring — a phishing payload, a leaked password, a vulnerable VPN — but the lateral movement always requires a privileged credential that worked at the moment the attacker found it. The credential exists. It is valid. Nothing in the environment cares whether the human who owns it is actually at the keyboard.

Standing privileges create a permanent attack surface proportional to the number of admins times the hours in a week. Even disciplined organizations end up with hundreds of accounts that are technically Domain Admin "just in case." Each one is a windfall to whoever phishes it.

What Zero Standing Privileges actually means

ZSP has a strict and a loose definition. The strict version says no human account holds any production-privileged membership at rest — every elevation is granted dynamically. The loose version permits a small population of break-glass accounts (typically two or three, vaulted, alarmed, never used in the normal course of work) and tolerates a few service identities that are constrained by other controls.

In practice the loose version is what mature programs ship, and it is good enough to reduce blast radius by an order of magnitude. The goal is not philosophical purity; it is that no opportunistic compromise of a workstation hands the attacker production capability.

The four building blocks

1. A vault that holds the credentials, including the ones for elevation targets. Without a vault you are still going to leave passwords in scripts and config files; ZSP collapses without it.
2. A request flow that grants membership for a bounded window — typically 15 minutes to a few hours — with approval logic that fits the risk of the target. High-risk targets demand peer approval; low-risk targets can be self-service with a justification.
3. A revocation path that fires when the window expires or the session ends, whichever comes first. The revocation must be auditable — "the elevation expired silently" is not evidence.
4. A break-glass mechanism that bypasses the request flow for genuine emergencies and screams loudly when used. Break-glass without alarms is a backdoor.

Implementation sequence

The order matters because each step generates the inventory the next step needs.

Step 1: Discover every privileged group membership

Pull membership for Domain Admins, Enterprise Admins, Schema Admins, Account Operators, Backup Operators, Server Operators, every local administrators group, and every cloud-role equivalent. Then build a per-account history of when each membership was actually exercised. The "actually exercised" bit is critical: 60% of standing memberships have not been used in months.

Step 2: Move the credentials into the vault

Every account that retains privileged membership after the discovery pass moves into the vault. Humans no longer know the passwords; they check out access through the PAM gateway. This step alone closes the credential-reuse attack vector and is a prerequisite for revocation tracking.

Step 3: Remove the standing memberships

For accounts you confirmed are used regularly, replace standing membership with a JIT request workflow. The first wave of removals always surfaces surprises — a backup job that nobody knew used a particular service account, a quarterly compliance script that runs at 3 a.m. — so do it in cohorts and instrument carefully.

Step 4: Set the break-glass policy

Decide on two or three accounts that retain standing membership for genuine emergencies. Vault them, randomize the passwords on a 24-hour cycle, alarm the moment they check out, require a post-use justification within 24 hours, and audit every use.

How DataDike implements ZSP

DataDike treats the elevation request as a first-class object: it is an artifact with an owner, a justification, an approval chain, a target, a duration, and a recording of the resulting session. The platform writes the privileged group membership into the directory at activation time, records every command the elevated session produced, and removes the membership at expiry — even if the user forgot to log out. Every step is timestamped, hash-chained, and exportable for audit.

For organizations early in the journey, the typical first wave is Linux SSH and Windows RDP for the Tier-0 estate — the highest-blast-radius systems. Tier-1 and Tier-2 follow in subsequent quarters once the request flow is normalized in the operations culture.