Segregation of duties vs user access review in identity governance

At a glance

What this is: This article separates segregation of duties from user access reviews, showing that one is preventive and the other is detective.

Why it matters: IAM and IGA teams need both controls because provisioning-time conflict checks and post-provisioning access recertification solve different governance problems.

Context

Segregation of duties and user access reviews are two different access governance controls, not two names for the same process. One acts before access is granted and the other acts after access exists, which is why conflating them creates blind spots in identity governance.

The article sits squarely in IAM and IGA practice because the problem is lifecycle drift: roles change, contractors leave, and temporary permissions linger. That makes the distinction relevant to human access governance as well as any environment where access is provisioned, reviewed, and revoked over time.

Auditors typically look for both controls because prevention without review leaves stale access in place, while review without prevention allows conflicting access to be granted in the first place. The control gap is not theoretical. It shows up in manual processes, weak evidence, and unresolved risk cycles.

Key questions

Q: What breaks when segregation of duties checks are handled outside the provisioning workflow?

A: When SoD checks sit outside provisioning, conflicts can be introduced before anyone notices, or approved later without full context. That creates delayed remediation, inconsistent enforcement, and audit exposure. Embedding SoD controls into the workflow helps stop risky access earlier, before it becomes operational access that must be unwound after the fact.

Q: How do access reviews help with segregation of duties?

A: Access reviews help by revealing conflicts that already exist, but they do not prevent those conflicts from being created. They work best when paired with preventive SoD checks in the request workflow. Used alone, reviews become a cleanup mechanism after privilege drift has already occurred.

Q: How can teams tell whether access governance is actually working?

A: Look for short revocation times, low rates of stale entitlements, and repeatable access review outcomes across systems. If accounts remain active after role changes or offboarding, governance is not effective. Good measurement focuses on whether access is removed when it stops being justified.

Q: What should organisations do when SoD conflicts and stale access both appear in the same programme?

A: Treat the problems separately but govern them together. Fix the provisioning logic so conflicting access is blocked, then clean the existing population through access reviews and removal workflows. A combined model closes both the creation path and the drift path, which is the only durable way to reduce audit findings and operational risk.

Technical breakdown

How segregation of duties blocks conflicting access at provisioning

Segregation of duties, or SoD, is a preventive rule set applied when access is requested or assigned. It checks whether a user would hold two permissions that create an unacceptable conflict, such as creating and approving the same financial transaction. In identity governance, the control is usually encoded as policy logic that evaluates roles, entitlements, and approvals before the access change is committed. The key technical point is that SoD is not about proving access is still needed. It is about stopping structurally risky combinations from ever becoming active in the system.

Practical implication: define conflict rules in provisioning workflows so risky combinations are blocked before access is granted.

How user access reviews detect access drift after the fact

User access reviews, often called UAR, operate as a detective control over existing access. Managers or application owners compare current entitlements with current job function, then decide whether each permission still belongs. The technical challenge is not just checking a list. It is establishing ownership, collecting evidence, and turning review decisions into revocation or recertification actions. This control catches access creep, orphaned accounts, and contractor access that outlives the work it was intended to support. It does not prevent the original grant, but it is how governance systems recover control once drift has started.

Practical implication: schedule review campaigns with clear approvers, evidence capture, and removal actions for unneeded access.

Why manual review processes break at scale

Manual SoD checks and spreadsheet-based access reviews look manageable in small environments, but they fail when access spans multiple applications, cloud services, and third-party systems. At that point, policy logic becomes inconsistent, approvals are delayed, and evidence fragments across email threads and static reports. The governance problem is not simply effort. It is reliability. If the process cannot produce repeatable decisions and audit-ready records, the organization has control activity without control assurance. That is why mature programmes move from ad hoc administration to governed workflows with traceable decisions and system-enforced checks.

Practical implication: replace spreadsheet governance with workflow-based evidence, repeatable approvals, and system-enforced control checks.

Threat narrative

Attacker objective: The objective is to exploit contradictory or stale access to perform actions that should have been blocked or removed.

1. Entry occurs when access is provisioned with a conflicting permission set or an unnecessary entitlement that bypasses governance checks.
2. Escalation follows when the user can combine permissions that should have been separated, creating an opportunity for fraud or improper self-approval.
3. Impact appears as stale access, unresolved audit findings, and operational exposure that remains in place until the next review cycle.

Breaches seen in the wild

