Notifications
Clear all
Topic starter
09/06/2026 11:05 pm
TL;DR: Modern application authorization has outgrown simple RBAC, with ABAC, externalized policy engines, and observability now central to secure distributed design, according to Cerbos and the PurePerformance podcast discussion. The practical shift is that access control must be treated as a scalable governance layer, not scattered application logic.
NHIMG editorial — based on content published by Cerbos: authorization, ABAC, and scalable access control in modern applications
Questions worth separating out
Q: How should security teams implement centralized authorization in distributed applications?
A: Start by moving high-risk authorization rules out of application code and into a policy decision layer that every service can call consistently.
Q: When does RBAC become too limited for application authorization?
A: RBAC becomes too limited when access depends on resource ownership, data sensitivity, time, device, or other contextual conditions that a simple role cannot express cleanly.
Q: How do you know if authorization controls are actually working?
A: Look for consistent decision outcomes, low policy drift, clear audit trails, and stable performance under load.
Practitioner guidance
- Map authorization logic out of application code Identify where access rules are hardcoded inside services, then move high-risk decisions into centralized policy management so teams can version, test, and audit them consistently.
- Separate coarse roles from contextual policy Use roles for broad job function access and use attributes for resource sensitivity, ownership, location, or session context.
- Instrument authorization decisions end to end Track decision latency, cache evictions, and authorization failures so operational teams can distinguish policy defects from application performance problems.
What's in the full article
Cerbos' full post covers the operational detail this analysis intentionally leaves for the source:
- How Cerbos models policy decision points and policy enforcement points in distributed application architectures.
- Examples of ABAC rules and attribute combinations that teams can adapt for real application access decisions.
- Performance and observability details, including traces, latency, and cache behaviour for authorization decisions.
- Query planning patterns for list filtering that reduce the N plus one problem in resource access checks.
👉 Read Cerbos' discussion of authorization, ABAC, and scalable access control →
Authorization at scale: are your access controls keeping up?
Explore further
10/06/2026 1:19 am
Broken access control is now a governance problem, not just an application bug. The article reinforces a basic truth that many programmes still underweight: authorization failures are often caused by architecture, not isolated coding mistakes. When policy logic is fragmented across services, access decisions become inconsistent, unauditable, and hard to recertify. That is why broken access control keeps appearing as a top vulnerability class. Practitioners should treat authorization drift as an identity governance failure, not only an appsec defect.
A few things that frame the scale:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- That same research found that organisations maintain an average of 6 distinct secrets manager instances, a fragmentation pattern that weakens centralized governance.
A question worth separating out:
Q: What should teams do when authorization checks slow down application performance?
A: Measure whether the delay comes from repeated policy evaluation, poor policy caching, or inefficient resource filtering. In many systems, the fix is architectural, not just tuning, because centralized policy and query planning can reduce both latency and security risk.
👉 Read our full editorial: Authorization at scale: why RBAC is not enough for modern apps
