Privileged access has always been the crown jewel for attackers.
With the right credentials or an elevated session, defenses fall quickly, ransomware spreads faster, sensitive data is siphoned, and systems go offline, stopping sales and service delivery.
That's why Zero Standing Privilege (ZSP) has become a guiding principle in modern identity security: the idea that no privileged account should ever sit idle, waiting to be misused.
... most implementations of privileged access still leave cracks on the surface
The promise of ZSP is compelling. However, most implementations of privileged access still leave cracks on the surface. At best, they reduce risk. At worst, they give organizations a false sense of security while attackers quietly exploit residual standing privileges.
This debate is especially sharp today, as identity-centric approaches promise "agentless" privilege elevation through the identity provider (IdP). Despite the marketing gloss that suggests a holy grail of agentless control, these models still hinge on standing privileged roles and static directory accounts.
By contrast, agent-based Privilege Elevation and Delegation Management (PEDM) goes further, enforcing elevation directly at the endpoint or server, and closing gaps that agentless solutions leave behind.
How does privilege elevation usually work?
It helps to trace how privilege elevation has evolved to understand why agentless approaches fail. Each step improved control, but left behind exploitable standing privileges.
Local privileged accounts
Every Windows machine comes with a built-in local Administrator account. Linux has root. In many environments, those accounts remain enabled for login. Even if passwords are rotated regularly, these credentials are permanently usable ways into the system. Attackers know this.
According to Verizon's 2024 DBIR, nearly 40% of breaches involve compromised credentials, making credential theft one of the most common tactics used for lateral movement.
Active Directory groups and sudoers
A common "step up" is to assign admins to domain groups (like "Administrators" in Active Directory) or to sudoers on Linux. It's convenient, but risky: those memberships confer standing privileges across systems. A single stolen token or password can deliver broad, domain-wide reach.
On Linux, the problem is compounded by the fact that each server has its own local /etc/sudoers file. There's no native mechanism to manage or synchronize sudoers entries across servers, so permissions can drift and inconsistencies can creep in. Some systems may have carefully restricted sudoers configurations, while others quietly grant near-unlimited root privileges.
This lack of centralized control increases the risk of misconfiguration, weakens accountability, and makes compliance audits far more difficult.
Password vaults
Credential vaults were designed to improve the situation. They are indispensable tools that provide secure storage, automated rotation, secure remote access, audit trails, governance, and safe sharing of sensitive accounts. Used correctly, they solve multiple problems.
But the key is how they are used. Vaults cannot delete operating system superuser accounts; they can only rotate and protect them. Standing privilege persists if those vaulted accounts are still available for routine logins.
Best practice is to vault and rotate superuser credentials, restrict their use to break-glass scenarios only, eliminate admin group memberships and shadow accounts, and require admins to log in with unique, individual low-privilege accounts, then elevate specific tasks just-in-time (JIT).
Another challenge is that superuser accounts like Administrator or root are inherently shared. Even if a vault rotates the password, activities performed with those accounts can't be easily tied back to a single individual. This is why best practice is for administrators to log in with unique, accountable identities and use the vault only for break-glass situations.
Vaults remain essential in this architecture, but vaulting alone does not equal ZSP. Gartner's guidance on Zero Standing Privilege makes this clear: privileged accounts that remain enabled, even when vaulted, still represent residual risk. True ZSP combines vaulting with just-in-time, host-level elevation and unique, accountable identities.
The latest wave of privileged access solutions, including Axiom Security, acquired by Okta, shifts elevation into the identity provider (IdP). Users request elevation, and the IdP temporarily adds them to a privileged role or group. When the time window expires, the role is revoked.
On the surface, this looks like Zero Standing Privilege. In practice, gaps remain:
- Privileged roles in the IdP always exist, permanently enabled and tied to downstream systems. Because these roles are shared by design, the activity performed under them is more challenging to attribute to a single individual, weakening accountability.
- Once elevated, the entire session runs with admin rights.
- IdP compromise exposes all privileged access paths.
- Servers cannot distinguish legitimate IdP brokers from attackers replaying stolen credentials.
While Axiom and similar IdP-centric solutions emphasize their ability to grant just-in-time access to cloud-native resources such as AWS, GCP, Azure, SaaS apps, and databases, the underlying weaknesses are the same as with server access.
Pre-defined roles and groups must still exist, privileges are typically assigned at the session level rather than scoped to individual actions, and enforcement depends on the IdP rather than the resource itself. For clarity, this blog focuses on the server use case, but the same risks extend across both servers and cloud platforms.
The impact of agentless elevation
Agentless or IdP-centric models reduce some risks, but they introduce others that are harder to control. Standing privileged roles persist in the directory or IdP, meaning there is always a target for attackers. Once elevated, an administrator's session typically runs with full rights, creating a window of opportunity for malware or lateral movement.
These models also turn the IdP into a single point of failure: if it is compromised, every privileged access path downstream is exposed at once. And because servers lack host-level validation, they cannot distinguish between a legitimate IdP broker and an attacker replaying stolen credentials.
The result is a model of "less privilege," not "zero privilege."
Agent-based PEDM pushes enforcement down to the server or endpoint itself:
Privileged accounts disabled, not deleted
Built-in accounts like root or Administrator remain in the OS but can be disabled for routine logins. They are vaulted, rotated, and reserved strictly for emergencies ( such as Linux single-user mode) under tightly controlled, audited, break-glass conditions. Day-to-day administration happens via individual, accountable, low-privilege accounts.
Elevation at the process level
The agent elevates only the authorized process, script, or command. Everything else in the user's session stays at normal user rights. If you run an installer, only that installer is elevated. If you restart a service, only that service is elevated—no blanket session-wide admin rights.
Trusted agent with platform policies
The agent is enrolled with the Delinea platform, establishing a trust relationship. The agent enforces centrally defined policies locally, distinguishing legitimate elevation requests from suspicious ones. A privileged login request might be from a valid IdP or platform workflow or an attacker replaying stolen credentials. The agent provides the host with the ability to tell friend from foe.
Local MFA enforcement
Unlike agentless models, the agent can enforce policies that require MFA directly at the server, both on login and on each elevation event. This ensures compliance with standards like PCI DSS 4.0.1, which requires MFA for all access to systems within the Cardholder Data Environment (requirements 8.4.1–8.4.3). These controls are intended to protect access to the system components, which is stronger than relying only on MFA checks at an upstream IdP or vault.
Analysts like Gartner have echoed this point, emphasizing in its 2025 Market Guide for User Authentication that modern authentication cannot stop at the IdP or VPN. Their guidance underscores that privileged accounts remain exposed if MFA is enforced only at those upstream points, and that stronger models validate MFA as close as possible to the resource or host where privileged actions occur.
Privileges vanish instantly
With agent-based PEDM, privileges exist only for the action being executed, only for as long as needed, and are automatically revoked immediately after. There are no permanent standing accounts and no lingering roles.
By contrast, in many agentless/IdP-centric implementations (including some promoted under the JIT model), elevation often involves adding a privileged identity or group membership (usually full administrator privileges) at least for the duration of a session. While some of that access may be scoped, many systems still grant broad rights when elevated, which increases exposure. Because the elevated identity often remains active for that session, there's a window of opportunity for misuse or lateral movement.
Centralized sudoers management with Server Suite
On Linux and Unix, managing /etc/sudoers files server-by-server creates drift, inconsistency, and compliance headaches. Delinea Server Suite solves this by centralizing sudoers management through Active Directory, importing local sudo policies, and distributing a single authoritative configuration across the environment.
Beyond eliminating drift, Server Suite adds enhancements such as RBAC, JIT/JEA enforcement, MFA, detailed auditing, and Delinea's patented Zone technology that improves on the native sudoers model while reducing risk.
Comparison: Agentless vs. agent-based
| Feature | Agentless / IdP-Centric (e.g., Axiom) |
Agent-Based PEDM |
| Privileged roles/accounts | Always exist in IdP/directory | Local accounts disabled; vaulted for break-glass only |
| Elevation scope | Session-wide during elevation window | Scoped to specific process, script, or command |
| MFA enforcement | At IdP/session initiation only | At server login and on each elevation |
| Local validation | Limited; server cannot distinguish IdP vs. attacker | Strong; agent enforces trusted policies locally |
| Single point of failure | IdP compromise exposes all access paths | Distributed enforcement across endpoints |
| ZSP alignment | Reduces risk but leaves standing roles | Closer to true ZSP |
Analyst and industry validation
Industry authorities consistently emphasize the importance of eliminating standing privileges and enforcing controls locally.
Analysts such as Gartner highlight that standing privileges remain a high-risk vector even when managed through traditional PAM or IdP workflows and that MFA is most effective when applied at the resource or host itself. Compliance frameworks like PCI DSS 4.0 echo this direction by requiring MFA for access to system components, underscoring that IdP-only checks are insufficient.
These perspectives validate the agent-based PEDM model: privileges must not linger in standing form. To achieve the true intent of Zero Standing Privilege, they should be enforced directly at the system level.
Ultimately, these perspectives point to a clear destination: Zero Standing Privilege is not just a philosophy, but a specific technical state that organizations can measure themselves against.
My closing thoughts
Zero Standing Privilege is a precise technical state: no routine privileged logins, no session-wide admin elevation for malware to hijack, and privileges granted only for specific, approved actions before being revoked instantly.
Identity-centric, agentless models provide improvements but leave residual standing roles and session-wide risks. Agent-based PEDM brings the industry closer to the true intent of ZSP: privileged accounts disabled for logins, granular and temporary elevation, and servers that enforce who can do what, when, and how.
Only agent-based PEDM eliminates session-wide standing privilege and allows servers to defend themselves. That's the difference between saying "we've reduced privilege" and proving "we've achieved Zero Standing Privilege."
FREE EBOOK
Servers are targeted by cybercriminals looking to exploit weaknesses in your server security
