Three specific, predictable failure points that most access governance frameworks were never built to catch, and why they tend to show up together.

Identity Governance | Access Risk | SoD | Enterprise Security

There's a pattern that plays out in access governance that's almost clockwork. Controls get put in place. Reviews get scheduled. Audits pass. And then, somewhere in the space between systems and cycles and manual follow-through, access slips out of sight.

Not dramatically. Not all at once. In the small, accumulated ways that don't trigger alerts: an account that outlives an employee, a permission combination nobody thought to flag, a contractor whose engagement ended but whose credentials didn't. These aren't edge cases. They're the default outcome when governance is periodic and access is continuous.

In our last post, we laid out why fragmented environments make this so hard to solve at the infrastructure level. Here, we go one level deeper, into the three specific failure points where access risk consistently shows up, and why they almost always coexist.

Problem 01: Ghost access

The accounts that outlived the people who owned them

An employee leaves. A contractor's engagement ends. A role changes, and the old one becomes redundant. In each case, the expectation is that someone will follow up, revoke access, close the account, clear the credentials. In practice, that follow-up depends on a manual process, a ticket, a notification that reaches the right person at the right time. It often doesn't happen.

Orphaned accounts don't announce themselves. They sit inactive, sometimes for months, sometimes for years. They don't trigger alerts. They don't show up in dashboards unless someone specifically goes looking. And because they're tied to identities that no longer exist in the HR system, they occupy a grey zone, technically present in the application, but owned by nobody.

The risk isn't hypothetical. An unmanaged account is an unmonitored entry point. Whether the threat is external, a credential that gets compromised, or internal, a former employee who retains access they shouldn't, the exposure is real and measurable.

"The most dangerous access in your environment isn't the access someone abused. It's the access nobody remembered to remove."

What makes this problem particularly difficult to solve with traditional tooling is that the fix requires connecting HR data, application access records, and identity management in real time. When those systems don't talk to each other, which is the default in most enterprises, orphaned accounts accumulate faster than any manual cleanup effort can keep pace with.

Problem 02: SoD violations

The conflicts that build up one approval at a time

Segregation of Duties exists for a reason. When the same person can initiate a payment and approve it, create a vendor and authorize a transaction, access a system and modify the audit log, the controls that governance frameworks depend on cease to function. The checks and balances that should exist in the process exist on paper only.

The challenge is that SoD violations rarely happen in a single, obvious moment. They accumulate. Someone gets temporary access to cover a colleague's leave. A role is expanded during a project, then never wound back. A new application is onboarded and its permissions aren't mapped against existing roles in other systems. Each individual decision seems reasonable in isolation. The problem only becomes visible in aggregate, usually during an audit, and usually at the worst possible time.

What makes SoD particularly difficult to govern at scale is that conflicts span systems. An employee might have the ability to approve payments in one platform and initiate them in another. No single system flags that combination. Only a cross-system view of access, one that runs conflict checks before access is granted, not after the fact, can catch these before they become findings.

Before
SoD conflicts discovered during audit cleanup cycles

After
SoD checks run automatically at the point of access request

Always
Policies enforced in real time, not reviewed periodically

The difference between catching a conflict before access is granted versus discovering it three months later is not just operational. It's the difference between a governance control that works and one that exists only on paper.

Problem 03: External identities

The contractors, vendors, and auditors your governance framework wasn't built to see

Most access governance frameworks were designed with one assumption baked in: the people they govern exist in the HR system. Employees do. Contractors, auditors, third-party vendors, and implementation partners often don't, and that gap is where some of the most significant access risk lives.

External identities get onboarded quickly, often informally, and typically with broad access granted to meet an immediate need. The intention is always to review and restrict once the engagement is underway. In practice, that review rarely happens on schedule, if it happens at all. Access that was granted for a six-week implementation project gets renewed, forgotten, or simply left in place because nobody owns the process of tracking it.

The volume compounds the problem. A mid-size enterprise might have hundreds of active contractors and vendor accounts at any given time, each with different engagement scopes, different access requirements, and different end dates. Managing that manually is not sustainable. And because these identities sit outside the HR system, they're invisible to the same governance workflows that cover internal employees.

"External identities are not an edge case. For most enterprises, they represent a significant share of active access, and almost none of it is governed the same way as internal access."

The answer isn't a separate governance process for external identities. It's bringing them into the same control layer as everyone else, with access scoped to engagement, reviewed continuously, and deprovisioned automatically when the relationship ends.

Three problems, one connected root cause

Orphaned accounts, SoD violations, and ungoverned external identities look like separate issues. But they share a common origin: access governance that operates in silos, reacts to events after the fact, and relies on manual follow-through to close the gaps.

That's the environment most enterprises are actually operating in, not by choice, but because the tooling they have was built for a cleaner, more standardized world. Patching individual gaps with point solutions doesn't change the underlying dynamic. It just adds more complexity to an already fragmented picture.

User Access Management by moderor.ai was built for this reality. It connects across heterogeneous environments, brings external identities into the same governance framework as internal ones, runs SoD checks before access is granted rather than after, and deprovisions orphaned accounts automatically when an employment or engagement ends. Not as three separate modules, but as a single, unified control layer.

Because access risk doesn't respect the boundaries between systems. The governance framework shouldn't either.