Topic starter
12/06/2026 12:04 am
TL;DR: Broken access control remains the dominant application authorization risk, and the article argues that policy-based access control is re-emerging because modern systems now need context-aware decisions across microservices, human users, and machine identities, according to Cerbos. The practical shift is away from scattered code checks toward centralized policy evaluation that can support least privilege, auditability, and real-time decisioning.
Editorial analysis by NHI Mgmt Group, based on content published by Cerbos: “PBAC is back. Why policy‑based access control is trending again for enterprise security”.
Key questions
Q: What breaks when authorisation is hardcoded into application logic?
A: Hardcoded access rules become brittle as systems grow, because each code path must be updated and retested whenever permissions change.
Q: Why does PBAC reduce broken access control in modern applications?
A: PBAC reduces risk by moving access logic into one governed policy layer instead of duplicating it across services.
Q: How do you know if your authorisation model is too dependent on RBAC?
A: If access exceptions keep accumulating, if teams cannot explain decisions without reading code, or if the same rule is implemented differently across services, RBAC is too coarse for the environment.
Practitioner guidance
- Separate policy from application code Identify where authorisation checks are embedded directly in services and replace repeated logic with a central decision layer for shared rules.
- Model access around subject resource action and context Define policies using attributes such as user role, resource sensitivity, action type, and environmental conditions instead of relying on roles alone.
- Version and test policies like code Store policies in source control, review changes, and run tests that prove allowed and denied decisions before promoting updates.
Bottom line: Broken access control remains common because access logic is still too often embedded in application code and repeated inconsistently across services.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 5 days ago by NHI Mgmt Group
12/06/2026 9:06 am
PBAC is a response to authorisation debt, not just an access-control pattern. When permission logic is scattered through application code, every feature change adds another place where policy can drift from intent. That is why broken access control persists even in otherwise mature engineering teams. The practitioner lesson is that authorisation must be governed as a lifecycle asset, not treated as incidental application logic.
A question worth separating out:
Q: Should IAM teams treat policy-based access control as part of identity governance?
A: Yes. Authorisation is part of identity governance because it determines how access is granted, reviewed, and explained across systems. PBAC gives IAM and IGA teams a shared decision model that can support least privilege, auditability, and change control without pushing every rule into each application.
👉 Read our full editorial: Policy-based access control is back for modern authorization
This post was modified 5 days ago by NHI Mgmt Group