Topic starter
11/06/2026 11:27 pm
TL;DR: Access control still depends on authentication, authorization, and audit, but modern applications increasingly need policy-based decisions that go beyond coarse roles, according to Cerbos. For IAM teams, the real issue is not whether access control exists, but whether it can stay auditable, contextual, and maintainable as systems grow more complex.
Editorial analysis by NHI Mgmt Group, based on content published by Cerbos: “What is access control?”.
Key questions
Q: How should teams decide when to move from RBAC to policy-based authorization?
A: Teams should move when roles alone no longer describe real access conditions.
Q: Why do coarse roles become a problem in growing applications?
A: Coarse roles tend to accumulate exceptions, duplicate permissions, and broad access grants as teams try to fit complex reality into a small number of groups.
Q: What breaks when authorization policy evaluation is tightly coupled to application code?
A: When policy evaluation is tightly coupled to application code, changes become harder to test, deploy, and scale.
Practitioner guidance
- Define where static roles stop Map the access decisions in your application and mark the ones that depend on resource state, time, device, or other context.
- Reduce permission sprawl Review roles for duplication, exceptions, and manual overrides that have accumulated as the application grew.
- Separate policy from application code Move authorization rules into a central control point so teams can update access logic without changing business features.
Bottom line: Access control problems often start when static roles can no longer express dynamic business conditions without exceptions.
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 8:05 am
Policy-based authorization is becoming the practical control plane for modern application access. Coarse roles still work for stable business systems, but they break down when permissions depend on resource state, user attributes, or runtime context. The important change is not technical fashion, it is governance: access decisions now need to be managed as policy, not as scattered application logic. Practitioners should treat this as an authorization architecture choice, not a tooling preference.
A few things that frame the scale:
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
A question worth separating out:
Q: How should teams choose between RBAC and ABAC for application authorization?
A: Use RBAC when access maps cleanly to business roles and the number of exceptions is low. Use ABAC when decisions depend on context such as device, location, resource sensitivity, or time. Most teams need both: RBAC for baseline access and ABAC for exceptions that would otherwise create role sprawl.
👉 Read our full editorial: Access control fundamentals are shifting toward policy-based authorization
This post was modified 5 days ago by NHI Mgmt Group