How should security teams build a segregation of duties matrix that reflects real access?

Why This Matters for Security Teams

A segregation of duties matrix is only useful if it reflects how identities actually operate across systems. For NHIs, that means service accounts, API keys, workload identities, and agentic software may have the ability to start, route, approve, or execute the same business process in ways a static org chart will never show. NHI Management Group’s Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which is exactly the kind of condition that makes a SoD matrix look compliant while real access remains concentrated.

The practical risk is not just fraud or misuse. It is hidden privilege overlap: one identity can initiate a change, another can validate it, and the same automation layer can still bypass the intent of both checks. The OWASP Non-Human Identity Top 10 treats over-privilege and poor lifecycle control as recurring failure patterns because they undermine both accountability and separation of control. In practice, many security teams discover SoD failures only after a workflow, bot, or service account has already approved what it should only have been able to request.

How It Works in Practice

Building a real SoD matrix starts with identity evidence, not policy language. Pull live IAM, PAM, CI/CD, cloud, and application logs to identify every human and non-human identity involved in high-risk processes such as payments, user provisioning, vendor onboarding, code deployment, and secrets access. Then map the actual action chain: who can initiate, who can modify, who can approve, and which service accounts or agents can invoke those steps automatically.

From there, classify conflicts by process, not by team title. A useful matrix usually includes:

• Identity type: human user, service account, workload identity, API client, or agent
• Process step: create, validate, approve, execute, reconcile, or revoke
• Privilege path: direct access, delegated access, shared credential, or token exchange
• Exception owner: named accountable person for any documented override
• Review cadence: periodic validation against current entitlements and logs

This is where NHI governance becomes operational. The 52 NHI Breaches Analysis and the broader Ultimate Guide to NHIs both point to the same pattern: hidden credentials, excessive privilege, and weak visibility make paper controls drift away from reality. The control objective is to prevent one identity from both initiating and approving the same sensitive action unless a documented exception exists and is time-bound. Current guidance suggests using access reviews, policy-as-code checks, and workflow telemetry together rather than relying on annual certification alone. These controls tend to break down when identities are shared across multiple applications without clean ownership because attribution becomes too weak to prove who actually exercised the privilege.

Common Variations and Edge Cases

Tighter SoD rules often increase operational friction, so organisations have to balance fraud reduction against release speed, service reliability, and support overhead. That tradeoff becomes sharper when agents and automation are involved, because an autonomous workflow may need temporary access across multiple steps to complete a single task. Best practice is evolving, but current guidance suggests treating those cases as exceptions with short-lived credentials, explicit runtime policy checks, and a named approver for each exception.

One common edge case is delegated approval. If a human reviewer signs off on a workflow that an automation platform later executes, the matrix should still show whether the same upstream identity can influence both paths. Another is emergency access: break-glass access may be legitimate, but it should be isolated, logged, and reviewed after use. For agentic systems, the relevant control is less “who owns the bot” and more “what can this workload identity do at this moment.” That is why teams increasingly pair SoD with real-time authorization concepts in NIST AI Risk Management Framework and the Zero Trust Architecture model. When automation spans shared pipelines, vendor integrations, or cross-domain orchestration, a static matrix usually lags behind the actual control path.

Related resources from NHI Mgmt Group

• How should security teams run access reviews for non-human identities?
• How should security teams govern non-human identities that have persistent access?
• How should security teams govern API keys used for generative AI access?
• How should security teams combine segregation of duties and user access reviews?