Everyone agrees with least privilege. It's in every security framework, every audit checklist, every vendor deck. And almost nobody has it.
That gap is worth sitting with for a second, because it tells you something. When a principle is universally endorsed and rarely implemented, the problem usually isn't that people don't understand it. It's that the principle is easy to state and genuinely hard to do - and most advice skips straight past the hard part.
So let's not do that. Here's what least privilege actually means, why it keeps failing, and a sequence that works without taking production down on a Tuesday afternoon.
The principle is simple: give every user, service and process exactly the permissions it needs to do its job, for exactly as long as it needs them, and nothing more.
The word doing the heavy lifting is needs. Not "might plausibly need." Not "needed once in 2023." Not "needs, because they asked and it was easier to say yes." Actual, demonstrable need - which means you have to know what people are really doing with their access, not what they told you they'd do with it.
That's the part that makes it hard. Least privilege isn't a policy decision you make once. It's a measurement problem you have to keep solving, because roles change, projects end, and people move on while their permissions stay behind.
Four reasons, and they're structural rather than technical.
Someone can't ship because they lack access. That's a blocked engineer, a Slack message with three people tagged, and pressure to fix it now. Nobody has ever sent an urgent message asking to have their permissions reduced.
So access accrues in one direction. Every grant is a small, individually reasonable decision, and the sum of them is an estate where half your engineers can reach production.
If you revoke something and nothing breaks, no one notices. If you revoke something and a deployment fails, you own that. The incentives point at leaving things alone — which is exactly why least privilege needs to be somebody's explicit job with a metric attached, rather than everyone's good intention.
The fastest way to onboard someone is to copy the permissions of a person doing a similar job. It's also how one over-provisioned account becomes a template, then a department standard, then the way things have always been done. Privilege creep by inheritance.
The argument for keeping access is always concrete and immediate - what if there's an incident at 3am and they can't get in? The argument for removing it is abstract and probabilistic. Abstract loses, every time, unless you've decided in advance how you'll answer it.
If you only fix one thing, fix this.
Standing privileged access is elevated access that exists permanently - sitting in the account whether or not it's being used, whether or not anyone's at their desk, whether or not the credential has been stolen. Most privileged access in most organizations is standing.
Why it matters more than the raw permission count: a compromised credential with standing admin is immediately useful to an attacker. No escalation needed, no waiting for an approval window, no noisy privilege-request trail. They log in and they're already an administrator.
The alternative is just-in-time elevation. Nobody holds admin by default. When they need it, they request it, get it for a bounded window, and it expires on its own. A stolen credential is then worth much less - it's a standard account until someone approves an elevation, and that approval is a signal you can alert on.
Full elimination isn't realistic. Break-glass accounts need to work during an outage of the very system that would approve the request. Some service accounts genuinely need persistent access. That's fine - the goal isn't zero, it's knowing your number and driving it down deliberately. What proportion of your privileged access is standing? Most teams have never calculated it, and the calculation itself is usually the wake-up call.
These get used interchangeably and they're not the same thing.
Worth being precise about this in vendor conversations. "We support RBAC" is not the same claim as "we help you achieve least privilege." Zero trust for cloud applications covers the verification side.
This is the sequence that works. The order matters more than the tooling.
Compare granted permissions against permissions actually exercised over a real window - ninety days is a reasonable default. The gap between the two is your reduction target, and it's usually alarming. Users with production admin who haven't used it once. Accounts holding permissions in systems they've never opened.
Don't skip this to move faster. Cutting without usage data is how you break a quarterly job that runs on the account nobody remembered.
Accounts with no accountable human owner are the easiest wins and the highest risk. Nobody will defend them in a review because nobody knows what they're for. Work these first - you'll build momentum and reduce genuine exposure before you touch anything anyone cares about.
Identity risk management covers how to build the inventory and rank findings, which is the prerequisite for all of this.
Super-admin → admin → operator is three steps, and each one is defensible and reversible. Super-admin → read-only is one step that will be reverted within a day and will cost you credibility for the next attempt.
This is the highest-value step and the one most likely to break something, which is why it goes late. Do it one system at a time. Trace what calls each privileged account before you take its permanence away. Pipelines and scheduled jobs are where the surprises live.
Here's the failure mode nobody plans for: you implement beautiful JIT elevation, it takes fifteen minutes and two approvals, and within a month engineers have found workarounds - a shared account, a long-lived token, a service account with standing admin used as a back door. You've now got shadow standing privilege, which is worse than the visible kind because it's not in your inventory.
If elevation isn't close to frictionless for routine work, least privilege will lose. Fast approval isn't a nice-to-have; it's the thing that determines whether the control survives contact with real work.
Some access stays. That's fine and expected. What matters is that the exception is written down with a justification and a review date, so next quarter's reviewer inherits the reasoning instead of guessing. Undocumented exceptions are what auditors find; documented ones are what they accept.
Four numbers tell you most of the story:
That last one is the metric most programmes don't track and most need to. It's the difference between a control people use and a control people evade.
Josys shows granted entitlements next to actual usage across your SaaS estate, so the permission-to-usage gap is visible rather than theoretical - including in applications that were never enrolled in a PAM tool. Entitlements are tied to identity and employment state, so privilege from a previous role gets flagged when the role changes rather than at the next review cycle.
Have a look at the identity security and risk page, or book a demo and we'll walk through your own estate.
Least privilege access means every user, service and process holds only the permissions it needs to do its job, for only as long as it needs them. The principle is straightforward; the difficulty is proving what's actually needed, which requires comparing granted permissions against real usage rather than relying on what people say they need.
It's the security principle that access should be limited to the minimum necessary for a task. It appears in most compliance frameworks including SOC 2, ISO 27001 and PCI-DSS. In practice it applies to human users, service accounts, applications and automated processes alike - service accounts are usually where it's most neglected.
Standing privileged access is elevated access that exists permanently, whether or not it's in use. It's the main structural risk in most privileged estates, because a compromised credential with standing admin is immediately useful to an attacker - no escalation required. The alternative is just-in-time elevation, where access is granted on request and expires automatically.
Zero standing privilege is the goal state where no account holds permanent elevated access - all privilege is granted on request and expires. Complete elimination is rarely achievable, since break-glass accounts and some service accounts need persistence, so most organizations treat the standing-privilege proportion as a metric to reduce rather than a binary to reach.
Least privilege governs how much access an identity holds. Zero trust governs whether to trust a request at all, verifying every time regardless of network location. They're complementary: verifying access to an over-permissioned account still grants too much, so least privilege is what makes zero trust worth doing.
Measure granted versus used permissions first, start with unowned accounts, reduce in stages rather than all at once, convert standing access to just-in-time one system at a time, and make elevation fast enough that people don't work around it. That last point matters most - slow elevation produces shadow standing privilege, which is worse than the visible kind.
Mostly three things: permissions granted for temporary needs and never revoked, roles cloned from over-provisioned accounts, and role changes where new access is added but old access isn't removed. All three are one-directional - access accumulates because granting is urgent and revoking never is.
