Ask a security team a simple question: how many privileged accounts in your environment could cause material damage right now, at this moment, without anyone approving anything?
Few organisations can answer with precision. Most suspect the number is considerably higher than it should be. Hundreds of standing administrative accounts. Service accounts whose passwords predate half the engineering team. SSH keys duplicated across servers without a clear owner. Each one is an open door that requires no effort to walk through, only the credentials to do so.
That is standing privilege, and it is the largest reducible attack surface in most enterprise environments.
Why standing privilege is the root problem
Examine the significant breaches of the past five years and a consistent pattern emerges. The attacker did not need a zero-day exploit or nation-state tooling. They needed a credential that already existed before they arrived. An account that was always on, always privileged, always available.
Attackers increasingly do not break in. They authenticate.
This reframes the problem. If the credential itself is the attack surface, the objective is not to protect it more effectively. The objective is to ensure it does not exist until the moment it is legitimately required, and ceases to exist the moment it is not.
Storing credentials is not the same as reducing them
Traditional privileged access management established an important principle: credentials belong somewhere controlled and auditable. That principle remains sound.
The limitation is what came after it. Vaulting manages privileged access. It does not reduce the quantity of privileged access in existence. The accounts remain. The entitlements remain standing. What has been added is a secure repository for keys that continue to work whether or not anyone is legitimately using them.
The practical consequences are familiar to anyone who has run a large deployment. Extended rollout timelines. Engineers routing around checkout processes that take longer than the underlying task. Session recordings retained but rarely reviewed. Compliance evidence produced, with the underlying exposure largely unchanged.
Eliminating standing privilege is not a rejection of that foundation. It is the step the model never took.
What elimination actually requires
Moving from managed privilege to eliminated privilege rests on three operational commitments.
Privileges are created on request, scoped to the task, and expire automatically. Access is provisioned for the specific work at hand and revoked on completion or expiry. There are no cleanup scripts to maintain and no orphaned administrative accounts accumulating over time. Nothing persists to be discovered, stolen, or inherited.
Approval occurs where the work occurs. A request that takes thirty seconds to fulfil should be approved in thirty seconds, or auto-approved by policy where the risk profile permits it. Controls that impose disproportionate friction are the controls engineers find ways around, and a bypassed control provides no protection at all.
Sessions are evaluated for risk, not merely recorded. A recording reviewed after an incident is evidence for the post-mortem. Risk assessment applied before and during a session is prevention. The distinction matters most in exactly the scenarios where recordings are consulted.
Taken together, these turn zero standing privilege from an aspiration into a design constraint that every other capability has to satisfy.
The exposure extends well beyond human users
If standing privilege presents risk when a person holds the credential, the same logic applies with greater force to everything else holding credentials.
Service accounts operating with unchanged passwords for years. SSH keys propagated across infrastructure without lifecycle management. Automation and scripts running with broad, persistent entitlements that have not been reviewed since deployment. In most enterprises, machine identities now outnumber human identities by an order of magnitude, and each one provisioned under the traditional model represents another standing entitlement that no one is actively supervising.
These identities do not observe working hours and do not recognise anomalous conditions. A script will execute a destructive command at 3 a.m. with precisely the same reliability it executes a routine one at 3 p.m. Granting it standing privilege embeds a persistent liability directly into the infrastructure.
Legacy tooling offers a limited answer here, largely because it was designed for a period when a privileged user meant a person at a keyboard working a defined shift.
The correct approach is consistent across identity types, human and machine alike: begin from zero, request what is required, receive precisely that, and lose it when the work concludes. Applied properly, this extends to the command level, with individual privileged operations assessed for risk before they execute rather than reviewed after the fact.
Where this is heading
Three developments appear likely over the next several years.
The vault becomes infrastructure rather than product. Secure storage is now table stakes. Differentiation shifts to real-time decisions about whether a given identity should be performing a given action at a given moment.
Machine identity governance reaches theboard agenda. The first widely reported breach traced to a forgotten service account or an over-privileged key with standing access will acceleratethis considerably.
Access control and detection converge. Access decisions informed by live risk signals, and risk signals informed by access context. Two product categories addressing one underlying problem.
The organisations that make the most progress will not be those with the longest feature inventories. They will be those whose controls engineers are willing to use, because access control that works against builders is eventually circumvented.
A practical starting point
Standing privilege is measurable, which makes it manageable. Three questions provide a useful baseline:
- How many accounts in the environment hold privileged entitlements that are active right now, independent of any current task?
- Of those, how many are machine identities, and when was each last reviewed?
- For any given privileged action, how long does it take an engineer to obtain approved access through the sanctioned path?
The first two quantify the exposure. The third predicts whether controls will be followed or bypassed. Organisations that improve all three simultaneously are the ones genuinely reducing risk rather than documenting it.
If counting standing privileged accounts while reading this produced an uncomfortable number, that is a reasonable place to begin. RankEZ is built to close the gap between that number and zero.