Because the application is often making the last authorization decision. If the code can be bypassed, the identity policy no longer protects the object, record, or function being accessed. IAM teams need to care because application-level authorisation drift can defeat the access model they believe is in place.
Why This Matters for Security Teams
broken access control matters to IAM teams because identity policy only works if the application and API layer actually enforce it on every request. When object-level checks, function-level checks, or tenant boundaries are weak, users can act outside the access model that IAM designed. That creates audit gaps, privacy exposure, and privilege escalation paths that are often invisible in directory-centric reviews.
This is especially important in systems that rely on role assignment, delegated administration, or service-to-service authorization. A valid identity does not guarantee a valid action. IAM teams should treat broken access control as an enforcement problem that crosses application security, API design, and entitlement governance. Guidance such as NIST SP 800-53 Rev 5 Security and Privacy Controls helps frame access as a control objective, not just a login event.
In practice, many security teams encounter broken access control only after a user has already viewed, changed, or exported data they were never meant to touch, rather than through intentional authorization testing.
How It Works in Practice
IAM programs usually define who a user should be and what broad access they should have. Broken access control appears when the application fails to translate that policy into correct per-request decisions. The most common failures are missing object-level authorization, insecure direct object references, parameter tampering, weak tenant isolation, and admin functions that are reachable with ordinary accounts. These are not just coding defects; they are control failures that undermine least privilege.
For IAM teams, the operational question is whether the control plane and the application plane agree. An identity provider may assert that a user is in a sales role, but the app still has to verify that the same user can only read their own records, not another customer’s data. The same issue arises with non-human identities. Service accounts, API tokens, and automation identities often accumulate broad entitlements, then bypass object-level checks through trusted backend calls. The OWASP Non-Human Identity Top 10 is useful here because many modern authorization failures involve machine identities acting with excessive reach.
Practical controls should include:
- Server-side authorization on every sensitive action, not just at login.
- Consistent object, tenant, and function checks across web, API, and mobile paths.
- Centralized policy for high-risk actions, with logging for denied and allowed events.
- Testing for IDOR, privilege escalation, forced browsing, and mass assignment during release cycles.
- Separation of duties for administrative workflows and privileged API operations.
IAM teams should also align application reviews with control baselines from CIS Controls v8 and inventory sensitive authorization paths as part of governance. These controls tend to break down when microservices, legacy apps, and partner integrations each implement their own authorization logic because policy drift becomes impossible to see end to end.
Common Variations and Edge Cases
Tighter authorization controls often increase engineering and review overhead, requiring organisations to balance speed of delivery against stronger enforcement and test coverage. That tradeoff becomes sharper in multi-tenant SaaS, delegated administration, and highly automated environments where every request may require a different policy path.
There is no universal standard for how much authorization should be centralized, but current guidance suggests that high-risk actions deserve explicit server-side checks and strong auditability. In regulated environments, evidence expectations matter as much as the control itself. For payment systems, PCI DSS v4.0 pushes teams to demonstrate access restriction, monitoring, and review discipline, while ISO/IEC 27001:2022 Information Security Management provides a broader governance lens for access control and assurance.
Edge cases often appear where the app trusts upstream claims too much, such as SSO assertions, group membership, or API gateway headers. That works until a downstream service reuses those claims without re-checking object scope or tenant context. IAM teams should also be cautious with just-in-time access, break-glass accounts, and service principals, because temporary elevation can become standing privilege if revocation, logging, or policy cleanup is incomplete.
The practical rule is simple: if a user, token, or service can reach an object or function directly, authorization must be proven there, not assumed from the directory.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack surface, NIST CSF 2.0, NIST SP 800-63 and ISO/IEC 27001:2022 set the technical controls, and PCI DSS v4.0 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | Broken access control is a least-privilege enforcement failure. |
| OWASP Non-Human Identity Top 10 | NHI-2 | Service accounts and API tokens often bypass app-level checks. |
| NIST SP 800-63 | AAL2 | Strong identity proofing does not replace correct authorization decisions. |
| PCI DSS v4.0 | 7.2.1 | PCI requires access limited by job and business need. |
| ISO/IEC 27001:2022 | A.5.15 | Information access restriction needs governance and evidence. |
Verify every sensitive action is authorized at the application layer, not only at identity issuance.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 1, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
