From Disposition to Design: How Keep/Downgrade/Drop Verdicts Become an Actual Role Model

Two of our earlier pieces covered how a single privilege gets its verdict: stays as-is, downgrades to read, or drops, and why "no evidence" has to be handled with real care. Neither one produces a role. A disposition table is, deliberately, just the decision surface, thousands of rows, one per user per privilege, each with a verdict. Someone still has to turn that into an actual set of roles a security team can assign, audit, and maintain.

That's a genuinely different problem, and it doesn't have an obvious right answer.

The needed set, and the two shapes it can take

Start from what each user actually needs: everything that stays_as_is at its native tier, plus everything downgrade_to_read at its cheaper read tier. Privileges the evidence couldn't confirm are held aside unless keeping them would raise the user's license tier; anything genuinely unused and observable is already gone. That's the raw material, a binary user-by-privilege matrix.

There are two honest ways to turn that matrix into roles, and they sit at opposite ends of a real trade-off.

The first: give every user their own role, built from exactly what they need. Zero over-provisioning, by construction, every single time. It also produces roughly as many roles as there are users, which is not a role model, it's a spreadsheet with extra steps. No security team can administer that.

The second: keep the handful of broad roles the organization already has, and just trim what's inside them. Fast, familiar, and it only works if the roles were reasonably coherent to begin with. When a role's members turn out to do genuinely different jobs, wide as it is, no amount of trimming produces something both cheap and correct at the same time.

Neither extreme is usually the right answer. What sits between them is a genuine optimization problem: minimize the number of roles, subject to every user keeping everything the evidence says they need. That has a name in the literature, the Role Mining Problem, a Boolean matrix decomposition that's formally equivalent to set cover, and known to be NP-complete. Naming it correctly matters in practice, not just academically: ordinary similarity-based clustering has no concept of "must cover", it will happily grant a privilege three people need to everyone in a group, or silently drop one that two people depend on. That's a fine trade-off for a marketing segment. It's not an acceptable one for a person's ability to do their job.

Core roles: the part that's never allowed to inflate anyone

The first half of the answer is a core role per job family: whatever privileges the clear majority of that group's active users genuinely need, at a shared license tier. The threshold for "clear majority" isn't fixed; it's swept across a range and chosen deliberately, because pushing it up or down trades role count against how many people carry something they don't personally use.

One rule doesn't move, though: a privilege never enters a core if it would raise even one member's license tier above what their own evidence supports. Cores are built to never inflate anyone, by construction, not by later cleanup. Anything that would blow that rule for even a single person gets pushed out to the second half of the model instead.

Add-ons: the residual, mined rather than guessed

Whatever's left over, the genuinely individual, occasional, or role-crossing access that didn't fit a shared core, becomes the add-on layer. This is where set-cover mining actually happens: group the residual privileges into license-homogeneous bundles that recur across many users, and select the smallest, cheapest set of bundles that still covers everyone's needs.

Naming an add-on well matters more than it sounds. When a mined bundle happens to line up with a real, named business function, an accounts-payable duty, a reporting duty, that's what the add-on is called and scoped to. When granting that whole named function would hand a few of its members more than they need, the add-on shrinks to just the common subset actually shared. Only when neither approach fits does the system fall back to naming the add-on after the pattern of usage itself. Reusing real business language whenever it's honestly available is what keeps the result something an administrator can reason about, instead of a wall of algorithmically-labeled clusters nobody recognizes.

What actually gets handed to the client

None of this is useful if the output is a table of privilege IDs. The delivered role catalog is deliberately written for a non-technical reviewer: a plain-English description of what the role is actually for, the single license a holder is required to carry (the cheapest license that covers everything the role grants, not the most expensive one theoretically possible), how many additional licenses a holder would need only if they exercised every privilege in the role at once, and, separately, which license families the role touches at all, a diagnostic figure, not a requirement. Keeping those last two numbers distinct matters: conflating "touches" with "requires" is exactly the kind of overstatement that makes a savings number impossible to defend later.

Standard roles are left alone on purpose

Every object this process mints carries a version suffix, distinct from what already exists, and only modified-standard or fully custom roles are ever candidates for restructuring. An unmodified, standard Microsoft role is left exactly as it is. This isn't a shortcut: touching Microsoft's own baseline roles adds real risk (breaking assumptions other configuration or ISV code makes about a standard role's shape) for savings that are rarely there in the first place, since standard roles are usually reasonably scoped by the people who wrote them. The savings live in what's been customized, extended, or copied and modified since, and that's exactly where this process spends its effort.

Questions we get asked

Glossary