Zero standing privileges (ZSP): definition and how to start

Zero standing privileges (ZSP) is a privilege model in which no account holds admin, root, DBA or cloud owner rights by default. When someone needs elevated access, they request it for one task, it is approved, they use it through a controlled session, and it is removed automatically when the time runs out. Between tasks there is nothing for an attacker to steal or an insider to misuse. This guide is for security leaders, identity teams and platform engineers who want a clear definition of zero standing privileges, how it relates to just-in-time access and least privilege, and a staged plan to get there.

Zero standing privileges (ZSP) is a privileged access model in which no human or machine identity keeps elevated rights by default; privileges are granted just in time for a specific task and time window, then revoked automatically.

For a short definition you can link to, see the zero standing privileges glossary entry.

Why is standing access the risk?

A standing privilege is a right that exists whether or not anyone is using it. The domain admin group membership granted for a migration two years ago, the DBA role kept “in case”, the cloud access key created for a one-off script: each one is valid at 3 a.m. on a Sunday, when nobody is working and nobody is watching.

Attackers rely on that. The Verizon 2024 Data Breach Investigations Report found that over the past ten years “stolen credentials have appeared in almost one-third (31%) of breaches.” A stolen password is only as dangerous as the rights attached to it at the moment it is used. If the account holds no admin rights by default, the attacker gets an ordinary user, not the estate.

Standing access also grows on its own. Rights are added for projects and incidents and rarely removed, shared passwords outlive the people who knew them, and cloud roles outlast the job. ZSP reverses the default: access has to be justified each time, rather than removed when someone remembers.

How do ZSP, just-in-time access and least privilege differ?

The three are related but answer different questions. NIST describes least privilege as restricting access “to the minimum necessary to accomplish assigned tasks.” That limits how much an account can do. It says nothing about when.

	Least privilege	Just-in-time (JIT) access	Zero standing privileges
What it is	A principle	A mechanism	An end state
Question it answers	How much access?	How is access granted and removed?	Does anyone hold privilege by default?
Privilege between tasks	Still present, but scoped	Removed when the grant expires	None
If the account is stolen while idle	Attacker gets the scoped rights	Attacker gets whatever is not under JIT	Attacker gets no privileged rights
Typical controls	Role design, access reviews	Requests, approvals, time limits, auto-revocation	JIT for all privileged access, vaulted credentials, short-lived cloud credentials

In practice you need all three. Least privilege decides what a grant should contain, just-in-time access delivers and removes it, and ZSP is what you have when no privileged right is left outside that workflow.

ZSP also fits the zero trust model. NIST SP 800-207 states that zero trust “assumes there is no implicit trust granted to assets or user accounts.” A standing admin right is exactly that kind of implicit trust.

What does a zero standing privileges request look like?

Every privileged action follows the same short lifecycle. Take an engineer investigating an incident on a billing database.

1. Request: read-only access to the billing PostgreSQL database for two hours, with the incident number as the reason.
2. Approve: the named approver is notified and approves; higher-risk requests may need a second approver or step-up MFA.
3. Connect: the engineer connects through a proxy or gateway that injects the credential, so it never reaches their device, and the session is recorded.
4. Expire: when the two hours end, the grant is removed. Nobody has to remember to take it back.

SWOT PAM: the Access Hub.

How do you get to zero standing privileges in stages?

Nobody switches every account to ZSP in one change. A staged plan keeps production running and shows results early.

Stage 1: find standing access

List every account with elevated rights: directory admin groups and their nested members, local administrators, sudo rules, database roles, cloud roles and access keys, service accounts and vendor logins. Give each an owner. Expect to find more than the directory alone shows, because privilege also comes from local groups and nested membership.

Stage 2: take the passwords away

Move shared, admin and service credentials into a vault. People check out access rather than knowing passwords, and credentials rotate after use or on a schedule. Before you rotate anything, find the scripts, scheduled tasks and integrations that use it.

Stage 3: move the highest-impact systems to just-in-time

Start with the systems where an unauthorised change would hurt most: production databases, payment systems, domain controllers, cloud owner roles. Remove standing group membership and replace it with time-bound, approved grants. Route low-risk requests quickly so engineers do not look for workarounds.

Stage 4: extend to cloud and machine identities

Replace long-lived cloud keys with short-lived credentials. AWS documents that temporary security credentials “can be configured to last for anywhere from a few minutes to several hours” and, after they expire, “AWS no longer recognizes them or allows any kind of access.” For service accounts, issue credentials at run time where the platform supports it and vault and rotate the rest.

Stage 5: prove it and keep it

Record every request, approval, session and expiry on an audit trail that shows if it has been changed. Re-run the stage 1 discovery on a schedule to catch new standing access, and report the count of standing privileged accounts as the measure of progress.

ZSP readiness checklist

• Every privileged account, human and machine, is listed with an owner.
• No person knows the password of a shared admin or root account.
• Admin rights on production systems are granted per task with an expiry, not by group membership.
• Every grant records the requester, approver, reason, target and duration.
• Cloud administration uses short-lived credentials; no long-lived access keys for people.
• Privileged sessions run through a proxy or gateway and are recorded.
• Break-glass access is tested, alerted and reviewed after each use.
• Discovery runs on a schedule and new standing access is removed or justified.

How do SWOT PAM and SWOT Cloud PAM support zero standing privileges?

The SWOT platform covers each stage, as set out on the zero standing privileges solution page.

• Find standing access: SWOT Radar records the local admins, sudo and wheel members and SSH users on each host and follows nested AD groups down to five levels. SWOT DAM scores every database identity against its own 30-day baseline.
• Take the passwords away: the SWOT PAM Central Vault holds passwords, SSH keys, cloud keys and API tokens, encrypted with AES-256-GCM, and rotates them on a schedule or as soon as a credential is checked back in.
• Just-in-time access to servers and databases: engineers request a target, a duration and a reason, or ask the AI assistant in plain English. Approvers are notified in Slack, Microsoft Teams or email. The proxy injects the credential, each database session gets a temporary account revoked at disconnect, and the grant ends on its own. Break-glass overrides are logged and alerted at high priority.
• Cloud without standing keys: SWOT Cloud PAM brokers time-bound grants behind multi-stage approval into short-lived STS AssumeRole or Azure and GCP OAuth credentials, with no persistent keys. Deterministic risk scoring can require a second approver or step-up MFA, a revoked grant stops working within 60 seconds, and break-glass needs dual control.
• Prove it: SWOT PAM seals each audit event in a SHA-256 hash chain, and SWOT Cloud PAM records sessions on a hash chain anchored by a server key that clients never hold.

Next steps

Zero standing privileges removes the admin rights an attacker or insider could use between tasks, by granting access just in time and taking it back automatically. Get there in stages: find standing access, vault credentials, move the highest-impact systems to JIT, then extend to cloud and machine identities. See how SWOT PAM delivers zero standing privileges on your own systems, or book a demo.