Notifications
Clear all
Topic starter
09/06/2026 11:28 pm
TL;DR: Human Managed describes how RBAC quickly broke down for customer-specific authorization, pushing the team toward ABAC-style policies that could express richer conditions without rewriting application code, according to Cerbos. The case shows why policy-driven authorization now matters across API access, packaging, and operational change management.
NHIMG editorial — based on content published by Cerbos: Human Managed's authorization story and its move from RBAC to ABAC
Questions worth separating out
Q: How should security teams replace RBAC when access rules depend on customer context?
A: Teams should replace RBAC only where roles are being used to model business conditions rather than stable duties.
Q: Why do role-based models become hard to govern in multi-tenant applications?
A: Role-based models become hard to govern because each new customer rule can create another role combination or exception path.
Q: What signals show that authorization has outgrown static roles?
A: Warning signs include role nesting, repeated code changes for permission updates, inconsistent access logic across APIs, and frequent questions about who really has administrator access.
Practitioner guidance
- Map where RBAC is carrying business logic Inventory APIs and services where roles are being used to encode customer tier, product packaging, or request context.
- Move authorization rules into version-controlled policy files Store access logic in source control, test it in pipeline, and require review before policy changes reach production.
- Define the attributes your access decisions actually need Identify which user, resource, and environmental attributes are required for accurate decisions, then standardise how the API fetches and validates them.
What's in the full article
Cerbos's full success story covers the implementation detail this post intentionally leaves for the source:
- The exact API decision flow that turns identity and metadata into a boolean allow-or-deny response.
- The YAML and CEL policy patterns used to express conditional access without embedding logic in application code.
- The GitOps and Argo CD deployment model that keeps authorization policies under change control.
- The troubleshooting and documentation lessons learned during the rollout.
👉 Read Cerbos's full success story on policy-driven authorization at Human Managed →
RBAC limits in authorization: what ABAC changes for IAM teams?
Explore further
10/06/2026 1:47 am
RBAC failures are often policy-design failures, not implementation failures. Human Managed’s problem was not that roles were missing, but that roles could not express customer-specific authorization without collapsing into nested exceptions. That is the point where RBAC stops being a governance model and becomes a hidden business logic layer. The practitioner lesson is to recognise when access design is carrying product complexity that should live elsewhere.
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.
- 23.7% of organisations share secrets through insecure methods such as email or messaging applications, which shows how quickly access governance weakens when controls are handled informally.
A question worth separating out:
Q: How do policy-driven authorization controls improve access governance?
A: Policy-driven controls improve governance by making rules explicit, testable, and versioned. That gives teams a cleaner change process, stronger auditability, and a way to update access decisions without rebuilding the application each time the business changes.
👉 Read our full editorial: Human Managed’s move from RBAC to ABAC exposes policy limits
