PlainIDGet the migration plan
RBAC → PBAC Translator

Watch role explosion become a handful of policies

RBAC bakes context into static roles, so every location, app and environment multiplies your role count. Set your dimensions below to see the combinatorial role estate — then watch PBAC collapse it into run-time policies, with the admin savings and a generated sample policy.

Want the dollar view? Try the ROI Calculator to size the full 3-year value of run-time authorization.

Set your access dimensions. In RBAC, every combination becomes a new role. Drag the sliders to watch the role estate explode — then see how PBAC collapses it.

Contextual dimensions

Each dimension multiplies the RBAC role count.

40
Roles people actually do — e.g. 40
8
Each one forks a role set
2
Dampened — each app adds 40% impact
1
Dampened — each env adds 20% impact
RBAC roles =40 × 8 × 1.4 × 1 ≈ 448Apps & environments are dampened — the first counts in full; beyond that each extra application adds 40% and each extra environment 20% to the role count, so yours act like ×1.4 and ×1.

Admin cost assumptions

Used to estimate annual maintenance savings.

1.5
1–2 hours typical
$85
$75–$100/hr
Before · RBAC
448
static roles to mint & maintain
showing 360 of 448 roles
After · PBAC
45
run-time policies, context-aware
40 job-function policies
One attribute-based policy per job function — the role explosion across location, app and environment collapses into run-time conditions on each.
5 cross-cutting policies
Break-glass, MFA step-up, geo-fencing, working-hours and deny-by-default — written once, enforced everywhere.
0 net-new roles per app
Onboarding a new application or region adds attributes, not a fresh multiplicative slice of the role matrix.
90%fewer access objects to manage — 448 roles → 45 policies, a 10:1 collapse
RBAC annual admin cost$11,424
PBAC annual admin cost$2,869
Estimated annual savings$8,555

269 of your 448 roles likely differ from a sibling by a single permission — pure role sprawl PBAC eliminates.

Generated PBAC policy
policy "access-claims-adjuster" {
  permit when
    subject.jobFunction == "Claims Adjuster"          // 1 of 40 job functions
    and subject.region == resource.region             // collapses 8 location-roles
    and resource.app in subject.entitledApps          // collapses 2 app-roles
    and context.environment == resource.environment   // collapses 1 env-roles
    and context.time within subject.workingHours      // runtime context RBAC can't express
}

Sample policy derived from your dimensions. The full pack maps every job function this way.

RBAC → PBAC Migration

Get the full RBAC→PBAC migration plan

Share a few details and a PlainID specialist will send the full policy pack and a phased migration plan tailored to your role estate — mapping your 448 roles to 45 run-time policies.

RBAC → PBAC translator — frequently asked questions

How the model works and what it measures.

  • Why does RBAC create a role explosion?
    Role-based access control encodes context — location, business unit, application, environment — directly into static role definitions. Every new dimension multiplies the number of roles, because each combination needs its own role to grant the right access. A modest environment of 50 job functions across 20 locations and 10 projects already implies roughly 10,000 roles, most of which differ from a sibling by a single permission. This is the well-documented combinatorial blow-up that makes RBAC unmanageable at scale.
  • How does PBAC collapse all those roles into a few policies?
    Policy-based access control evaluates attributes and context at run time instead of pre-minting a role for every combination. The location, business unit, application and environment that RBAC bakes into separate roles become conditions inside a single policy. So one policy per job function — plus a small set of cross-cutting policies for break-glass, MFA step-up, geo-fencing and working hours — replaces the entire multiplicative role estate.
  • How is the admin-cost saving calculated?
    We model the annual maintenance of access objects: roughly 20% of the role estate is touched each year (the midpoint of the typical 15–30% range from PlainID's ROI benchmark), at your maintenance-hours-per-object and IAM hourly rate. PBAC is modelled at about half that change rate because a single policy update covers many access scenarios. The savings is the difference between the two annual figures. It is a directional estimate, not a quote.
  • Is the generated policy real syntax I can deploy?
    The sample is readable pseudo-policy that illustrates how your specific dimensions translate into run-time conditions — it is meant to make the RBAC-to-PBAC mapping concrete, not to be pasted into production. PlainID supports standards-based policy languages (including OPA Rego and the OpenID AuthZEN API). Request the full migration plan and a specialist will produce deployable policies for your environment.
  • What do I get if I request the full migration plan?
    A PlainID specialist will send the full policy pack — every job function mapped to a run-time policy — plus a phased migration plan that sequences which role clusters to retire first, how to externalize authorization from your applications, and how to prove least-privilege continuously for audit. It is tailored to the role estate you modelled here.