You're auditing an access management procedure and you see two rules: the person approving access can't be the one provisioning it, and the approver can't have access to the system themselves. The intent is clear enough. But then you look at how it's enforced — email threads, an honor system, and an IT admin who could skip the approval step entirely and nobody would know until the next audit. The controls are sound in theory. The enforcement mechanism is the problem.

What Segregation of Duties in Access Provisioning Is Actually Trying to Prevent

Segregation of duties (SoD) in access provisioning is about preventing a single individual from having end-to-end control over a system — the ability to request, approve, and provision access all without independent oversight. When one person controls the full chain, the opportunities for unauthorized access, privilege escalation, and fraud multiply significantly. A system owner who can approve their own access requests and then provision them has no check on what they grant themselves or others.

The first rule in the procedure — approval and provisioning must not be performed by the same individual — is the cleaner of the two controls and the one with broader consensus. What you're trying to ensure is that the decision to grant access and the act of granting it are separated into two distinct roles, so that neither party can complete the process alone. As one commenter in the original thread noted, the relevant question is whether access was approved and documented before provisioning happened and whether what was granted matches what was approved — the specific individuals involved matter less than the separation itself.

The second rule — the approver must not have access to the system themselves — is more contested, and the thread discussion reflects that. The concern it's addressing is conflict of interest: if an approver actively uses and understands a system, they might be more likely to approve access for colleagues they work with, or exploit the approval role to gain elevated permissions without independent scrutiny. In mature identity governance frameworks, any situation where a user might be in a position to review or approve their own access gets flagged automatically and rerouted to a different approver — a different department head, a security team member, whoever is structurally removed from the access decision.

The counterargument, raised clearly in the thread, is that approvers who don't understand the system they're governing aren't in a position to make competent approval decisions. Both points are valid, and most mature implementations resolve it by requiring that approvers don't have admin access rather than no access at all — distinguishing between someone who uses a system and someone who can administer it.

Why Manual Enforcement Via Email Creates the Gaps It's Trying to Close

Email approval chains are the most common implementation of access governance at organizations that haven't formalized their IGA processes, and they have a specific and predictable failure mode: they depend entirely on the IT admin choosing to follow them.

The problem isn't that email is an inherently bad audit medium. A documented email trail can satisfy an auditor's requirement for evidence of prior approval if the records are complete and retrievable. The problem is that the step is voluntary. An IT admin who receives an access request and needs to act quickly — or simply forgets the process — can provision the user directly without waiting for the approval email, and the system has no mechanism to prevent it. The control exists on paper. Whether it exists in practice depends on whether the provisioner follows it every time, under time pressure, across hundreds of access requests.

The compliance exposure here is specific: during an audit, if provisioning timestamps precede approval timestamps — or if there's no approval email to retrieve at all — the control fails. Not because someone acted maliciously, but because a manual process didn't hold under operational pressure. Bottlenecks accumulate, inconsistencies compound, and audit friction becomes a recurring problem rather than an edge case.

The deeper issue is that email approvals produce no structured data. There's no queryable record of who approved what, when, for which system, and under what conditions. Reconstructing that picture from an inbox search is time-consuming and unreliable. It's the kind of process that looks functional until an auditor asks for the access log for a specific system over the past 12 months and the answer involves someone manually searching through email threads.

How Automated IGA Enforces SoD Controls That Email Can't

The shift from email-based approval workflows to automated identity governance closes the gap between the control as written and the control as enforced. The mechanism is structural: provisioning cannot occur until the system registers the required approvals. The IT admin doesn't check an email and then decide whether to proceed — the provisioning step is gated by the approval state in the platform.

Zluri enforces this through hardcoded approval workflows. When an access request is submitted, the platform routes it automatically to the designated approvers — manager, app owner, security head, or any multi-stage combination the organization defines. The provisioning action is blocked until each required approval is recorded. There's no honor system, no manual check, and no path for an admin to skip the step under pressure.

SoD conflict detection runs at the point of request submission, before any approval or provisioning occurs. If an incoming access request would create a conflicting combination of permissions — a user gaining both the ability to submit and approve purchase orders, for example — the system flags it immediately and either blocks the request or routes it for elevated review. The violation is caught before it becomes a provisioning event rather than discovered during an audit cycle.

The audit trail this produces is structurally different from an email chain. Every action — request submission, approval decision, provisioning event, access modification — is logged with a timestamp, the identity of the actor, and the specific permission or role involved. That record is immutable and queryable. When an auditor asks for the access history on a specific application for the past year, the answer is a report, not an inbox search.

For organizations where the approver-has-system-access concern is relevant, Zluri's approval routing can be configured to automatically reassign approval tasks when the designated approver has a conflicting access profile — routing to a peer, an escalation contact, or a security team member without requiring manual intervention to identify the conflict.

What Good Access Governance Actually Looks Like in Practice

The r/sysadmin thread raised a practical question worth addressing directly: what's wrong with having a single system owner responsible for managing all access to a system, where that one person both approves and provisions? The answer from the thread — and it's correct — is that a single point of control is also a single point of failure and a single point of potential abuse. Even with full documentation, a system where one person can create accounts, grant permissions, and approve their own decisions has no independent check on what that person does. Fake accounts, unauthorized elevations, and access granted to people who shouldn't have it are all possible without any external detection mechanism.

What good access governance looks like is separation that's enforced by the system rather than assumed from process. Approval and provisioning are distinct actions performed by distinct roles. SoD conflicts are detected and flagged automatically before they become provisioning events. The audit trail captures the full lifecycle of every access decision without requiring anyone to reconstruct it manually. And periodic access reviews — checking that what's currently provisioned still matches what should be provisioned — catch drift before it compounds into a compliance finding.

The email approval process isn't wrong in intent. It's just a manual implementation of a control that works better when the system enforces it structurally.

Frequently Asked Questions

What is segregation of duties in IT access provisioning?

Segregation of duties (SoD) in access provisioning means separating the roles involved in requesting, approving, and granting system access so that no single individual controls the full chain. The goal is to prevent unauthorized access grants, privilege escalation, and fraud by requiring independent oversight at each stage of the access lifecycle.

Why is email approval insufficient for access governance compliance?

Email approvals depend on manual compliance — the IT admin must choose to follow the process every time. There's no system-level gate preventing provisioning before approval, no structured audit trail, and no detection mechanism for cases where the step was skipped. During an audit, reconstructing the approval chain from email records is unreliable and time-consuming.

How does automated IGA enforce segregation of duties?

Automated IGA platforms gate provisioning actions behind approval states in the system — access can't be granted until the required approvals are recorded. SoD conflict detection flags problematic access combinations at the point of request submission. Every action is logged in an immutable, queryable audit trail rather than scattered across email threads.

What happens when an approver has access to the system they're approving?

In mature IGA implementations, this is handled through automatic approval rerouting — the system detects the conflict and reassigns the approval to a structurally removed role (peer reviewer, security team, escalation contact) without requiring manual intervention. The control is enforced by the platform rather than relying on the approver to recuse themselves.

See How Zluri Enforces Access Governance Without the Email Trail

Most organizations that rely on email approvals discover the gap during an audit rather than before it. See how Zluri's automated access workflows enforce SoD controls structurally — gated provisioning, conflict detection, and an audit trail that's ready when the auditor asks.