Notifications
Clear all
Topic starter
25/06/2026 3:06 pm
TL;DR: Segregation of duties prevents one privileged person from creating access, approving changes, and erasing evidence, reducing insider misuse and audit exposure across cloud, SaaS, and data center environments, according to SecurEnds. The control only works when identity governance, role design, and exception handling stay current with real admin workflows.
NHIMG editorial — based on content published by SecurEnds: separation of duties in cybersecurity
By the numbers:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
Questions worth separating out
Q: How should security teams implement separation of duties in cloud environments?
A: Start by identifying privileged workflows where one identity can request, approve, and execute the same change.
Q: Why does separation of duties matter for IAM and PAM programmes?
A: Because IAM and PAM are the controls that decide who can act, who can approve, and who can certify the result.
Q: What do organisations get wrong about separation of duties?
A: They often treat SoD as a policy document instead of a workflow design problem.
Practitioner guidance
- Map conflicting duties at the workflow level Document where one identity can request, approve, execute, and review the same privileged change.
- Separate approval from execution in PAM and IAM Use PAM for elevation, IAM for entitlement control, and distinct approvers for each privileged action.
- Treat emergency access as a tracked exception Give break-glass access a short expiry, mandatory justification, and post-use review by someone who did not hold the elevated session.
What's in the full article
SecurEnds's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step role mapping for separating provisioning, approval, and monitoring duties across IT teams
- Practical examples of where SoD conflicts appear in cloud, SaaS, and database administration
- Guidance on building audit-ready exception handling and evidence trails for reviewers
- Implementation detail on how automation supports recurring access review cycles
👉 Read SecurEnds's guide to separation of duties in cybersecurity →
Segregation of duties in cybersecurity: are your controls airtight?
Explore further
25/06/2026 4:25 pm
Duty concentration is the failure mode, not just overprivilege. Separation of duties exists to stop a single identity from controlling access creation, access approval, and evidence suppression at the same time. In practice, that failure mode is what turns routine administration into a fraud path and an audit failure path. Mature IAM teams should treat overlapping administrative authority as a structural control defect, not a policy gap.
A few things that frame the scale:
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to Ultimate Guide to NHIs.
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
A question worth separating out:
Q: Who is accountable when separation of duties breaks down?
A: Accountability usually sits with the control owner who allowed the overlap to exist, not only with the individual who used it. Governance teams, IAM administrators, PAM owners, and system owners all share responsibility for preventing conflicting authority. Frameworks such as NIST CSF and ISO 27001 expect evidence that duties are separated and reviewed.
👉 Read our full editorial: Segregation of duties is the control that limits admin abuse
