Why do organisations struggle with segregation of duties at scale?

Why This Matters for Security Teams

segregation of duties is supposed to prevent one identity, process, or role from gaining enough power to approve, execute, and conceal a sensitive action. At scale, that model becomes harder to maintain because entitlements are distributed across SaaS apps, cloud control planes, CI/CD systems, and service accounts. The result is not just policy drift, but blind spots: conflicting permissions sit in different systems, manual reviews lag behind change, and compensating controls depend on people noticing what automation has already enabled.

For NHI programmes, this matters even more because workload identities often outnumber human users by 25x to 50x in modern enterprises, and only 5.7% of organisations report full visibility into service accounts. That is why the challenge is not simply “more review”, but better authoritative data and policy enforcement. NHI Mgmt Group’s Ultimate Guide to NHIs — Why NHI Security Matters Now shows how hidden privilege and weak lifecycle control amplify risk, while the NIST Cybersecurity Framework 2.0 reinforces the need for repeatable governance, asset visibility, and access control. In practice, many security teams discover SoD failures only after a privileged workflow has already combined request, approval, and execution in one path.

How It Works in Practice

Effective SoD at scale starts by defining which actions must never be held by the same identity, workflow, or control plane. That sounds simple, but organisations usually encode those boundaries inconsistently: RBAC in one system, approval rules in another, and emergency access exceptions in a spreadsheet. The practical fix is to centralise the policy logic, connect it to authoritative identity and entitlement data, and evaluate it continuously rather than during quarterly reviews.

For non-human identities, that means treating the service account, API key, token, or certificate as a governed workload identity with a clear lifecycle. NHI Mgmt Group notes that 96% of organisations store secrets outside secrets managers in vulnerable locations, which makes SoD enforcement unreliable because the same credential may be reused across pipelines and environments. Pairing policy with rotation, JIT credential issuance, and revocation reduces the window in which a single workload can accumulate conflicting privileges. The Ultimate Guide to NHIs — Why NHI Security Matters Now is useful here because it ties visibility, rotation, and offboarding to Zero Trust outcomes, while NIST Cybersecurity Framework 2.0 provides the governance language for control monitoring and access enforcement.

• Define SoD conflicts at the workflow level, not only the human role level.
• Use authoritative entitlement data from IAM, PAM, CI/CD, and cloud logs before approving access.
• Issue JIT credentials for narrow tasks and revoke them automatically after completion.
• Separate request, approval, and execution paths for both humans and NHIs.

These controls tend to break down in highly automated release pipelines because the same toolchain often creates, approves, and deploys the credentials before reviewers can intervene.

Common Variations and Edge Cases

Tighter SoD often increases operational overhead, so organisations have to balance stronger control separation against delivery speed and incident-response flexibility. That tradeoff is especially visible in environments with shared platform teams, break-glass access, or legacy applications that cannot cleanly separate duties without redesign.

Current guidance suggests there is no universal standard for every edge case, but best practice is to make exceptions explicit, time-bound, and monitored. For example, a release engineer may need temporary access to a production secret, but that should not become standing privilege or a reusable pattern. The same applies to service accounts used by agentic workflows: if an autonomous system can chain tools, trigger approvals, and call downstream APIs, SoD must be enforced by context-aware policy rather than static role membership. The Ultimate Guide to NHIs — Why NHI Security Matters Now and NIST Cybersecurity Framework 2.0 both support the same operational lesson: visibility and control only work when identities, secrets, and approvals are governed together. Where this gets hardest is in multi-cloud estates with inherited permissions and exception-heavy legacy systems, because historical access paths usually outlive the policies meant to constrain them.

Related resources from NHI Mgmt Group

• How do organisations operationalise NHI ownership at scale?
• How do organisations reduce the dwell time of exposed credentials at scale?
• How should security teams govern non-human identities at scale?
• When should organisations treat an NHI as a high-priority risk?