The industry keeps calling identity the new perimeter. Attackers increasingly sign in with legitimate credentials rather than breaking in. The credential they most want is already approved and always on, with no expiry date. That's standing privilege: one compromised login becomes an instantly usable path across your systems.
Your business probably already has some, accumulated through privilege creep as people change roles without handing rights back. The fastest-growing slice isn't human: service accounts, API keys and AI agents outnumber people in most organisations and are rarely reviewed. Origin Energy learned how costly always-available access gets.
By the end you'll be able to draw clean lines between standing privilege, privileged access management (PAM) and just-in-time access, and see exactly where the exposure window lives. For the wider context, the Origin Energy breach shows what happens when always-available access is left unmanaged.
What is standing privilege and why do security teams consider it dangerous?
Standing privilege is elevated access held continuously and indefinitely by a human or machine identity, rather than granted on demand. The always-on part is what makes it dangerous.
Steal a standing credential and three things happen. The blast radius grows, because one login unlocks everything the identity could reach. Lateral movement gets easier, because the account already has the rights to hop from system to system. And there's no approval step: the credential is immediately actionable, with no request, justification or expiry date in the way. As IBM puts it, whoever steals the credentials inherits the permissions. That inheritance sits at the heart of the access risks behind the breach.
Standing privilege is also a standing breach of least privilege (PoLP): identities should hold only the permissions their current task needs. It accumulates through privilege creep. A domain admin account created for a migration two years ago still sits untouched, long after the project finished and the engineer moved on. That kind of access left standing is how orphaned accounts pile up.
The least-governed slice is non-human: service accounts, API keys and AI agents outnumber human users by an average of 45 to 1, reaching 144 to 1 in cloud-native environments, and one in twenty carries full administrative privileges.
Origin Energy shows what always-available access costs. The breach affected around 900,000 customers, and reporting traced it to a former Accenture employee in Manila, where Accenture runs Origin's call centres. Access that stayed on too long is what turned a single compromise into a breach of that scale.
Credential lifecycle management vs privileged access management: what's the difference?
Faced with a stack of always-on accounts, the natural first instinct is to manage them better, and that's where two disciplines come in. They answer different questions. Credential lifecycle management (the identity governance and administration, or IGA, discipline) governs whether an identity should exist and hold access at all, across the joiner-mover-leaver arc. PAM governs how privileged access is granted, brokered, monitored and recorded, focused on the riskiest accounts.
PAM is a specialised subset of identity and access management (IAM). IAM governs everyone; PAM applies tighter discipline to a high-risk few. Traditional access management was never built for privileged accounts: it doesn't vault credentials, broker sessions or record privileged activity, which is where the two diverge.
PAM's scope shows in its lifecycle: discovery, credential vaulting, privilege elevation, session brokering and monitoring, recording and auditing, then review and adaptation. It's a continuous operating discipline. The credential vault marks the mechanism: PAM tools rotate and vault credentials and broker delegated access, so secrets are never exposed at rest. CyberArk is the name most people associate with this market, but the tooling is only one part of the picture.
The connection to lifecycle: lifecycle failure leaves orphaned and unrevoked access behind, and that residue is what standing privilege exploits. Incomplete offboarding leaves orphaned accounts and dormant access. PAM brokers and monitors whatever access exists; offboarding and deprovisioning decide whether it should exist in the first place.
Just-in-time access vs standing privileges: why does the distinction matter?
Where PAM governs how privileged access is protected, just-in-time (JIT) access governs how long that access lasts. JIT grants time-limited, task-specific privilege on demand, then revokes it automatically when the work is done. It comes in two patterns: an ephemeral account created and destroyed per task, or temporary elevation layered onto an existing identity and then stripped back. Privilege becomes a transaction rather than a permanent state.
The distinction is temporal, and it shows in four ways. Duration: standing privilege is indefinite, JIT is time-boxed. Approval: standing privilege needs none, JIT needs a per-request justification. Auditability: standing privilege is thin, JIT is logged. Revocation: standing privilege is manual or never, JIT is automatic. The result is a smaller window for an attacker to work in, and no lingering access left behind when a task ends.
Keep the concepts apart. JIT is a mechanism; zero standing privileges (ZSP) is the outcome: no identity holds elevated access by default. JIT governs duration, while just-enough access (JEA) governs scope, so a user gets only the permissions a task needs; together they instantiate least privilege. And a timer isn't magic. As SGNL puts it, JIT without context is still a form of standing access, just with a timer attached. The aim is to shrink the exposure window; a timer reduces risk without eliminating it. That's the direction just-in-time access pushes you toward, by removing standing privilege rather than just protecting it.
Break-glass access is the deliberate, governed exception: emergency access that stays standing so responders can get back in when identity systems are down. It stays protected by vaults, MFA, rotation, monitoring and a documented escalation path. It's the one standing access you keep on purpose, governed rather than ignored.
Taken together, the pieces line up. Standing privilege is measured in blast radius times time. What matters is that it never expires, because a permanent entitlement stays usable however well it is protected. PAM brokers, monitors and records privileged access as a subset of the broader lifecycle discipline, but a vaulted standing credential is still standing. Gartner's distinction holds: vaulting and session management mitigate the risk of a privileged account existing, while removing the standing privilege shrinks the attack surface itself.
JIT turns privilege from an indefinite state into a time-boxed, task-scoped transaction with approval and automatic revocation. Zero standing privileges is the direction of travel, an outcome to approach rather than a switch to flip, with break-glass the one standing access you keep by design. The window closes only when privilege is borrowed for a task and revoked when it ends. Zoom out, and the goal is credential lifecycle management applied to privileged access: nothing holds more, or for longer, than the task requires.
Frequently Asked Questions
How does just-in-time access work in practice?
Just-in-time access works by turning privilege into a request rather than a permanent state. A user asks for elevated rights for a defined task, the request is approved and brokered through a vault or policy engine, and access is granted for a fixed window before being revoked automatically. Most implementations use one of two patterns: an ephemeral account created and destroyed on demand, or a temporary elevation layered onto an existing identity.
Does implementing PAM remove standing privilege?
No. PAM protects privileged access, it does not remove it. Vaulting credentials, brokering sessions and recording activity all reduce risk, but a vaulted account with always-on rights is still standing privilege with a better lock on it. PAM shrinks the blast radius of a stolen credential, whereas just-in-time access changes the duration of exposure. The two are complementary, not interchangeable.
Should service accounts and API keys use just-in-time access too?
Yes. Service accounts, API keys and AI agents are the fastest-growing and least-governed slice of standing privilege, so leaving them out undermines the whole model. Machines cannot request approval the way people can, which is why the practical approach is short-lived, automatically rotated credentials or dynamic secrets issued through a secrets manager, so the identity never holds a permanent key at all.
Can multi-factor authentication replace just-in-time access?
No. Multi-factor authentication strengthens how a credential is presented, not how long the underlying access lasts. An account that requires MFA but holds always-on rights is still standing privilege, and MFA can be bypassed through phishing or stolen session tokens. Just-in-time access addresses a different dimension entirely by capping the window of exposure and adding approval and automatic revocation, so the two controls solve different problems.
What is privilege creep, and how do you stop it?
Privilege creep is the gradual accumulation of access rights as people change roles, join projects or take on temporary duties, with old entitlements never revoked. Over time an account holds far more than its current job needs, widening the blast radius. You contain it with regular access reviews, a disciplined joiner-mover-leaver process, least privilege by default, and automated deprovisioning so that access expires rather than lingering.
How long should a just-in-time access session last?
There is no universal number, but the principle is to grant the shortest window that lets the task finish, then revoke automatically. Typical windows run from a few minutes to a few hours, sized to the work rather than to convenience. If a task runs long, the better approach is a fresh, re-approved extension than a generous default, because every extra minute of elevated access is extra exposure.
Is standing privilege only a risk for administrator accounts?
No. Standing privilege is defined by always-on, indefinite elevated access, not by the word administrator in a job title. It covers domain admins, but equally database owners, cloud roles, service accounts, third-party contractor links and break-glass accounts. Any identity that holds continuous rights beyond its current need is standing privilege, and the less visible ones are often the more dangerous because nobody is reviewing them.
How do break-glass accounts fit into a just-in-time model?
Break-glass accounts are the one exception a just-in-time model keeps deliberately, so responders can regain access when identity systems themselves are unavailable. They remain standing by design, but they are governed rather than ignored: credentials vaulted, MFA enforced, secrets rotated, every use alerted and logged, and a documented escalation path. The goal is not to eliminate break-glass but to make its use rare, controlled and fully auditable.
How do you find standing privilege that already exists in your environment?
Start with discovery: inventory every human and machine identity, then map the entitlements each one actually holds across systems. Correlate those entitlements against real usage to surface accounts with rights they never use and access that was never revoked. Prioritise by blast radius, focusing first on privileged accounts, service accounts and API keys, then work backwards from there to remove or time-box the standing access you find.
Does zero standing privilege mean deleting every permanent account?
No. Zero standing privilege means no identity holds continuous elevated access, not that permanent accounts disappear. Everyday, non-privileged accounts still exist, and people still need to do their jobs; what changes is that privileged rights are granted on demand, scoped to the task and revoked when it ends. Break-glass access is the deliberate exception. Treat zero standing privilege as a direction of travel and an outcome to approach, not a one-off switch you flip.
Do Australian security frameworks require just-in-time access?
Australian guidance increasingly points in this direction without always naming just-in-time access. The ACSC Essential Eight's restrict administrative privileges mitigation, and the Information Security Manual's emphasis on least privilege and privileged access management, both push toward removing always-on rights rather than merely protecting them. Frameworks rarely mandate a specific tool, but a shrinking exposure window is exactly the direction they reward.