How should organisations implement segregation of duties in hybrid environments?

Why This Matters for Security Teams

segregation of duties in hybrid environments is harder because the same person, service account, or workflow can touch finance, identity, cloud, and SaaS controls in one transaction chain. If SoD is only enforced in one platform, toxic combinations can still form elsewhere through sync jobs, delegated admin roles, API tokens, or break-glass paths. Current guidance suggests treating SoD as an enterprise control plane problem, not a single-system permission problem, and aligning it with broader governance principles in the NIST Cybersecurity Framework 2.0.

This matters even more for non-human identities because NHIs often outnumber human identities by 25x to 50x in modern enterprises, and many of those identities accumulate privileges across platforms that were never designed to reason about conflict pairs. The Ultimate Guide to NHIs shows that 97% of NHIs carry excessive privileges, which makes SoD drift a predictable outcome unless it is engineered into lifecycle controls. In practice, many security teams encounter toxic access only after an audit finding, a fraud review, or a production incident has already exposed the overlap.

How It Works in Practice

A workable SoD program starts with a matrix that defines prohibited combinations, then maps those combinations to every identity type and every control plane that can grant access. The matrix should cover human users, service accounts, API keys, privileged roles, temporary elevation, and delegated administration. For hybrid estates, enforcement needs to sit in provisioning, certification, and exception workflows so the conflict is blocked before access is issued or renewed. That usually means integrating IAM, PAM, HR, cloud entitlement systems, and SaaS admin APIs into one policy flow.

The operational pattern is simple: classify duties, tag systems that own each duty, then evaluate access requests against the conflict model at request time. In mature environments, JIT elevation can reduce standing exposure, but it only works if the approval path checks the SoD matrix before the token or role is minted. The same applies to quarterly certifications, where reviewers must see conflicting access across systems, not just inside one application. The governance goal is to prevent a user or NHI from becoming both requestor and approver, or builder and releaser, across finance, procurement, infrastructure, and identity. This is why Ultimate Guide to NHIs places lifecycle control and visibility at the centre of NHI risk management, while NIST Cybersecurity Framework 2.0 reinforces governance, access, and continuous monitoring as linked functions.

• Define toxic pairs in business terms first, then translate them into technical entitlements.
• Enforce SoD in the request path, not only in periodic reviews.
• Include API-driven actions, CI/CD roles, and cloud admin paths in the same conflict model.
• Log both the approval decision and the conflicting entitlement that was denied.
• Re-test the matrix after mergers, app migrations, and role redesigns.

These controls tend to break down when access is granted through unmanaged SaaS tenant admins, direct cloud console elevation, or ad hoc break-glass accounts because those paths bypass the policy engine.

Common Variations and Edge Cases

Tighter SoD enforcement often increases workflow friction, requiring organisations to balance fraud reduction and auditability against operational speed. There is no universal standard for this yet, especially where hybrid environments combine legacy ERP, cloud IAM, and service-to-service automation. Some teams use strict hard-blocking for high-risk duties, while others allow controlled exceptions with compensating controls, time limits, and independent review. The key is to make the exception process explicit rather than informal.

Edge cases are common. Small teams may not have enough people to separate every duty cleanly, so they need compensating controls such as session recording, dual approval, or post-action attestation. Shared admin accounts are another problem because they hide individual accountability and make certification meaningless. For NHIs, the issue is often not deliberate fraud but autonomous or scheduled processes that inherit broad permissions and then cross duty boundaries through orchestration tools, which is why visibility into service accounts remains so important. Best practice is evolving toward continuous policy evaluation, but organisations should avoid presenting real-time SoD automation as solved when the underlying identity inventory is still incomplete. In hybrid estates, the hardest failures appear when cloud roles, SaaS admin rights, and local application permissions are reviewed separately instead of as one connected authorisation graph.

Related resources from NHI Mgmt Group

• How should security teams implement segregation of duties automation in hybrid environments?
• How should security teams implement segregation of duties in multi-cloud environments?
• Why do segregation of duties controls fail in cloud and SaaS environments?
• What do organisations get wrong about segregation of duties in federated environments?