Segregation of duties exposes the IAM gap in access governance

At a glance

What this is: This is a guide to segregation of duties and its role in limiting fraud, errors, and control concentration in identity and business processes.

Why it matters: It matters because IAM teams must enforce SoD across human users, service accounts, and automated workflows before privilege concentration turns into compliance failure or misuse.

By the numbers:

• 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.
• Only 5.7% of organisations have full visibility into their service accounts.

👉 Read Zluri's guide to segregation of duties and identity governance

Context

Segregation of duties, or SoD, is the control principle that keeps one identity from owning an entire high-risk process end to end. In practice, it is an identity governance problem as much as a compliance one, because excessive access concentration is what creates both fraud risk and accidental damage.

For IAM teams, SoD is not limited to finance or audit workflows. The same design problem appears in user provisioning, access review, offboarding, privileged operations, and NHI lifecycle management, where service accounts and API keys can quietly accumulate incompatible responsibilities.

Key questions

Q: How should security teams apply SoD to service accounts and API keys?

A: Treat service accounts and API keys as governed identities, not as technical leftovers. Define which actions are incompatible, map them into a matrix, and make sure provisioning, approval, execution, and review are separated across different principals or control points. Review the matrix whenever automation, SaaS permissions, or offboarding changes.

Q: Why does SoD often fail in cloud and SaaS environments?

A: SoD fails when identity sprawl and automation let one principal accumulate too many compatible-looking permissions. Cloud and SaaS tools can hide that overlap because access is distributed across consoles, APIs, and delegated roles. Teams need live entitlement data and recertification, not a one-time policy document, to see the failure early.

Q: What do security teams get wrong about SoD matrices?

A: They often treat the matrix as proof of control rather than as a control design tool. A matrix that is not aligned with current roles, current entitlements, and current exception handling will miss actual violations. The useful signal is whether the matrix drives removal of risky overlaps, not whether it exists.

Q: Should organisations separate access provisioning from access review?

A: Yes, especially for high-risk systems and privileged access. The team or workflow that grants permissions should not be the same one that certifies them, because that turns review into self-attestation. Independent review is what gives SoD its value, and it is especially important when identities can be reused across systems.

Technical breakdown

SoD conflicts and violations in identity governance

A SoD conflict exists when one role or one identity can perform incompatible steps in the same process. A violation occurs when that theoretical overlap becomes active and the identity actually executes both sides of the control. In IAM, the distinction matters because conflict analysis is about policy design, while violation monitoring is about runtime enforcement. Role-based access control often underpins this model, but RBAC alone does not resolve the issue if role design is too broad or recertification is too weak.

Practical implication: define incompatible access combinations explicitly and monitor for actual execution, not just theoretical role overlap.

SoD matrices as a control model for access reviews

A SoD matrix maps roles, duties, and prohibited combinations so reviewers can see where concentration risk exists. It is useful only if the matrix reflects current entitlements, current process steps, and current approval paths. In mature identity programmes, the matrix becomes a governance artefact that supports access certification, exception handling, and audit evidence. If the matrix is stale, it creates the appearance of control while leaving hidden privilege chains intact.

Practical implication: keep the matrix synchronized with entitlement data, workflow changes, and review outcomes.

Why SoD becomes harder in SaaS and NHI environments

SoD was originally built for human process separation, but cloud platforms and machine identities compress many actions into a single technical principal. Service accounts, API keys, and automation tokens can span provisioning, configuration, data access, and administrative tasks without a natural human break point. That creates a governance problem because the process owner, executor, and auditor may no longer be different identities. The more automated the environment, the more SoD depends on lifecycle control, least privilege, and strong entitlement visibility.

Practical implication: extend SoD analysis to machine identities and automation paths, not only named employees.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Azure Key Vault privilege escalation exposure — Azure Key Vault Contributor role misconfiguration enabled privilege escalation.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

SoD is really an identity concentration problem, not just a compliance checkbox. The article describes the classic failure mode correctly: one identity or role gains control over incompatible process steps, and that concentration increases fraud and error risk. In IAM terms, SoD is the control that prevents a single principal from becoming the full transaction path. Practitioners should treat role design, access review, and exception handling as parts of the same control surface.

