> For the complete documentation index, see [llms.txt](https://docs.balkan.id/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.balkan.id/iam-risk-analyzer/rbac-analyzer/current-and-ideal-state-rbac.md).

# Current & Ideal State RBAC

The RBAC Analyzer presents your access two ways: as it is today, and as it could be. Comparing the two turns an abstract goal "move toward least privilege" — into a concrete, reviewable plan.

* **Current State RBAC** is your live access, factored into BalkanID Generated Roles exactly as it stands. It is the honest picture of how access is structured right now, including the drift and over-provisioning that accumulate over time.
* **Ideal State RBAC** is the least-privilege target BalkanID derives from your current state. It is produced by applying the engine's own recommendations and re-factoring, so it represents what your roles *should* look like once redundant and unused access is cleaned up.

Both views share the same tables and drill-downs: *Generated Roles, Role Confidence,* and *Role Risk Factor* — so you can audit the target the same way you audit today's posture.

{% hint style="info" %}
The ideal state conserves access by construction such that no real access is silently dropped. It shows which current roles are kept, which are reshaped, and which are removed on the way to a smaller, cleaner set. You decide what to adopt and when.
{% endhint %}

### Consolidation

Consolidation is the process of collapsing today's sprawling role definitions into a tighter set. The Analyzer surfaces it as a funnel so you can see the reduction at a glance, typically across three stages:

| Stage                | What it represents                                                                                 |
| -------------------- | -------------------------------------------------------------------------------------------------- |
| **Grants today**     | The access that exists right now, before any consolidation.                                        |
| **Role definitions** | How many distinct role definitions describe that access — *before* versus *after* consolidation.   |
| **Single-sourced**   | Permissions that end up granted by exactly one role, a sign of clean, non-overlapping role design. |

The gap between *before* and *after* is your consolidation opportunity: duplicate and unused access removed, survivors merged into a smaller ideal set. Clicking through a funnel stage drills into the underlying grants in the Permission Set Explorer.

### Role lifecycle

Underneath consolidation, every current role is tracked through to the ideal state:

* **Kept:** the role survives essentially unchanged.
* **Reshaped:** the role survives but its permission set is tightened.
* **Removed**: the role's access is redundant or unused and is dropped.
* **Merged**: overlapping roles collapse into a shared role.
* **New**:a small number of net-new ideal roles are created to close gaps.

This lifecycle is what lets you adopt the ideal state incrementally and confidently: you can see exactly what becomes of each role rather than being handed an opaque "after" picture.

### Adoption Readiness

Not every generated role is equally ready to operationalize. **Adoption Readiness** buckets your roles by the engine's holistic quality **grade**, so you know where to start:

| Tier             | Grade        | Meaning                                                                                                      |
| ---------------- | ------------ | ------------------------------------------------------------------------------------------------------------ |
| **Ready**        | Recommended  | High-quality roles that align cleanly and are safe to adopt as-is.                                           |
| **Needs review** | Needs review | Roles that are plausible but warrant a human look before adoption.                                           |
| **Low signal**   | Noise        | Leftover or residual access that did not consolidate cleanly and should not be treated as an adoptable role. |

Readiness counts let you measure progress: as you formalize high-confidence roles and remove drift, more of your posture should land in **Ready**.

{% hint style="info" %}
The role **grade** (Recommended / Needs review / Noise) is the engine's *should-you-adopt-this* judgment and blends confidence, alignment, and support. It is distinct from the Role Risk Factor, which measures *how risky* the access is. A role can be Recommended for adoption and still carry meaningful risk worth reviewing.
{% endhint %}

### Posture at a glance

The consolidation view also summarizes your overall RBAC health — a posture grade computed from the engine's composite signals, the number of open recommendations, standing separation-of-duties exposure, and dormant privileged access. These KPIs give leadership a single read on whether the RBAC posture is improving over time as remediation work lands.

### Putting it together

The intended workflow is:

1. Review **Current State** to understand where access stands today.
2. Switch to **Ideal State** to see the least-privilege target and the lifecycle of each role.
3. Use **Adoption Readiness** to start with the roles that are ready, and the consolidation funnel to quantify the reduction.
4. Apply the changes in your IdP and re-run the analysis to confirm the current state moves toward the ideal.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.balkan.id/iam-risk-analyzer/rbac-analyzer/current-and-ideal-state-rbac.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.