Published 2026-04-03

Least Privilege Can Be Poor Practice

Published 2026-04-03

The Problem with a Sacred Cow

The "principle of least privilege" is one of those security controls we learn by rote. It sounds innocuous enough: reduce the privileges for any user so they can do what they need to do but nothing more. For anyone coming from a classical Unix background, this seems like an improvement over the all-or-nothing power of the root user (same with Windows and the Administrator role). For those of us who cut our teeth on big iron — what today is called IBM Z — a range of privileges has been the norm for decades.

But least privilege, as it is usually implemented, is a poor practice — not a best practice.

It should be renamed the principle of optimal privilege, where "optimal" is the correct balance between access control complexity and the ability of users and tools to accomplish useful work.

The Combinatorial Explosion

The following table shows the privilege structures for common platforms and the approximate number of possible privilege combinations each supports.

Platform	Privilege Structure	Approx. Combinations
z/VM	33 classes (A-Z, 0-6); 7 IBM-defined (A-G), 26 user-definable; any non-repeating combination	~10⁹ (billions)
z/OS (RACF)	User-level privileges, group-level privileges, access control lists, arbitrary object privileges, implicit privileges	~10⁹ (billions)
IBM i on IBM Power Systems	User classes, special authorities, object authorities, adopted authority	~10⁶ (millions)
Linux	Users, groups, file permissions, POSIX ACLs, 41 kernel capabilities across 5 sets, SELinux/AppArmor, namespaces	~10⁶ (millions)
Windows	36 privilege constants, 44 user rights assignments, 5 mandatory integrity levels, discretionary ACLs with 32-bit access masks per object	~10¹³ (trillions)
Cloud (AWS, Azure, GCP)	API-level and resource-level permissions; AWS alone defines over 20,000 distinct IAM actions across 350+ services	~10²⁰⁺ (sextillions)

Clearly, no organization uses that many privilege sets. A large enterprise will typically have hundreds to low thousands. But even at that magnitude, maintaining roles becomes a nightmare — and the natural tendency is either to leave what works alone or to grant more privilege than necessary.

Why This Matters: Interactive Complexity

The problem is not just administrative overhead. A large number of fine-grained privilege sets creates interactive complexity and tight coupling: there are more combinations of effects than anyone can enumerate, much less comprehend, and the nth-order impact of this complexity will manifest itself as system accidents (Perrow, 1999).

Charles Perrow's Normal Accidents demonstrated that in tightly coupled systems with interactive complexity, failures that interact in unexpected ways are not anomalies — they are inevitable. When your access control system becomes a tightly coupled complex system in its own right, the security mechanism itself becomes a source of failure.

In practice, this means:

Users cannot do their jobs and flood the help desk with access requests.
Administrators repeatedly add permissions until something works, without understanding why.
Permissions accumulate and are rarely revoked — creating a "ratchet effect."
Users share credentials or find workarounds that bypass access controls entirely.
The access control system becomes so complex that no one can audit it effectively.

A 2023 Palo Alto Unit 42 analysis of 680,000 cloud identities found that 99% of cloud users, roles, and services had excessive permissions — many unused for 60+ days (Palo Alto Networks, 2023). The mechanism is predictable: when getting access is painful, people request more than they need, and no one revokes what goes unused.

The Dangers of Overly Granular Permission Grants

Fine-grained permissions feel like better security. In practice, they produce the opposite:

Permission ratchet. Users request broad access to avoid repeated access requests. Once granted, privileges are rarely reviewed or revoked.
Shadow IT. When legitimate access is too hard to obtain, users route around controls — shared credentials, personal devices, unauthorized cloud services. A StrongDM survey found over 40% of teams resort to shadow IT due to access friction (StrongDM, 2022).
Audit failure. A system with thousands of roles cannot be meaningfully audited. If you cannot explain your access control model to an examiner, you do not have a functioning access control model.
Configuration errors. Administrators who do not fully understand the permission model repeatedly add permissions until an operation succeeds. The resulting privilege set is neither least privilege nor intentional — it is accidental.
Role explosion. Roles are created to address specific situations but almost never deleted. An organization with 1,000 employees can easily end up with several thousand roles, transforming a manageable problem (governing people) into an unmanageable one (governing roles) (Elliott & Knight, 2010).
Productivity loss. Ivanti's 2024 survey of 7,800 IT professionals found that 61% of employees use unsafe workarounds when frustrated by security controls, and access friction costs an average of 1.6 hours per employee per month. For a 2,000-person organization at $100/hour loaded cost, that is approximately $3.8 million per year (Ivanti, 2024).
Worse security outcomes. A cumbersome control that is bypassed 30% of the time is worse than a slightly less restrictive control that is followed 100% of the time.