Service accounts and automation break the old SoD assumption that process steps are naturally separated by people. That assumption was designed for human-paced workflows, where authorization, execution, and reconciliation could be split across different employees. It fails when an NHI can be provisioned once and then operate across multiple steps without a human break. The implication is that SoD must be evaluated through lifecycle and entitlement visibility, not only through organisational org charts.

SoD matrices only work when they are tied to live entitlement data and recertification. A static matrix may satisfy audit language, but it does not prevent privilege drift or hidden overlap in SaaS and IGA environments. Zluri’s discussion of automated access reviews and policy-based provisioning points to the operational reality: the control is only as good as the underlying identity data. Teams should assume stale matrices are false confidence until proved otherwise.

The governance model has to stretch from human IAM into NHI lifecycle control. The most important SoD failures now sit at the edge of access provisioning, offboarding, and privileged automation, where machine identities can outlive the process they were created for. That is why NHI governance, not only human access control, is now part of SoD discipline. IAM leaders should integrate SoD checks into NHI visibility, rotation, and revocation workflows.

Named concept: access concentration drift. This is the gradual accumulation of incompatible responsibilities inside one identity, role, or automation path. It often starts as a convenience exception and ends as a governance blind spot that no quarterly review catches in time. The practical conclusion is simple: teams need continuous detection of incompatible access, not just annual policy statements.

From our research:

• 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.
• Only 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
• For a broader control model, NHI Lifecycle Management Guide shows how provisioning, rotation, and offboarding reduce privilege concentration over time.

What this signals

Access concentration drift: SoD programmes will fail quietly if they are not connected to entitlement freshness and offboarding discipline. With only 20% of organisations formalising API key revocation and rotation, the control gap is now operational, not theoretical.

The next maturity step is to apply SoD logic to machine identities, not just human approvals, and to anchor that logic in lifecycle controls and review evidence. Teams that only model roles will miss where automation compresses incompatible duties into a single principal, especially across SaaS and privileged workflows.

For practitioners

• Map incompatible duties across human and machine identities Build a SoD matrix that includes employees, service accounts, API keys, and automation tokens. Flag any identity that can provision access, approve access, and execute sensitive downstream actions.
• Tie access reviews to current entitlements Reconcile the SoD matrix against live directory, SaaS, and privileged access data before each certification cycle. Remove stale conflicts created by role changes, project transfers, or unattended offboarding.
• Separate provisioning from review and approval Ensure the team that grants access is not the team that certifies it, especially for high-risk applications and privileged workflows. Use distinct approver groups and independent audit evidence for exceptions.
• Extend SoD checks into NHI lifecycle controls Apply conflict rules to service account creation, token issuance, rotation, and revocation so non-human principals do not accumulate end-to-end process control.
• Monitor for privilege concentration drift Track when one identity gains multiple incompatible permissions over time, then trigger review before that overlap becomes a formal violation.

Key takeaways

• SoD protects identity programmes by preventing one principal from owning incompatible steps in the same process.
• The real control failure is privilege concentration drift, which becomes harder to spot as automation and machine identities expand.
• IAM teams should connect SoD matrices to live entitlements, recertification, and NHI lifecycle controls to keep the model usable.

Key terms

• Segregation Of Duties: Segregation of duties is an internal control that splits critical process steps across different people or control points. In identity programmes, it prevents one principal from requesting, approving, executing, and reconciling the same sensitive action, which reduces fraud, error, and abuse risk.
• SoD Matrix: A SoD matrix is a governance map that shows which roles, tasks, or entitlements are incompatible. It turns policy into something reviewable by linking access combinations to specific process steps, helping teams identify where control overlap creates risk before it becomes a violation.
• SoD Violation: A SoD violation occurs when an identity actually performs incompatible duties that policy says must remain separate. Unlike a theoretical conflict, it represents active control breakdown and is usually the point at which investigation, remediation, and audit evidence become necessary.
• Privilege Concentration Drift: Privilege concentration drift is the gradual accumulation of incompatible access inside one identity, role, or automation path. It often starts as an exception or convenience shortcut, then becomes embedded in operations until recertification or incident response finally exposes the overlap.

Deepen your knowledge

SoD design, access review, and NHI lifecycle governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are extending segregation of duties into service accounts and automation, it is worth exploring.

This post draws on content published by Zluri: Security & Compliance Segregation of Duties (SoD) - A 101 Guide. Read the original.