Why People Hate Roles and Groups — And How We’re Doing It Differently

Every IT and security team has the same confession: they secretly hate roles and groups. They won’t always say it out loud, because these systems are supposed to be the backbone of access governance. But the truth is, the way roles and groups have been designed for the last decade makes day-to-day operations harder, not easier.

It isn’t because roles and groups are bad ideas. It’s because the tooling around them froze in time.

Why do people hate roles and groups?

They were built for a world where nothing changed

Most RBAC systems assume a clean, stable org chart and a predictable lifecycle. But today, companies change structure every quarter. Teams spin up, dissolve, reorg, merge, and rename. People move between roles faster. Contractors come and go. Shadow apps appear weekly.

The idea that you can build “the perfect set of roles” and walk away is fiction.

Groups accumulate “scar tissue”

Google Groups. Okta groups. Entra groups. Slack user groups. Atlassian groups. Every environment ends up with thousands of them. And every one of those groups becomes the plumbing of everything else: SAML apps, OAuth scopes, shared folders, email routing, channels, alerts.

Over time:

• owners disappear
• external partners stick around
• group names lose meaning
• app-specific mappings drift
• nobody knows which groups matter and which were created for a launch two years ago
  

Groups do not age gracefully. They rot silently.

RBAC is treated as law, not intention

RBAC was always supposed to describe an ideal state: “This is who should have access if the world is tidy.” But the world is not tidy.

During real operations, exceptions happen:

• temporary access for a project
• contractor needs three extra permissions
• engineer switched scrum teams
• external agency gets access for a demo
• someone gets an elevated role for an incident

Those exceptions create drift. And drift is not a failure. Drift is real life. But legacy systems treat drift like corruption. So you’re stuck between ignoring reality or endlessly rebuilding the “official” model.

IT and security have no shared control over drift

Security wants policy enforcement. IT wants things to keep moving. Both want visibility. Neither wants to fight over whether a single permission breaks all of RBAC.

Most tools give them the same blunt instruments:

• “Fix the role” (which breaks onboarding)
• “Ignore it” (which causes risk)
• “Add another group” (which just creates more sprawl)

No nuance. No staging. No time-based overrides. No understanding of why drift happened.

Reviews happen at the wrong time

Everyone knows roles and groups should be reviewed. But most tools force reviews only during:

• annual access reviews
• quarterly audits
• compliance cycles

Those reviews are slow, exhausting, and disconnected from reality.

What teams actually want is:

• review when someone changes roles
• review when someone switches departments
• review when a contractor ends
• review when an external partner is added to a risky group
• review when drift exceeds what was intended

These moments matter more than anything an auditor ever schedules.

How YeshID is doing it differently

RBAC as an ideal state, not a rigid system

We treat roles and groups as the baseline—the approved model of how access should work. It’s a starting point, not a prison. You can build your clean structure, but it doesn’t collapse the moment reality deviates.

Drift is first-class

We assume drift will happen.
We track it.
We show it.
We help you control it.

You decide:

• what drift is allowed
• what drift is temporary
• what drift should trigger a review
• what drift should auto-revoke
• what drift needs approval
• what drift is safe and expected

Drift becomes something you manage, not something you fear.

Time-based overrides baked in

Temporary access shouldn’t pollute the role forever. If someone needs elevated access for 48 hours, it should automatically revert without creating a new “special” group or permanently mutating the role.

Reviews that happen at the right time

We let you schedule reviews based on changes in reality, not compliance cycles.

Reviews can trigger when:

• someone changes roles
• someone changes teams
• someone is offboarded
• someone moves from internal to external or vice-versa
• a group suddenly gains more external members
• a group suddenly expands its effective permissions
  
  

This is how access should be reviewed: in context, not on a fixed calendar.

Groups become “access sets” with structure

In YeshID, a group isn’t just a bucket of people. It has meaning:

• it can map to Google
• it can map to Microsoft
• it can map to Slack
• it can map to any connected app
• it can be dynamic
• it can show drift clearly

You’re not managing floating objects. You’re managing an identity-driven graph.

Separation of provisioning vs enforcement

One of the biggest flaws in legacy IAM is assuming the thing that provisions access is also the thing that enforces security.

YeshID separates:

• Access Sets: what access someone should get
• Policy Enforcement: internal rules and external triggers
• Workflows: how changes happen
• Drift Controls: how reality gets monitored

IT can operate safely. Security can govern without blocking. Both can see the same truth.

The future: cleaner roles, safer drift, fewer surprises

Roles and groups are not going away. They’re foundational. But the old way of managing them—static RBAC, endless groups, brittle policies—simply doesn’t match how modern companies actually work.

YeshID is building an identity system that:

• accepts that things change
• understands that drift is normal
• gives teams the power to review drift at the right time
• keeps the ideal state healthy
• keeps the real world safe
  
  

You get the best parts of RBAC—fast onboarding, predictable provisioning—without the rigidity that made people hate it.

This is identity that works the way companies work today.