Human Managed’s move from RBAC to ABAC exposes policy limits

At a glance

What this is: This is a customer story showing how Human Managed moved from RBAC to ABAC-style policy control because role-based rules could not express customer-specific authorization needs cleanly.

Why it matters: It matters because IAM teams designing authorization for APIs, product packaging, and operational workflows need policy models that keep pace with business context without pushing changes back into application code.

Context

RBAC is a role-centric authorization model: access is inferred from the user’s assigned role, then expanded through role inheritance and nested permissions. That structure works until the business needs conditions that depend on customer, context, or request data rather than a fixed role set. Human Managed’s case is a familiar example of where authorization logic becomes too specific for static roles.

For IAM and application security teams, the real problem is not merely model preference. When policy logic lives in source code, every access change becomes a development, testing, and deployment task. Moving authorization decisions into a policy layer changes how product teams handle packaging, API access, and operational change control, especially where customer entitlements vary by tenant or use case.

Key questions

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. At that point, role explosion and exception handling usually signal that ABAC or another policy-based model is needed.

Q: Why does ABAC reduce application change risk?

A: ABAC reduces application change risk because access rules can live outside the code path and be evaluated from attributes and context at decision time. That means a permission update does not require a code edit, recompilation, and redeployment, which shortens change cycles and reduces the chance of introducing authorization bugs during releases.

Q: What are the signs that authorization logic belongs in policy rather than code?

A: A strong sign is when engineers keep adding exceptions to the application because each customer, tenant, or package needs slightly different access rules. Another sign is when troubleshooting a permission change requires source-code changes just to understand the effective decision. Those patterns show the application is carrying policy it should not own.

Technical breakdown

Why RBAC breaks down for customer-specific access

Role-Based Access Control assigns permissions to roles, then users inherit access by being placed into those roles. That is efficient when entitlements are stable and easy to group, but it becomes brittle when access depends on customer attributes, product package, request context, or organisational exceptions. The article describes exactly that pressure: Human Managed needed flexible access controls for tailored product packaging, and RBAC could not model the required variation without creating role explosion and confusing inheritance chains. In practice, RBAC starts to encode business exceptions as more roles, which makes permission review harder, not easier.

Practical implication: treat RBAC as a coarse access layer, not the place to encode customer-specific policy logic.

How ABAC changes the authorization decision

Attribute-Based Access Control evaluates a request against attributes such as user identity, customer metadata, resource properties, and request context. Instead of asking which role a user has, it asks whether the conditions for access are true at decision time. That is why ABAC can express policy such as organization membership, product tier, or API context without rewriting the application whenever a rule changes. The article’s key point is operational: authorization becomes a policy decision outside the code path, so the application asks for a yes-or-no verdict rather than hard-coding business rules. This separates entitlement logic from release cycles.

Practical implication: move conditional access logic into a policy layer when access depends on attributes that change more often than code.

Why policy-driven authorization reduces change risk

Policy-driven authorization changes where risk sits. Instead of scattering if-then-else logic across application code, the team maintains policy centrally and evaluates it at runtime. That improves change control because a permission update no longer requires a source-code edit, recompilation, and redeployment. It also improves auditability because the rule set is easier to inspect than buried branching logic. In Human Managed’s case, the policy layer sat behind the API, with metadata fetched separately and the final decision reduced to allow or deny. That pattern matters wherever operational teams need fast entitlement changes without destabilising application releases.

Practical implication: centralise authorization policy when deployment friction is slowing entitlement changes or creating audit blind spots.

NHI Mgmt Group analysis

RBAC failure here is a governance limitation, not just an implementation inconvenience: when access needs vary by customer, product packaging, or request context, role inheritance stops expressing the real business rule. The result is role sprawl, opaque effective permissions, and a widening gap between policy intent and runtime enforcement. For practitioners, the lesson is that authorization models must match the granularity of the decision they are trying to govern.

