Notifications
Clear all
Topic starter
12/06/2026 1:05 am
TL;DR: IT segregation of duties reduces fraud, privilege abuse, and error propagation by separating account creation, approval, monitoring, and response across different people, according to Zluri. The deeper issue is that many identity programmes still rely on checks and balances after access has already concentrated too far.
NHIMG editorial — based on content published by Zluri: Security & Compliance How IT Segregation of Duties Helps Strengthen IT Security
Questions worth separating out
Q: How should security teams implement segregation of duties in access governance?
A: Start by identifying the high-risk workflows where one identity could request, approve, and execute the same change.
Q: Why do toxic role combinations create more risk than simple overprovisioning?
A: Because overprovisioning increases scope, while toxic combinations remove challenge.
Q: How do organisations know whether segregation of duties is actually working?
A: Look for evidence that requests, approvals, execution, and review are truly independent.
Practitioner guidance
- Define toxic duty combinations List incompatible actions for access creation, approval, monitoring, administration, and incident response.
- Separate approval from execution Ensure that no identity can both approve a sensitive request and carry out the resulting administrative change.
- Review privileged roles for hidden overlap Inspect database administrators, system administrators, and security operators for overlapping responsibilities that remove challenge from the process.
What's in the full article
Zluri's full article covers the operational detail this post intentionally leaves for the source:
- Detailed SoD examples across user access management, vendor management, and IT security workflows.
- Expanded discussion of how automated IGA platforms support access review and certification operations.
- Practical reporting and integration capabilities used to surface SoD violations and compliance gaps.
- The article's own framing of how SoD fits broader internal control and audit programmes.
👉 Read Zluri's article on how segregation of duties strengthens IT security →
Segregation of duties in IT security: where IAM teams still slip?
Explore further
12/06/2026 10:46 am
Segregation of duties is an access-governance control, not a compliance checkbox. The article is right to frame SoD as a way to reduce fraud, privilege abuse, and error propagation, but the identity lesson is broader: once a single role can request, approve, and execute access-related actions, the control environment has lost independent challenge. That is the same structural weakness IAM, IGA, and PAM teams try to prevent in high-risk workflows. The practitioner takeaway is that SoD must be treated as a control architecture decision, not a policy statement.
A few things that frame the scale:
- 1 in 4 organisations are already investing in dedicated NHI security capabilities, with an additional 60% planning to do so within the next twelve months, according to The State of Non-Human Identity Security.
- Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared with nearly 1 in 4 for securing human identities, according to the same report.
A question worth separating out:
Q: Who is accountable when segregation of duties fails during an audit or incident?
A: Accountability sits with the control owners who designed the workflow, the managers who approved exceptions, and the governance team that allowed incompatible duties to persist. Regulators and auditors expect demonstrable independence, so the absence of SoD is usually treated as a governance failure, not just an operational mistake.
👉 Read our full editorial: Segregation of duties is an identity control, not just an audit rule
