How should organisations build a segregation of duties matrix for modern IAM programs?

Why This Matters for Security Teams

A segregation of duties matrix is only useful when it reflects how work actually gets done across people, service accounts, pipelines, bots, and AI agents. In modern IAM programs, the risk is not just one person doing too much, but one identity path accumulating enough authority to approve, execute, and conceal a sensitive change. That creates toxic combinations that traditional RBAC reviews often miss.

Current guidance suggests grounding SoD in business processes and control outcomes, then translating them into identity rules. The same principle applies to NHI governance: service accounts, API keys, and agent identities must be included because they often outlive the human workflows they support. NHIMG research shows that 97% of NHIs carry excessive privileges, which is why access conflict design matters as much as access provisioning. The same pattern appears in credential sprawl and misconfigured vault usage, including scenarios discussed in Azure Key Vault privilege escalation exposure.

Security teams also need an external reference point for control design. NIST Cybersecurity Framework 2.0 is useful because it ties identity governance to risk management rather than treating SoD as a purely audit-led exercise. In practice, many security teams encounter SoD failures only after an approver identity, a privileged service account, and an automation workflow have already combined to make the breach look legitimate.

How It Works in Practice

Start by documenting critical business transactions end to end: initiate, modify, approve, release, reconcile, and revoke. Then identify which steps must never be held by the same identity context. That matrix should include human roles, shared technical accounts, workload identities, CI/CD runners, and any agent that can call tools or make decisions on behalf of a user. The goal is to define conflict pairs, not just job titles.

A practical SoD matrix usually has four layers. First, the business conflict, such as create vendor plus approve payment. Second, the identity mapping, such as finance analyst plus payment bot plus ERP service account. Third, the enforcement point, such as RBAC, PAM, workflow approval, or JIT elevation. Fourth, the evidence trail, which should show who requested access, who approved it, and when the privilege expired. Where possible, use NIST Cybersecurity Framework 2.0 to tie those steps back to governance and monitoring outcomes.

• Define prohibited combinations at the process level before translating them into system entitlements.
• Separate requester, approver, executor, and reviewer functions across identities and tooling.
• Include NHI controls for secrets, certificates, tokens, and API keys, not only human accounts.
• Use JIT access for exceptions so elevated rights exist only for the minimum task window.
• Review automation paths, because a workflow can bypass manual checks if no one treats it as an identity.

For NHI-specific evidence, the fact that 79% of organisations have experienced secrets leaks and that 96% store secrets outside secrets managers shows why SoD cannot stop at user accounts. The same weak point is visible in privileged cloud configurations such as Azure Key Vault privilege escalation exposure, where access to one control plane can cascade into broader secret exposure. These controls tend to break down when workflows are heavily customised across multiple SaaS tenants because entitlement inheritance and exception handling become too fragmented to validate consistently.

Common Variations and Edge Cases

Tighter SoD often increases operational overhead, requiring organisations to balance fraud prevention and change control against speed and usability. That tradeoff becomes sharper when the program spans ERP, cloud consoles, low-code automation, and agentic systems, because a single business action may touch several identities in seconds. Best practice is evolving here, and there is no universal standard for how granular an SoD matrix should be across autonomous workflows.

One common edge case is break-glass access. It should be excluded from normal SoD paths only when the approval, monitoring, and expiry conditions are separately enforced. Another is shared service accounts in legacy applications. If the application cannot support workload-level identity, current guidance suggests compensating controls such as PAM checkout, restricted network paths, and immutable logging. A third edge case is AI agents. Their access must be based on what the agent is authorised to attempt at runtime, not a static role that assumes predictable behaviour. That is where workload identity and policy evaluation become more important than traditional role charts.

For organisations building mature governance, NIST Cybersecurity Framework 2.0 helps anchor the monitoring side, while NHIMG research on excessive NHI privileges and secret leakage highlights why evidence quality matters as much as policy design. The practical rule is simple: if an identity can both request and approve its own escalation path, the matrix is already failing. That failure is most visible in environments with delegated admin, multi-cloud sprawl, and loosely governed automation chains.

Related resources from NHI Mgmt Group

• Why do non-human identities create audit risk in modern environments?
• How do organisations operationalise NHI ownership at scale?
• What is the difference between human IAM controls and NHI governance?
• When should organisations treat an NHI as a high-priority risk?