Home / Knowledge hub / Least privilege
Knowledge hub
Least privilege
Giving every person and service the minimum access the job requires.
What it means
Least privilege gives every person, service and process the access its work requires and nothing spare. The developer who needs to read logs gets read access to logs, not administrator rights on the server that happens to hold them.
OWASP describes it as assigning only the minimum privileges needed to do the job, applied across peers and up the hierarchy alike. Software counts as much as people. A service that reads one table should hold a credential that can only read that table.
Why it matters
It does not prevent compromise. It decides what compromise costs. The same stolen password is a contained nuisance or a company-wide incident, depending on what that account could reach. You made that call months earlier, on the day you granted the access.
Erosion is the real enemy. People change teams and keep old rights. Temporary elevation for a Friday deployment never comes back. A service gets broad permissions during debugging and nobody narrows them afterwards. AWS names the anti-pattern directly: infrequent reviews lead to permissions creep.
How it shows up
The quick test is uncomfortable. Pick an account at random, ask what it can reach, then ask who would notice if somebody used it at three in the morning.
Practical checks: leavers removed rather than disabled, role changes that subtract as well as add, service accounts scoped per service. Then database users that cannot drop tables, cloud roles without wildcards, and reviews often enough that somebody reads the list properly. Inside an application the equivalent is every role tested against every resource.
Questions people ask
Least privilege, answered
Will least privilege slow developers down?
Badly implemented, yes. A ticket queue for every permission request creates friction that people route around, which is worse than the original problem.
Give teams sandboxes where they can move freely, keep the tight controls on production, and grant elevated access for a defined window rather than forever.
Where do I start?
With evidence rather than opinion. Most platforms record which permissions an identity actually used, and that log usually shows a fraction of what you granted.
Start with the accounts that can reach customer data, narrow those, then work outward. A complete review that never finishes helps nobody.
Is least privilege the same as zero trust?
No, though they fit together. Least privilege is about how much access an identity holds. Zero trust is about not granting trust based on network location and checking every request.
You can apply least privilege without adopting anything else, which is part of why it is such good value.
How often should we review access?
Often enough that somebody reads the list properly. Quarterly works for most teams, with immediate reviews when people change role or leave.
Tie it to events as well as dates. Role changes are where rights accumulate fastest, because the new access gets added and the old access stays.
Does it apply to service accounts too?
Especially to service accounts. They hold broad permissions, they never change jobs, and nobody notices when something uses them oddly.
One credential per component, scoped to exactly what that component does, is the single change that limits how far an attacker travels afterwards.
Related
Terms that sit next to this one
Access control
The rules deciding which person can see or do which thing in your app.
RBAC
Permissions attach to roles, and people are given roles.
Need to know
Limiting information to the people whose work actually requires it.
Privilege escalation
Gaining rights you were never given, sideways or upwards.
Authorization
Deciding what a proven user is then allowed to do.
Who kept access they stopped needing?
We cannot read your HR system. We can show you what each role inside your application really reaches, with a request and a response for every case. Book a 30 day pilot on one application.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.