Least privilege is a design principle that limits each user or system to only the access needed for its job. Broken access control is the failure state where those limits are not enforced in the application. In practice, least privilege is the goal, while broken access control is what happens when checks are missing, bypassed, or implemented inconsistently.
Why Broken Access Control and Least Privilege Are Not the Same Thing
least privilege is the target state, a control principle that narrows what an account, role, workload, or agent can do. broken access control is the failure state, where the application does not reliably enforce those limits. The difference matters because one describes how access should be designed, while the other describes how access checks fail in practice.
That distinction is why access control reviews should not stop at role names or policy intent. A system can appear to follow least privilege on paper and still be broken if object-level checks, function-level checks, or ownership checks are inconsistent. In other words, least privilege is about intended scope; broken access control is about enforcement quality.
For a deeper map of the access-control side of the problem, see IAM and IGA Basics, which covers authorization models and entitlement governance. Least privilege is also closely tied to Privileged Access Management Guide, where the practical question is not just who can log in, but how much standing power that access should retain.
What Changes in Practice When Access Control Is Broken
Broken access control shows up when a user can reach data, actions, or administrative functions outside their intended scope. The defect may be an omitted check, a check applied only in the user interface, a rule that can be bypassed, or a permission model that is too broad to distinguish one object from another. Least privilege does not prevent those failures by itself, it only defines the standard the application should be trying to meet.
That is why broken access control often appears as a product defect, not just a policy problem. If the application trusts a caller too much, or if authorization is only enforced in some paths, the real issue is implementation inconsistency. A strong authorization design still fails if one endpoint, one method, or one tenant boundary is left unprotected.
Least privilege is broader than a single app check. It also includes scope design, entitlement review, temporary elevation, and removal of standing access that is no longer needed. For that reason, Authorisation Models Guide is useful when you need to compare coarse role assignment with finer policy decisions, and Just-in-Time Access and Zero Standing Privilege Guide is useful when the real risk is unnecessary permanent privilege.
How to Tell Which Problem You Actually Have
If you are deciding whether the issue is broken access control or a weak privilege model, ask two different questions. First, does the application correctly deny access when a caller is outside scope? If not, you likely have broken access control. Second, even when access is correctly enforced, is the granted scope still larger than the job requires? If yes, you have a least-privilege problem, even if the app is not currently broken.
That distinction helps you assign the fix to the right team. Broken access control usually demands engineering remediation, test coverage, and authorization redesign. Least privilege usually demands entitlement cleanup, role redesign, and tighter operational governance. Both can coexist, but they are not interchangeable findings.
For real-world privilege reduction, cloud and machine access often need special attention because overbroad rights accumulate quickly. Cloud PAM and CIEM Guide helps when the issue is effective permissions and escalation paths, while NHI Lifecycle Management Guide is useful when long-lived entitlements and orphaned access are part of the problem.
Risk and Threat Considerations
Broken access control creates direct exposure because an attacker only needs one missed authorization check, one over-permissive object reference, or one bypassable function path to reach data or actions they should not have. Least privilege reduces blast radius, but it does not compensate for a control that fails to enforce the boundary in the first place.
Failure mechanism: The application or access layer either grants access too broadly or fails to re-check authorization at the point where the protected object or action is actually used. That can enable horizontal access, vertical escalation, tenant crossover, or unauthorized administrative action.
Impact: The practical result is unauthorized data exposure, unwanted state changes, privilege escalation, and a larger attack surface for later movement or fraud. When access checks are weak, the difference between a routine bug and a security incident can be very small.
For attack-path context, OWASP API Security Top 10 is the most direct external reference for broken authorization patterns, and NIST SP 800-207 Zero Trust Architecture reinforces the idea that access should be continuously verified rather than assumed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack surface, OWASP ASVS and NIST SP 800-53 Rev 5 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Directly covers broken access control failures in protected actions. |
| API1 — Broken Object Level Authorization | Directly covers unauthorized object access, a core access-control failure mode. | |
| Recommendation — Enforce function-level checks on every protected API action. Validate object ownership and access on every request. | ||
| OWASP ASVS | V8 — Authorization | Materially addresses authorization design and enforcement for the access-control side of the question. |
| Recommendation — Implement consistent authorization checks across all protected functions and objects. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Directly maps to the least-privilege principle asked about in the comparison. |
| Recommendation — Limit each account to the minimum permissions needed for its role. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Relevant because the question distinguishes access-control enforcement from privilege minimization. |
| Recommendation — Define and enforce access-control rules based on need to know and need to use. | ||
Practitioner Guidance
What to verify: Confirm whether the application enforces authorization at the object, action, and tenant boundary, not only at login. Then compare granted permissions with actual job function to see whether you also have a least-privilege gap.
Decision rule: If a user can do something they should never be able to do, treat it as broken access control first. If the user can do only what they are allowed to do, but the allowed scope is still excessive, treat it as a least-privilege problem.
Practitioner takeaway: Broken access control is a control failure you must fix in the implementation, while least privilege is a design target you must keep tightening over time; the best programs treat the former as a defect and the latter as a governance standard.
Related resources from NHI Mgmt Group
- What is the difference between MFA and least privilege in healthcare access control?
- What is the difference between least privilege and role-based access control in CI/CD environments?
- What is the difference between least privilege and role-based access control in PAM programs?
- What is the difference between role-based access control and least privilege in identity governance?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
