Ask any security leader whether they believe in least privilege and you will get an immediate yes. It is the most agreed-upon idea in the field. Give every person, service, and process exactly the access it needs to do its job, and nothing more. The logic is airtight. A credential that cannot reach your customer database cannot leak it. An engineer who cannot touch production cannot break it at 2 a.m. by accident. The blast radius of any single compromise shrinks to whatever that one identity was allowed to do.
And yet, in practice, least privilege is the principle most companies endorse and least companies actually run. I have walked into organizations with a beautiful access control policy on the intranet and a reality where half the engineering team has admin on everything because that was faster than filing tickets. The gap between the slide and the system is where breaches live. So I want to talk about what it actually takes to enforce least privilege without grinding the company to a halt, because that second clause is the entire problem.
Why least privilege fails the moment it gets inconvenient
Least privilege done badly is indistinguishable from sabotage. If your access control model means a salesperson waits three days to see an account they are trying to close, or an on-call engineer cannot reach the logs during an incident, people will route around you. They will share credentials. They will request the broadest role that clears the request, because nobody wants to come back next week and ask again. They will keep a personal copy of the data on a laptop so they never have to deal with the gate. Every one of those workarounds is a worse outcome than the over-permission you were trying to prevent, and you created it.
This is the central tension. Security and friction are not the same thing, but lazy security implementations make them feel identical. The teams that get least privilege right understand that the goal is not to say no more often. The goal is to make the right level of access the path of least resistance, so that nobody is ever tempted to grab more than they need. When the correct door is also the easiest door, permissions stop sprawling on their own.
The failure mode I see most often is the static role. A company defines twelve roles, maps everyone into one, and considers the job done. Within a year the roles have drifted into uselessness. People changed teams but kept old access. New responsibilities got bolted onto existing roles because editing the role was easier than creating a new one. The "marketing" role now grants reach into finance because one marketer once needed a report. Static roles decay. Access control is not a configuration you set once. It is a living system that has to grant, review, and revoke on a continuous basis.
Start with identity, because everything hangs off it
You cannot enforce least privilege if you do not know who is asking. That sounds obvious, and it is precisely the step companies skip. Before you argue about which permissions a role should carry, you need one authoritative source of identity that every system trusts, and you need every action in the company to be attributable to a specific human or a specific service. If two engineers share a login, you have already lost. You cannot grant least privilege to a person you cannot distinguish from another person.
So the first investment is consolidation of identity. Single sign-on for every internal tool, no exceptions, no "this one vendor does not support it so we use a shared password." Service accounts that are named, owned, and tied to a specific workload rather than a pool of generic credentials passed around in a config file. Multi-factor authentication that is phishing resistant, because a password plus a code an attacker can socially engineer is not real assurance. Once identity is solid, every later decision becomes possible. Until it is solid, every later decision is theater.
Strong identity also changes the economics of access. When every action is attributable, you can grant more freely in low-risk areas because you have a clean audit trail if something goes wrong. Attribution is what lets you relax where it is safe and tighten where it is not. Companies that cannot attribute end up applying the same heavy gate everywhere, which is exactly how they teach their own people to resent security.
Grant just enough, just in time
The most useful shift in modern access control is the move from standing access to just-in-time access. Standing access means a permission sits attached to an identity permanently, waiting to be used or abused. Just-in-time access means the permission does not exist until the moment it is needed, is scoped to a specific task, and expires on its own.
This is the technique that finally makes least privilege practical at scale. An engineer who needs to debug a production issue requests a temporary access grant, states why, and receives it for the next two hours. The request is logged, sometimes approved by a peer in a single click, and the access vanishes when the timer ends. Nobody has to remember to revoke it. The default state of the system is low privilege, and elevation is a brief, deliberate, recorded event rather than a permanent grant that everyone forgets about.
I am a strong believer in making elevation fast and revocation automatic. If the request takes thirty seconds and a teammate approves it from their phone, people will happily operate at low privilege all day and raise their access only when they genuinely need to. If the request takes three days, you have recreated the exact friction that drives people to hoard permissions. Speed of legitimate access is a security control, not a convenience. Build it like one.
- Default everyone to the lowest useful level of access for their role.
- Make elevation a fast, logged, time-bound request rather than a permanent change.
- Expire access automatically so that revocation is never a task someone has to remember.
- Require a reason on every elevation, because the reason is the audit trail you will want later.
Revocation is the half nobody finishes
Granting access is easy. Every company is good at it, because the pressure to grant is immediate and the person asking is right in front of you. Taking access back is where least privilege quietly dies. Someone changes teams and keeps their old permissions. A contractor finishes a project and their account stays active for months. An integration is decommissioned but its API token still works. The accumulation of access that should have been removed is the single largest source of risk in most environments, and it is invisible because nothing breaks. The over-permission just sits there until the day it is exploited.
The fix is to make revocation a default behavior of the system rather than a human chore. Time-bound grants expire on their own. Access tied to a project ends when the project closes. When someone leaves a team, their team-scoped permissions leave with them automatically, driven by the same identity source that provisioned them. And on a regular cadence, every owner of a sensitive resource confirms who still has access and why. The review should take minutes, not days, which means the tooling has to present a clean, current picture rather than a raw permissions dump nobody can read.
We built access controls into Atlas with exactly this philosophy. Roles and permissions in Atlas are scoped, auditable, and reviewable, so that an administrator can see at a glance who can reach what and walk that back without filing a ticket with anyone. The point is not that we have a permissions screen. Everyone has a permissions screen. The point is that the screen makes the right answer easy to find and easy to enforce.
Segment the blast radius before you need to
Least privilege is one layer of a larger idea, which is that you should assume any single identity will eventually be compromised and design so that the damage is bounded when it happens. This is why permissions should not just be small, they should be segmented. A credential that can read one customer's data should not be able to read all of them. A service that needs to write to a queue should not also be able to delete the queue. The question to ask of every grant is not only "does this identity need this" but "if this identity were taken over tomorrow, what is the worst it could do," and then you shrink that worst case until it is survivable.
Segmentation is what turns a catastrophic breach into a contained incident. The breaches that make headlines are almost never the result of a single clever exploit. They are the result of an attacker getting one foothold and then discovering that the foothold had access to everything, because nobody had bounded it. Strong segmentation means the attacker who phishes one employee gets one employee's narrow slice and finds every other door locked. That is the entire return on least privilege, and you only get it if you did the unglamorous work of scoping every grant down before anything went wrong.
Make the secure path the easy path
If I could leave a security team with one operating principle, it would be this. People are not the enemy of your access control program. Friction is. Every time the secure way to do something is harder than the insecure way, you are training your own organization to undermine you, and they will, with the best of intentions, because they are trying to get their jobs done. The whole craft of least privilege is making the correct level of access fast to get, automatic to lose, and clear to audit, so that operating securely is simply the most convenient way to work.
Get that right and least privilege stops being a policy you have to police. It becomes the shape of the system, the default everyone falls into without thinking about it. That is the version that survives contact with a real company under real pressure, and it is the only version worth building.