• Internet Archive breach 2024: An exposed GitLab token opened Internet Archive code and 31 million user records; unrotated Zendesk tokens let the attacker back in weeks later.
• Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

SoD and user access review fail in different places, so they cannot be substituted for one another: SoD is designed to stop a conflicting entitlement before it exists, while user access review is designed to challenge access that already exists. The governance error is treating prevention and recertification as equivalent because they both touch access records. Mature identity governance needs both lifecycle checkpoints, or it leaves either conflict risk or access drift unaddressed.

User access review is the control that exposes lifecycle decay in identity programmes: the longer access lives beyond role change, contractor departure, or project completion, the less meaningful the original approval becomes. That is why review evidence matters as much as review activity. In audit terms, the question is not whether someone looked at access, but whether the organisation can prove that stale access was actually identified and removed.

Segregation of duties is a policy design problem, not a documentation exercise: if the conflict rule is missing or weak, the risk is created at provisioning time and no later review fully erases that exposure. This is why SoD belongs in the entitlement decision path, not only in periodic compliance reporting. The practical implication is clear: the control must live where access is granted, not where it is later explained.

Identity governance becomes materially stronger when preventive and detective controls are chained together: the control loop starts with SoD at request time and ends with user access review at validation time. That combined model reduces both bad grants and stale grants, which is what auditors and business owners actually need. The point is not more process for its own sake. The point is to make access state continuously defensible.

Access reviews are the named concept most teams underestimate: they are the only part of the process that can surface permissions that once made sense but no longer match reality. Without that second checkpoint, access control becomes a snapshot instead of a governance system. Teams should treat access review cadence as a core governance design decision, not an administrative afterthought.

From our research library:

• Over 70% of organisations lack automated access risk analysis, user access reviews and provisioning and deprovisioning, according to Pathlock's 2025 Digital Transformation and Access Risk Report.

What this signals

Access governance fails when teams rely on one checkpoint and ignore the other: SoD protects the point of assignment, while user access review protects the state of access after work and roles change. Programmes that separate those controls operationally tend to produce blind spots, because neither control can fully compensate for the missing stage.

Identity governance should be designed as a lifecycle loop, not a one-time approval path: provisioning checks stop conflicts early, and review cycles prove that the access still belongs later. That combined pattern is what turns access control into governance, rather than a periodic administrative exercise.

Auditability is the real differentiator between mature and immature access controls: if an organisation cannot show who reviewed what, when, and why, then it cannot demonstrate that SoD and recertification are more than policy statements. The operational signal is not volume of review activity, but whether decisions actually change access state.

For practitioners

• Embed SoD checks in provisioning workflows Evaluate every access request against conflict rules before approval so risky combinations are blocked at assignment time, not cleaned up later.
• Run evidence-backed user access reviews Assign each review to a named owner, capture the decision, and remove or recertify access immediately after the review outcome is recorded.
• Prioritise high-risk roles and privileged access Review finance, admin, and sensitive-data entitlements more frequently because those roles create the highest exposure when drift or conflict appears.
• Replace manual tracking with governed workflows Use repeatable workflow steps for approvals, recertification, and evidence retention so audit proof is consistent across applications and review cycles.

Key takeaways

• Segregation of duties and user access reviews solve different parts of the same access problem, so treating them as interchangeable weakens governance.
• The main risk is lifecycle drift: conflicting access can be granted at provisioning, and unnecessary access can persist long after the need has passed.
• A durable programme pairs preventive conflict checks with evidence-backed access reviews and documented removal actions.

Key terms

• Segregation of Duties: Segregation of Duties is a control principle that prevents one person or role from combining incompatible permissions that could create fraud, error, or undetected change. In ERP environments, it must account for roles, transactions, approvals, and compensating controls across business processes.
• User Access Review: A user access review is a periodic check that confirms each account still needs the access it has. In identity programs, the control is used to reduce excess privilege, support compliance, and catch access that has outlived its business need.
• Answer Drift: Answer drift is the gradual change in a model’s responses over time, often showing up as reduced consistency or increasing error rates. It can signal degraded grounding, shifting data quality, or prompt and retrieval issues. Monitoring drift helps teams catch reliability problems before they become widespread user-facing failures.
• Audit Evidence: Audit evidence is the record set used to prove that access was authorised, limited, and revoked according to policy. For modern identity programmes, evidence must come from runtime logs, approval events, and lifecycle records rather than from manual spreadsheets assembled after the fact.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.