Notifications
Clear all
Topic starter
09/06/2026 11:02 pm
TL;DR: RBAC remains easy to understand, but it breaks down when permission decisions need context, fine-grained conditions, and reusable policy logic, according to Cerbos’ CNCF demo. The real shift is that authorization is moving from static role assignment to policy-driven decisioning that better matches modern application and NHI governance needs.
NHIMG editorial — based on content published by Cerbos: a CNCF live demo on modern authorization
Questions worth separating out
Q: How should security teams move beyond RBAC without losing control?
A: Start by keeping RBAC for broad access boundaries and layering ABAC or policy-based rules where decisions depend on context, ownership, or environment.
Q: Why do attribute-based access controls fit modern cloud applications better?
A: Cloud applications often need decisions based on request context, resource state, tenant boundaries, and time-sensitive conditions.
Q: What breaks when authorization rules stay embedded in code?
A: Governance breaks first, because access logic becomes scattered across services and harder to review consistently.
Practitioner guidance
- Inventory where RBAC is overextended Map services, APIs, and admin paths where roles are carrying conditional logic that should be expressed as policy.
- Separate policy logic from application code Move authorization rules into a governed policy layer so access decisions can be reviewed, tested, and changed without redeploying every service.
- Define the attributes that actually drive access List the minimum set of subject, resource, and context attributes required for correct decisions, then remove unused role assumptions that add noise without improving control.
What's in the full article
Cerbos' full presentation covers the operational detail this post intentionally leaves for the source:
- Hands-on policy examples showing how ABAC conditions are expressed in practice
- The Cerbos playground workflow for building and testing authorization policies
- Derived role patterns for context-aware decisions across different application states
- Deployment patterns such as sidecar use and CI/CD validation for policy changes
👉 Read Cerbos' demo on modern authorization with RBAC, ABAC, and policy control →
ABAC and decoupled authorization: what IAM teams need to know?
Explore further
10/06/2026 1:14 am
RBAC is still useful, but it is no longer sufficient as the primary authorization model for modern identity estates. Static role assignment breaks down when access depends on resource context, request conditions, and runtime state. That limitation is visible in application teams, and it becomes sharper when non-human identities need task-scoped permissions that do not map cleanly to human job titles. The practitioner conclusion is that RBAC should be treated as a baseline, not a complete governance model.
A few things that frame the scale:
- 88.5% of organisations acknowledge that their non-human IAM practices lag behind or are merely on par with their human identity and access management efforts, according to The 2024 Non-Human Identity Security Report.
- Only 19.6% of security professionals express strong confidence in their organisation's ability to securely manage non-human workload identities.
A question worth separating out:
Q: How can IAM teams govern policy-driven authorization across services?
A: Treat authorization policy like any other controlled artefact. Require review, testing, versioning, and change approval before release, then monitor for drift between intended policy and runtime decisions. That approach gives IAM teams a repeatable control point even when access logic is distributed across many applications.
👉 Read our full editorial: ABAC and decoupled authorization expose RBAC’s practical limits
