How do organisations implement segregation of duties (SoD) in IAM?

How SoD should be built into IAM design

segregation of duties in IAM starts with separating the business rule from the technical control. The organisation has to define which combinations of roles, entitlements or transactions are incompatible, then express those conflicts in role models, access policies and approval rules. That matters because SoD fails when it exists only as a policy statement and not as an enforceable identity rule.

In practice, SoD works best when it is designed around the actual workflows that create fraud, error or self-approval risk. A role catalogue should reflect those conflict points, and identity governance should reject or flag requests that would place one person in both sides of the control. NHIMG’s IAM and IGA Basics covers how access governance, role design and access reviews fit together, while the Segregation of Duties (SoD) Guide is the most direct reference for building and enforcing conflict rules.

SoD also needs to account for exceptions that are operationally necessary but risky. Emergency access, shared admin paths and temporary overrides should be treated as controlled deviations, not normal access patterns. If those pathways are not explicitly time-bound, approved and reviewed, the SoD model weakens even when the base role design is sound.

Where SoD failures usually show up

The most common failure is role accumulation. A user gradually collects enough entitlements through job changes, project work or temporary access that the original SoD boundaries are no longer visible. Another common failure is overlap hidden in composite roles, where no single assignment looks risky but the combined access creates a toxic combination.

SoD can also break when organisations rely on manual approval alone. Approvers may not see the full access graph, especially when entitlements are spread across systems. That is why review processes need to compare current access against conflict rules, not just confirm that someone clicked approve. The Ultimate Guide to NHIs, Regulatory and Audit Perspectives is useful here because it frames access review, auditability and governance obligations as part of the control rather than an afterthought.

SoD issues also appear in non-standard access paths, such as service accounts, automation credentials and break-glass accounts. If those identities can initiate, approve and execute the same sensitive workflow, the organisation has recreated the same conflict outside the human user model. That is why SoD design needs to span both workforce access and machine-held privilege.

When the control environment is cloud-heavy or tightly integrated with vendors, it helps to map SoD to a broader identity control baseline. The CSA Cloud Controls Matrix provides a useful external control reference for IAM and governance in cloud settings, where roles, delegated administration and access review must stay aligned across multiple platforms.

How to make SoD enforceable, not just documented

Enforcement depends on three things: a clear conflict matrix, a request-and-approval workflow that checks that matrix, and a periodic review cycle that catches drift. If the governance tool cannot evaluate the conflict before access is granted, SoD becomes a detective control only, and by then the exposure has already existed.

The strongest implementations push SoD checks as early as possible in the lifecycle. That means checking new access requests, role changes and exception grants at the point of change, then revisiting the same conflicts during recertification. NHIMG’s Lifecycle Processes for Managing NHIs is relevant because the same lifecycle logic, provisioning, rotation, offboarding and review, applies whenever access is governed through managed identities or shared credentials.

For organisations with high-risk administrative estates, SoD should be paired with least privilege and strong admin separation. The Active Directory and Entra ID Hardening Guide is a practical companion where privileged groups, delegation and admin boundaries can undermine SoD if they are left too broad.

SoD in IAM is successful when the control is visible in daily operations: requests are blocked before conflict, exceptions are time-limited, and reviews produce evidence that incompatible access is being removed rather than tolerated. If an organisation cannot show that pattern, it likely has policy language, not SoD.

Risk and Threat Considerations

SoD weakness creates a direct fraud and abuse pathway because one identity can both create and approve a sensitive action, or both administer and conceal it. The risk is highest where emergency access, shared accounts or stale elevated access are allowed to persist without tight review.

Failure mechanism: Conflicting entitlements accumulate across roles, privileged groups or machine credentials, and the IAM stack fails to detect that a single identity can now complete an end-to-end sensitive workflow alone.

Impact: Unauthorised approvals, concealed changes, fraudulent transactions, privilege abuse and weaker audit assurance can follow, especially in finance, ERP, cloud admin and other high-trust systems.

Practitioner Guidance

What to verify: Confirm that the SoD ruleset covers both direct role conflicts and effective access after role aggregation, inherited permissions and emergency elevation. Then test it against real access requests, not just the published role catalogue.

What to prioritise: Start with the few access combinations that can cause the most damage if self-approved or self-executed. In most environments, that means finance, production administration, security administration and any workflow where a single identity can create, approve and release value.

Common mistake: Treating periodic certification as sufficient on its own. Reviews are necessary, but without preventive checks at request time, SoD violations can exist long enough to matter and then survive because everyone assumed the review would catch them later.

Practitioner takeaway: Good SoD is a control design problem, not a reporting exercise, and it only works when the IAM platform can block incompatible access before it becomes operational access.

Related resources from NHI Mgmt Group

• How should organisations build a segregation of duties matrix for modern IAM programs?
• How should organisations implement segregation of duties in hybrid environments?
• How should security teams implement segregation of duties in IAM workflows?
• How should organisations implement segregation of duties in accounts receivable?