Zero standing privileges, or ZSP, means that no account holds powerful access permanently. People and services request elevated rights for a specific task, receive them for a short time, and lose them automatically. The goal is that a stolen account has little to steal, because the power is rarely switched on.
Why do standing privileges cause trouble?
An administrator account that is always powerful is always valuable. If an attacker phishes it, they inherit everything it can do, at any hour. MITRE ATT&CK's Valid Accounts technique notes that adversaries use legitimate credentials for access, privilege escalation and persistence, and that overlapping permissions across local, domain and cloud accounts can let them move between systems and reach administrative access. Standing rights are what make that movement pay off.
They also build up. People change jobs and keep old rights. Service accounts get broad rights "to be safe". Reviews find the debris long after the risk existed.
How does ZSP relate to zero trust?
NIST SP 800-207 describes zero trust as moving defenses away from static, network based perimeters toward users, assets and resources, with no implicit trust granted because of location or ownership of a device. It says authentication and authorization are discrete functions performed before a session to a resource is established, and that protection centers on individual resources. CISA's Zero Trust Maturity Model points the same way, speaking of accurate, least privilege, per request access decisions.
ZSP is one way to carry that principle into privileged access: the decision is made per request, not once for the life of an account.
How does it work in practice?
The pattern has four steps.
- Request. A person asks for a specific role on a specific system, with a reason.
- Approve. A policy or a second person approves. Routine, low risk tasks can be approved automatically by rule.
- Grant. The system issues a time limited credential or role assignment.
- Expire. The access ends on its own, and the session is logged.
Most identity and cloud platforms now support time bound role assignments. Where they do not, a broker or vault can issue short lived credentials.
Constructed example: the database fix
An engineer needs to correct a bad record in a production database. In a standing model, the engineer already holds write access to production and uses it. In a ZSP model, the engineer requests a write role on that database for one hour, citing the ticket number. A manager approves from a phone. The role expires on schedule, and the log shows who changed what, under which ticket. If the engineer's laptop is compromised the next day, the attacker finds no live production rights.
The case is constructed, but the change is representative.
What are the hard parts?
Break glass. You still need a way in during an outage when the approval system is down. Keep a sealed emergency account, alert whenever it is used and review every use.
Service accounts and automation. Machines need rights too. Replace long lived keys with short lived tokens and narrow roles.
Friction. If approval takes an hour, people will route around it. Pre approve common tasks and make the request fast.
Discovery. You cannot remove rights you have not found. Start with an inventory of privileged roles.
As AI agents begin to call tools on a person's behalf, the same logic applies to them: give an agent only the access a task needs, for as long as it needs. Safeguard's agent identity and MCP Guardrail features are aimed at that case.
How to check or apply this
- List every account and role with administrative or production write access.
- Remove the ones nobody can justify.
- Choose the three most powerful roles and make them request based and time limited first.
- Set a short maximum duration, for example a few hours, and log every grant.
- Set up and test a break glass account with alerts.
- Replace long lived service credentials with short lived ones.
- Review grant logs monthly and tighten approvals where requests are routine.
Quick check
Is zero standing privileges the same as least privilege?
Related, not the same. Least privilege limits how much access an account has. Zero standing privileges also limits when it has it, by granting rights only for the duration of a task.
Do all users need to move to ZSP?
No. Start with administrators and production access, where a stolen account does the most damage, and extend as the process proves workable.
Sources
- NIST SP 800-207, Zero Trust Architecture
- CISA, Zero Trust Maturity Model
- MITRE ATT&CK, Valid Accounts (T1078)
Last reviewed: 18 October 2026.
