Everybody in IT can define least privilege. Give every identity the minimum access needed to do its job, and no more. It appears in every security policy, every framework, and every interview answer.
Almost nobody implements it properly. That is not because the principle is hard to understand. It is because the principle is free and the operation of it is not.
Standing access is convenient. Just-in-time access is friction. Friction gets removed by whoever is under the most delivery pressure, and that is usually not the security team.
Standing access is the default and the problem
Standing access means the permission is there all the time, whether it is being used or not. Somebody is a global administrator on a Tuesday afternoon in June when they last did anything administrative in March.
The exposure is not the person. It is the window. Every hour that a permission exists unused is an hour in which a compromised session, a phished token or a badly scoped agent can use it. Most access in most organisations is standing, and most of it is dormant most of the time.
Just-in-time flips it. The permission is not held, it is requested, granted for a defined period, and expires without anyone having to remember to remove it. The access still exists when it is needed. It just does not sit there when it is not.
In the Microsoft world, Privileged Identity Management is the mechanism. What it actually buys you is not really the elevation workflow, it is the fact that elevation becomes an event. Something happened, it is logged, somebody approved it, and it ended. Standing access produces no events at all, which is precisely why it is invisible in every report you run.
Scope is the thing people get wrong
When least privilege fails in practice, it usually fails on scope rather than on role.
The pattern is familiar. Someone needs to manage one resource. Rather than assign the role at that resource, it gets assigned at the resource group, because that is the level the console was open at. Or at the subscription, because that is where the existing assignment already lived and adding to it was one click. The role is correct. The blast radius is off by two orders of magnitude.
Nobody notices, because the person’s day job works exactly as expected either way. Correct scope and wildly excessive scope are indistinguishable from the perspective of the person doing the work, which is why this error survives.
The Azure RBAC guidance puts it plainly: assign at the narrowest scope that gets the job done. Worth reading properly, because the guidance is clear and the practice usually is not.
Over-granular is also a failure
The overcorrection deserves a mention, because organisations that take least privilege seriously often land here.
You can decompose access so finely that you end up with hundreds of custom roles, each granting a handful of permissions, each created for one situation and never reused. This looks rigorous. It is actually unmanageable, and it fails in a specific way: nobody can tell what any given person can do without running a report, so nobody ever checks, so the model stops being reviewed.
A permission model that nobody can hold in their head is not a permission model, it is a database. The target is the smallest number of roles that cleanly describe what people in your organisation actually do. Fewer roles that are well understood beat many roles that are theoretically precise.
The identities that are not people
Every point above applies to service principals, managed identities, application registrations and agents, and it applies more severely.
Machine identities get over-privileged more often than human ones, for a reason that is entirely understandable. When an integration does not work, the fastest way to find out whether it is a permissions problem is to grant more permissions. That is a perfectly sensible diagnostic step. It becomes a permanent state because once the thing works, nobody goes back and narrows it, and there is no user to complain that they have too much access.
They also outnumber the humans, and the gap widens every year. Every service, container, scheduled job and agent is an identity. I have written about why that makes identity the actual security boundary now, and the short version is that the wall you defend on is mostly machinery.
An over-privileged agent is a different shape of problem to an over-privileged person, because a person’s curiosity is bounded by their attention and their working day, and an agent’s is bounded by nothing at all.
Where to practise this without an enterprise estate
Least privilege is one of those topics where the homelab version teaches better than the enterprise version, because you can see the whole system at once.
Start with sudo, because most people run everything as root in their lab and never think about it. Configure a user with sudo rights to specific commands rather than blanket access, and you will immediately feel the friction that causes organisations to over-grant in the first place. That friction is the entire lesson. File permissions and ownership are the same concept one layer down.
Then go and look at your Docker socket, which is the cleanest example of scope error you will ever find. Anyone in the docker group can start a container that mounts the host filesystem, so the permission you granted looks narrow and is in fact total. Most homelabs hand this out without a second thought, mine included for longer than I would like to admit.
If you run a cluster, Kubernetes RBAC is worth an evening too. Roles versus cluster roles is the same resource-versus-subscription scope question you will meet in Azure, except you can hold the whole system in your head while you think about it.
None of that costs anything, and all of it produces the specific instinct you need: asking “at what scope?” as a reflex rather than as an afterthought.
Why this is suddenly load-bearing
Least privilege has always been the right answer and has always been quietly deprioritised, because the cost of getting it wrong was theoretical for most organisations most of the time.
Excessive permissions did not cause incidents on their own. They sat there, invisible, waiting for something to combine with. What has changed is that agents now traverse everything an identity can reach and return it in response to a plain English question. Excessive scope stops being latent and starts being enumerable.
And because access accumulates through a mover process that grants but does not remove, the scope problem compounds rather than staying still.
The principle did not change. The margin for ignoring it did.
The rest of this series:
- Agent Access and the Permissions You Forgot You Granted
- Joiners, Movers and Leavers: the mover leg is where your permission model rots
- The Permissions Work to Do Before You Deploy Copilot
ReadTheManual is run, written and curated by Eric Lonsdale.
Eric has over 20 years of professional experience in IT infrastructure, cloud architecture, and cybersecurity, but started with PCs long before that.
He built his first machine from parts bought off tables at the local college campus, hoping they worked. He learned on BBC Micros and Atari units in the early 90s, and has built almost every PC he’s used between 1995 and now.
From helpdesk to infrastructure architect, Eric has worked across enterprise datacentres, Azure environments, and security operations. He’s managed teams, trained engineers, and spent two decades solving the problems this site teaches you to solve.
ReadTheManual exists because Eric believes the best way to learn IT is to build things, break things, and actually read the manual. Every guide on this site runs on infrastructure he owns and maintains.
Enjoyed this guide?
New articles on Linux, homelab, cloud, and automation every 2 days. No spam, unsubscribe anytime.