ABAC becomes valuable when business context, not static identity, drives access: the article shows a familiar point where identity-centric grouping is too coarse for the policy problem. Attributes let teams bind authorization to the request, resource, and tenant context without translating every exception into a new role. That is the difference between managing access as an operational control and managing it as a code maintenance burden.

Policy-driven authorization shifts change control out of the application release path: once access logic lives in policy, teams stop treating entitlement updates as software changes. That matters for IAM, IGA, and platform teams because it shortens the path from business rule to enforcement while reducing the chance that access decisions are hidden inside application code. The practical conclusion is to govern policy as a first-class control surface.

Authorization architecture should be judged by how well it absorbs variability: Human Managed’s example is not about replacing one model with another for its own sake. It shows that the decisive test is whether the model can absorb customer-specific conditions without creating brittle code paths or unreadable role hierarchies. Practitioners should measure authorization design by policy clarity, operational change speed, and reviewability, not by how familiar the model sounds.

Centralising rules in a policy layer also changes accountability: once the rule is externalised, product, engineering, and security teams can reason about access separately from application release cadence. That improves governance only if the policy source of truth is controlled, tested, and reviewed as rigorously as code. The takeaway for identity programmes is that authorization governance now extends beyond the app stack into policy lifecycle management.

What this signals

Policy-driven authorization is the main governance lesson here: when the business needs access decisions that vary by customer or context, the control surface has to move closer to policy and further from source code. That is not just an architecture preference. It changes how teams review, test, and approve entitlement changes across the IAM programme.

RBAC and ABAC should be treated as different answers to different problems: RBAC is still useful for coarse grouping and human-readable assignment, but it becomes fragile when business exceptions accumulate. ABAC handles that variability better because it evaluates request conditions directly, which makes it more suitable for packaging, API entitlements, and customer-specific rules.

Authorization governance now belongs in lifecycle management as well as application design: once policy becomes externalised, teams need a clear process for policy versioning, validation, and review. Without that discipline, the speed benefit can turn into a governance gap where access changes are faster but less controlled.

For practitioners

• Define where RBAC stops Map the places where role inheritance is no longer sufficient, especially customer-specific packaging, tenant exceptions, and API decisions that depend on request context.
• Move conditional logic into policy Keep if-then-else access rules out of application code when the decision depends on attributes, metadata, or runtime context that changes frequently.
• Treat policy as a governed artifact Version, test, and review authorization policy with the same discipline used for code so changes remain auditable and do not bypass change control.
• Validate effective permissions regularly Check whether nested roles or policy combinations still produce the access outcome the business expects, especially where customer entitlements differ by product tier.

Key takeaways

• Human Managed’s experience shows that RBAC can become too coarse when access must reflect customer-specific conditions, packaging, or request context.
• The practical value of ABAC is not abstract flexibility, but the ability to externalise authorization decisions so application code does not carry every entitlement exception.
• For IAM teams, the real control shift is from role maintenance to policy governance, with stronger reviewability and faster change handling when done well.

Key terms

• Role-Based Access Control: A model that grants permissions by assigning identities to predefined roles. It works well when jobs are stable and access patterns are predictable, but it becomes brittle when exceptions pile up. In practice, role design must stay small enough to audit and broad enough to avoid endless custom variants.
• Attribute-Based Access Control: Attribute-Based Access Control is a policy model that grants or denies access using attributes such as user role, device state, location, and application context. It replaces purely static role assignment with a decision process that can adapt to current conditions, provided the underlying attributes are trustworthy and well-governed.
• Policy Driven Authorization: A policy driven authorization model makes access decisions from centrally defined rules rather than hard coded application logic. It lets teams express who can do what, under which conditions, and across changing business contexts. This approach is designed to be flexible enough for new use cases without forcing application rewrites.
• Effective Permissions: Effective permissions are the access an identity can actually use after role inheritance, scope, and policy are applied. In Azure AI environments, they often matter more than the assigned role name because inherited rights can widen access to data, logs, and secret stores.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.