Notifications
Clear all
Topic starter
12/06/2026 1:22 am
TL;DR: Segregation of duties separates task authority so the same identity cannot both perform and verify sensitive actions, reducing fraud and access misuse risk according to Zluri. In identity programmes, SoD only works when policy, workflow, and review are aligned across human, NHI, and privileged access paths.
NHIMG editorial — based on content published by Zluri: Security & Compliance Segregation of Duties Policy and Procedure: An Overview
By the numbers:
- Only 5.7% of organisations have full visibility into their service accounts.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
Questions worth separating out
Q: How should security teams enforce segregation of duties in IAM workflows?
A: Start by separating who can request, grant, modify, and certify access.
Q: Why do SoD controls fail when access review sits with the same team that provisions access?
A: Because the review is no longer independent.
Q: What do IAM teams get wrong about SoD for service accounts and shared accounts?
A: They often design SoD around named employees and forget that non-human accounts can carry the most sensitive privileges.
Practitioner guidance
- Separate access grant and access review ownership Assign provisioning, modification, and revocation to one team or workflow and certification to a different owner.
- Extend SoD rules to unmapped and shared accounts Include service accounts, shared accounts, and orphaned accounts in SoD conditions so non-person identities cannot bypass governance because they lack a clear user record.
- Centralise entitlement evidence before certification Use a unified view of access across applications so reviewers can see role memberships, privileged assignments, and exceptions in one place.
What's in the full article
Zluri's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step SoD policy setup guidance for access management teams working in Zluri
- Detailed procedure examples for access review, certification, and privileged access handling
- Platform-specific workflow descriptions for centralized dashboards and automated remediation
- FAQs and implementation examples that show how Zluri maps SoD concepts into its product
👉 Read Zluri's overview of segregation of duties policy and procedure →
Segregation of duties in IAM: where policy and procedure break down?
Explore further
12/06/2026 11:15 am
SoD breaks fastest when access assignment and access review are allowed to converge. The article describes the classic control failure correctly: the same operational path that grants or modifies access must not be the one that certifies it. When that separation collapses, the organisation no longer has a meaningful second line of challenge, only a procedural echo of the first decision. Practitioners should treat independent review as the control boundary, not the tooling label.
A few things that frame the scale:
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
A question worth separating out:
Q: Who should approve SoD exceptions and temporary access overrides?
A: Approval should come from someone outside the operational path that requested or granted the access. The exception should be time-bound, documented, and separately reviewable so it does not become a permanent bypass. Independence matters more than speed when the control is meant to prevent conflicted authority.
👉 Read our full editorial: Segregation of duties policy and procedure in IAM governance