The Productivity Cost Is Real

The StrongDM Access Productivity Report (2022) surveyed 600 IT, security, and DevOps professionals. The findings are striking:

64% of organizations have productivity impacted daily or weekly due to access issues.
57% take days or weeks to approve and grant infrastructure access.
52% of development teams have missed deadlines due to infrastructure access issues.
53% of organizations have shared credentials across teams as a workaround.

During a recent migration of a client from AWS WorkMail to Microsoft 365 Exchange Online, we had to go back to the permissions well more than 15 times to get the migration role to work. That cost approximately 75 minutes of a senior engineer's workday — not because of a security threat, but because Microsoft's extremely granular permission model made it nearly impossible to determine the correct combination of privileges on the first, second, or tenth attempt.

What "Optimal Privilege" Looks Like

Ironically, the paper that gave us the principle of least privilege also gave us the answer. Saltzer and Schroeder (1975) articulated another principle in the same paper: psychological acceptability — that security mechanisms must be designed for ease of use so that users routinely and automatically apply the protection mechanisms correctly. The tension between these two principles, from the same authors in the same paper, has been largely ignored for fifty years.

The lesson is not to give maximum privileges to every user. The lesson is to find the optimum balance between role privileges, security requirements, and the need for users and tools to accomplish useful work rather than fiddling with privilege sets for hours on end.

In practice, this means:

Consolidate roles aggressively. Even for the largest organizations, the number of necessary roles is in the tens — perhaps the hundreds at most. Aim for tens. This is a correct implementation of role-based access control (RBAC). If you find yourself with hundreds of roles, look for opportunities to consolidate.
Accept that most roles will have more privileges than strictly necessary. This is not a deficiency. Very few organizations have accurately recorded what each role will need — including operations that happen monthly, quarterly, or annually.
Monitor roles rather than restrict them. A smaller number of well-understood roles is far easier to monitor for anomalous behavior than thousands of fine-grained roles that no one can explain. For organizations with functioning detection and response capability, this compensates for the marginal risk of slightly broader access; the trade-off is less favorable for those without it.
Measure the cost of friction. Track help desk tickets for access requests, time spent on permission troubleshooting, and workarounds. These are signals that your access control model is working against you.
Use tools to find the optimum. We developed an open-source tool called AccessGuard that ingests AWS IAM permission sets, roles, users, and groups across multiple accounts, detects exact duplicates and near-matches using Jaccard similarity clustering, and uses AI analysis to recommend consolidation opportunities with risk ratings. The first time we used it, we reduced a client's privilege sets from 119 to 22 — many were pure duplicates, and the rest could be consolidated by granting a few (usually read-only) additional privileges to an existing role with a higher percentage of overlap.

Conclusion

Least privilege is a fifty-year-old idea that made sense when systems had simple privilege models and users numbered in the dozens. Applied literally to modern platforms with thousands of granular permissions, millions of objects, and complex organizational structures, it produces the opposite of its intent: systems that are harder to secure, harder to audit, and harder to use.

Optimal privilege — the smallest number of well-defined roles that let your organization function effectively while remaining auditable and monitorable — is what you should be implementing. That is not a compromise. It is better security.

Bibliography

Elliott, A. and Knight, S. (2010). "Role Explosion: Acknowledging the Problem." Software Engineering Research and Practice, CSREA Press, pp. 349-355.
Ferraiolo, D.F., Sandhu, R., Gavrila, S., Kuhn, D.R., and Chandramouli, R. (2001). "Proposed NIST Standard for Role-Based Access Control." ACM Transactions on Information and System Security, 4(3), 224-274.
Ivanti (2024). DEX Security Research Report.
Kuhn, D.R., Coyne, E.J., and Weil, T.R. (2010). "Adding Attributes to Role-Based Access Control." IEEE Computer, 43(6), 79-81.
Palo Alto Networks Unit 42 (2023). Cloud Threat Report, Vol. 7.
Perrow, C. (1999). Normal Accidents: Living with High-Risk Technologies (updated edition). Princeton University Press.
Saltzer, J.H. and Schroeder, M.D. (1975). "The Protection of Information in Computer Systems." Proceedings of the IEEE, 63(9), 1278-1308.
Smith, R.E. (2012). "A Contemporary Look at Saltzer and Schroeder's 1975 Design Principles." IEEE Security & Privacy.
StrongDM (2022). The Access Productivity Report.
Wolff, J. (2023). "Normal Cyber Accidents." Journal of Cyber Policy, Taylor & Francis.