Drift Happens. The Problem Is Everyone Pretends It Doesn’t

Most identity and access tools are built on a comforting assumption: your access model is tidy. Your groups make sense. Nobody bypasses the system. Everyone logs in through the approved IDP. Reality is messier.

Identity and access are always drifting. Someone grants temporary access for a project. An admin adds a contractor directly in Google. A manager shares a folder with an external agency. A team spins up a new SaaS app and just clicks Sign in with Google. None of this respects your perfect RBAC structure. It never has.

The problem is not that drift exists. The problem is that every traditional IAM platform hides it.

The truth nobody wants to say out loud

IDPs only show you drift inside the boundaries they control. If an app uses SAML through Okta, you see it. If it uses OAuth through Google, that drift is invisible. If it uses native roles inside Salesforce, that is invisible. If an admin bypasses the IDP entirely, you only discover it during an audit or after something breaks.

The drift was already there. You just didn’t see it.

The industry assumption that never worked

RBAC and groups were designed for a world that barely moves. The original assumption was a static org chart and predictable access lifecycles. Today, real companies change constantly. Reorgs. Contractors. Agencies. Temporary access. Shadow apps. None of this was part of the model. So the model breaks.

Roles were never the issue. The way we implemented them was.

Groups pick up scar tissue

Every environment eventually has thousands of groups. Google, Entra, Okta, Slack, Atlassian. They accumulate purpose and lose meaning. They route email. They grant access. They map to applications from five years ago. They include external users nobody remembers. They drift silently.

Exceptions are normal

Temporary access is the rule, not the exception. Projects happen. Contractors need privileges. Engineers move teams. Someone needs elevated access for a one time incident. Classic RBAC treats every exception like a violation. So teams either ignore drift or mutate groups until nobody understands them.

Security and IT both lose control

Security wants policy enforcement. IT wants to keep things moving. The tools give them no nuance. Fix the role. Ignore the drift. Create another group. None of these approaches understand why drift happened or how long it should last.

Reviews happen at the wrong time

Most access reviews are tied to compliance cycles, not real events. That means reviews are late, painful, and disconnected from actual risk. The better moment to review is when something changes:

• someone changes departments
• someone moves from contractor to FTE
• someone is offboarded
• a risky group gains new external members

This is when drift matters most.

Introducing Drift as a First Class Identity Concept

YeshID assumes drift exists. We track it and help you manage it. Drift is not corruption. Drift is reality.

The Drift Report

YeshID is introducing a new concept: Drift Reports. They show what changed, why, and whether that change is acceptable. They also distinguish intended drift from accidental drift. Acceptable drift is not a security failure. It is a sign that your business is functioning.

You decide what drift is acceptable

With YeshID, you define:

• allowed drift
• temporary drift
• drift that needs approval
• drift that should auto expire
• drift that should trigger review
• drift that is safe and intentional

You stay in control without pretending the world is static.

Time based overrides

Temporary access rolls off automatically. You do not need a new permanent group or role mutation. The access simply expires.

Reviews triggered by real events

Reviews happen when the world changes, not when compliance forces it.

Groups become Access Sets

In YeshID, a group is not just a bucket of users. It becomes structured identity metadata. It maps to Google, Microsoft, Slack, or any SaaS system. It can be dynamic. It can show drift clearly. You see what changed and why.

Separation of provisioning and enforcement

Legacy IAM assumes the provisioning system should also enforce policy. In YeshID, these are separate:

• Access Sets: what a person should have
• Enforcement: the guardrails
• Workflows: how change happens
• Drift controls: how reality is monitored

IT can operate safely. Security can govern without blocking. Everyone sees the same truth.

The future of RBAC is cleaner roles and safer drift

Roles and groups are not going away. They remain the backbone of access. But the old implementation no longer fits how modern companies operate. YeshID is building an identity system that:

• accepts that things change
• treats drift as normal
• gives teams visibility
• keeps roles healthy
• keeps people productive
• keeps the organization safe

This is identity that matches how real companies work. Not how old systems pretended they worked.