Our earlier piece on core and add-on role mining described the shape of the redesign. It didn't answer a fair follow-up question: how do we know the shape we recommend is actually the right one, and not just whatever came out of the first run? This is that answer. Before we trust a redesign enough to hand it to a client, we run it dozens of times against their own data, deliberately varying every setting the engine exposes, and we do it again on a second client with a completely different population shape, to make sure a finding isn't just an artifact of one dataset.
We're publishing the results because the findings are more useful, and more reassuring, than a single case study can be on its own: most of what looks like a "tuning decision" turns out not to matter at all, one decision matters enormously, and it behaves in opposite directions depending on the shape of the client. That last part is exactly why a redesign should never be copied from one organization to another, even a superficially similar one.
Two clients, deliberately different in shape
The two organizations behind these numbers are already familiar to readers of this site: the large, integration-heavy organization from our earlier case-study series, roughly a thousand users spanning several license tiers within the same job functions, and a second, much smaller organization, fewer than a hundred licensed users, with roles that are largely homogeneous, most people in a given role need close to the same access, and, distinctly, almost no usable navigation telemetry to work from. We picked this pair deliberately: if a finding holds on both a large, tier-diverse population and a small, uniform one, it's a property of the method, not a coincidence of one client's data.
Two designs, not two settings of one dial
The most common misunderstanding we run into is treating "strict" and "consolidated" as two points on the same slider. They're not. They're two different algorithms, and confusing them is where most confusion about the results comes from.
The strict design splits every job function into a separate role per license tier, so nobody ever pays for more than their own evidence supports. Anything too specific to share becomes an individual, per-user grant. It's the cost floor, mathematically the cheapest correct answer, and, as we found the hard way, operationally unworkable once the individual-grant tail is large.
The consolidated design collapses each job function into one role at its most common tier, and reabsorbs the leftover tail into shared objects instead of individual ones. It costs more, because some people below that common tier get bumped up to it. It's also the only design most security teams can actually run.
The one setting that actually moves the bill
Across every combination we tested, one decision explained almost the entire cost difference between designs: whether to consolidate at all. Everything else, exactly how generously a role shares a privilege, how aggressively small clusters get merged, how far a cleanup pass goes, moved the number by low single digits or less. If a client asks us what actually drives the cost in this methodology, this is the honest, complete answer: one decision, not fifteen.
The direction is consistent, more roles get consolidated, more people get bumped to a shared tier, cost goes up, but the size of that effect is not. On the large, tier-diverse client, consolidating cost roughly 11% more than the strict floor. On the small, largely uniform client, the same move cost roughly 57% more. Same mechanism, wildly different bill, because a small population with fewer distinct tiers per role has a much larger fraction of its people sitting on the wrong side of "most common tier" once you force everyone into one role.
Every design produces two figures that sound similar and measure different things. The license bill is what the client actually pays, the sum of each person's one required seat. The over-provisioning figure is a separate waste score, the value of access someone holds without evidence they use it, whether or not that access changes their seat. A design can hand out real waste without the bill moving at all, if the extra access lands on people who already needed that tier for another reason. Reading only one of these numbers gives an incomplete, sometimes misleading picture.
The setting that's dangerous to reuse across clients
One tuning decision, how generously a shared role absorbs a privilege that most, but not all, of its members need, behaves in genuinely opposite ways depending on the client.
Loosen that threshold on the small, uniform client, and almost nothing happens, its roles were already close to single-tier, so sharing aggressively barely changes who gets bumped. Loosen the exact same threshold on the large, diverse client, and a Full-tier privilege gets pulled into a shared role whose other members only needed a cheaper tier, dragging all of them up with it. In our testing, that single setting, moved one notch too far, would have added on the order of an 18% cost blowout and nearly quadrupled how many people ended up over-licensed, on a client where the correctly-tuned version of the same design was already the recommended one.
Whether generous sharing helps or hurts depends entirely on how tier-diverse a client's job functions actually are, not on the client's size, industry, or how similar it looks to a past engagement on paper. This is exactly why we re-sweep this setting on every new client's own data rather than reusing whatever a previous engagement landed on, and it's the single easiest way to turn a legitimate methodology into a six-figure mistake if it's skipped.
What's genuinely free to fix, and what has a price
Not every consolidation choice costs money. Reabsorbing a user's small leftover access into a role they already sit in, when it doesn't change their required tier, consistently improved manageability on both clients at no cost, and on the larger client it actually saved money, folding a redundant separate grant into an existing role removed a tier-forcing duplicate the model had been unnecessarily paying for.
Pushing all the way to zero leftover individual grants, so that literally every user sits on a named, reusable role, is a different story. On the small client, closing that last gap added a modest amount to the bill, because the final catch-all buckets happened to bump a few people up a tier. On the large client, the same cleanup was free, its leftover buckets landed on people who already held that tier for other reasons. Whether the very last mile of consolidation is free or has a price is, again, a property of the specific client's data, not something either client's outcome predicts for the next one.
What doesn't move at all, and why that's reassuring
One number stayed completely fixed no matter how we tuned the recommended design on either client: the number of core, shared roles. That count is set by how many genuinely distinct job functions exist in the underlying population, once service and system accounts are excluded, not by any setting we control. We take real reassurance from that. A recommendation that's robust to how it was tuned is a recommendation grounded in the client's actual organizational shape, not one balanced on a knife's edge that a slightly different sweep would have flipped.
What we actually hand a client
We don't hand over one number. A short, deliberately small menu, cost floor, recommended design, a fewer-roles alternative that accepts more over-provisioning, and today's current spend as the baseline, lets a client see the real trade-off frontier: cost against role count against how many people's access changes, instead of a single figure presented as the only possible answer. More than a handful of options stops being useful, the differences blur together and nobody can reason about fifteen near-identical configurations, so we deliberately keep the menu short enough to actually decide from.
It is never "cheaper" versus "more expensive" in isolation. It's a specific, quantifiable trade: some number of people carrying slightly more license than their individual evidence strictly requires, in exchange for a role count your team can actually staff, train, and audit against. The size of that trade is not guessable in advance, and it is not the same for every organization, which is exactly why it has to be measured on your own data before it's presented as a recommendation.
Questions we get asked
If one setting explains almost everything, why test all the others at all?
Because "probably doesn't matter" and "confirmed not to matter, on two differently shaped clients" are different levels of confidence, and only one of them is something we're willing to put in front of a client as the basis for a six or seven-figure recommendation. The other settings earning a "doesn't matter much" verdict is itself a finding worth having tested, not an assumption worth skipping.
Could a third client break these findings?
Possibly, and that's exactly why every new engagement gets its own sweep rather than inheriting the last client's settings. What we're confident about isn't "these exact numbers apply everywhere," it's "consolidation is the dominant cost lever, and the sharing threshold is genuinely client-specific." Both of those are structural properties of the method, consistent across two very differently shaped datasets, not a coincidence tied to either one.
Does a smaller organization get a worse deal out of this?
Not a worse deal, a different one. A small organization's consolidation premium looks larger in percentage terms because its whole population is smaller, but the actual dollar amount at stake is proportionally small too. The honest framing for a small client is usually "a modest, known dollar amount to retire thousands of unmanageable individual grants," not the percentage figure on its own, which can look alarming out of context.
Why not just always pick the cheapest design?
Because the cheapest design in this study came with thousands of individual, one-off roles, which is a real, ongoing administrative and audit cost that a license-cost figure doesn't capture at all. A number that looks best on a spreadsheet and unworkable in production isn't actually the cheapest option once someone has to staff it.
Glossary
| Term | Meaning |
|---|---|
| Strict design | The cost-floor role model: one role per job function per license tier, zero over-licensing, a large per-user leftover tail |
| Consolidated design | One shared role per job function, at its most common tier; costs more, but the leftover tail can be reduced to zero |
| Consolidation premium | The extra annual cost of moving from the strict design to a consolidated one, the direct price of "one role per job" instead of "one role per job per tier" |
| Sharing threshold | How large a fraction of a role's members must need a privilege before it becomes part of everyone's shared role |
| Over-provisioning score | The value of access granted without usage evidence, tracked separately from the license bill because it doesn't always change what anyone actually pays |
| Trade-off frontier | The small menu of designs, cost vs. role count vs. people affected, presented together so a client can choose deliberately instead of being handed one number |