Join our Newsletter — 33% off our NHI Course
Home› FAQ› Governance, Ownership & Risk› How should organisations use modern identity governance to…
Governance, Ownership & Risk

How should organisations use modern identity governance to reduce separation of duties risk across complex access models?

← Back to all FAQ
By NHI Mgmt Group Editorial Team Updated September 27, 2026 Domain: Governance, Ownership & Risk

Organisations should use modern identity governance to enforce separation of duties through policy-based controls, role management, access reviews, and auditability. The goal is to prevent conflicting permission combinations before they are granted, then continuously remove dormant, orphaned, or unused access. When access is limited to what people and systems actually need, breach likelihood and blast radius both drop materially.

How identity governance reduces SoD risk in mixed human, system, and application access

Separation of duties fails most often when access is granted as isolated entitlements instead of as a whole permission picture. Modern identity governance reduces that risk by evaluating toxic combinations across roles, attributes, application entitlements, and non-human access paths before they are approved. It also keeps the model current as people move roles, systems change, and privileges accumulate.

The practical shift is from periodic cleanup to continuous policy enforcement. Rather than asking only whether a user or system can do a task, identity governance asks whether that access would conflict with another duty somewhere else in the process. That is what makes SoD workable in complex access models.

Where SoD control breaks down in modern access models

Complex environments create SoD risk because the same outcome can be reached through multiple paths: direct permissions, group membership, inherited roles, temporary elevation, delegated administration, shared accounts, and machine credentials. If governance only reviews one layer, a conflicting combination can survive even when each individual grant looks harmless.

Role explosion and role drift make the problem worse. As roles are copied, exceptions are added, and business exceptions become permanent, the access model stops reflecting actual duties. Role mining and role design discipline helps because the role structure has to stay intelligible enough for SoD rules to remain enforceable. When the model becomes too fragmented, manual review degrades into box ticking.

Identity governance also has to follow access through the full lifecycle. Joiner, mover and leaver processes matter because SoD risk often appears when old access is not removed after a job change, or when dormant access is left in place after departure. In practice, stale access is as dangerous as obviously excessive access because it preserves conflicting privilege combinations long after business need has changed.

What modern identity governance should do before and after access is granted

Effective SoD control starts with policy, but it only works if policy is operationalised into the access request and access review flow. Conflicts should be checked before approval, not discovered later in a recertification campaign. That means modelling prohibited combinations, allowed exceptions, and compensating controls in a way the workflow engine can actually enforce.

Access reviews are the backstop, not the primary control. Access reviews and certification should be used to remove access, not just to confirm it exists. The most useful reviews focus on high-risk combinations, orphaned entitlements, and access that no longer matches current job function. If a review cannot drive removal, revocation, or formal exception handling, it does not materially reduce SoD risk.

For complex environments, a good IGA programme also needs clear ownership. Business owners should define which combinations are unacceptable, while platform teams maintain the technical pathways that enforce those rules. IGA platform selection and implementation becomes important when organisations need connectors, workflow, and evidence collection across many systems, because SoD controls fail when parts of the access estate remain invisible.

Why SoD governance is also a monitoring and audit problem

SoD is not a one-time design task. Every exception, emergency elevation, service account, and delegated workflow can create a new path around the policy. That is why modern identity governance has to produce evidence: who approved the exception, what compensating control exists, when it expires, and whether the access is still justified.

Auditability matters because SoD risk is often judged by whether an organisation can prove that conflicts were prevented or managed, not simply whether a policy exists. Segregation of duties rulesets and mitigating controls are especially useful where the business cannot fully separate duties, because the control objective shifts from perfect separation to controlled, documented exception handling.

Complex access models also require visibility across human and non-human identities. Service accounts, bots, and agents can carry privileges that bypass normal employment-based controls, so SoD governance must follow the actual authority path rather than the job title alone. Visibility and over-privilege risks are often the hidden failure mode when identity governance stops at workforce accounts.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 and SOC 2 (AICPA) define the regulatory obligations.

FrameworkControl / ReferenceRelevance
NIST SP 800-53 Rev 5AC-5 — Separation of DutiesDirectly governs SoD controls and conflicting privilege combinations.
AC-6 — Least PrivilegeSoD risk falls when access is limited to only necessary duties and functions.
AU-6 — Audit Review, Analysis, and ReportingSoD governance depends on auditable evidence of approvals, exceptions, and removals.
Recommendation — Enforce AC-5 to block conflicting access combinations before approval and document any compensating controls. Apply AC-6 to minimise entitlements so users and systems cannot accumulate conflicting powers. Use AU-6 to review access events and evidence SoD decisions and exception handling.
ISO/IEC 27001:2022A.5.15 — Access controlSoD is enforced through access-control policy and governance across complex models.
A.5.16 — Identity managementIdentity lifecycle changes often introduce or remove SoD conflicts over time.
A.5.18 — Access rightsSoD requires reviewing, approving, and revoking rights that create toxic combinations.
Recommendation — Define access-control rules that prevent conflicting access paths across systems and roles. Maintain identity records so role changes and departures trigger SoD reassessment. Review access rights regularly and remove entitlements that create SoD conflicts.
CIS Controls v8CIS-6 — Access Control ManagementSupports role governance, approval discipline, and removal of excessive access.
CIS-5 — Account ManagementAccount lifecycle and orphaned access are common SoD failure points.
Recommendation — Use access control management to approve, review, and remove conflicting entitlements. Manage account lifecycles so stale or orphaned access cannot preserve SoD conflicts.
SOC 2 (AICPA)CC6.1 — Logical and Physical Access ControlsSoD is a core logical access control expectation in audited environments.
Recommendation — Design logical access controls to separate conflicting duties and support audit evidence.

Practitioner Guidance

What to prioritise: Start with the toxic combinations that would create the highest fraud, change-management, or production-impact risk if they were held by the same actor. Do not begin with the easiest review population; begin with the highest-consequence conflicts.

What to verify: Check whether your governance process evaluates effective access across inherited roles, temporary elevation, and service or application credentials, not just direct entitlements. If one of those paths is missing, the SoD control is incomplete even if the dashboards look healthy.

Common mistake: Treating SoD as a quarterly certification exercise instead of a policy-enforced access design rule. That approach catches some drift, but it does not reliably prevent conflicting access from being granted in the first place.

What good looks like: Conflicts are blocked or routed to explicit exception handling at request time, reviews remove unused access quickly, and every approved exception has an owner, expiry, and compensating control that can be audited.

Practitioner takeaway: The strongest SoD programme is not the one with the most reviews, it is the one that makes conflicting access difficult to grant, easy to detect, and hard to leave behind.

Deepen Your Knowledge

Sign up to our weekly newsletter — get 33% off our NHI Foundation Level Course

    NHIMG Editorial Note
    Reviewed and updated by the NHIMG editorial team on September 27, 2026.
    NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org