How do organisations know whether segregation of duties is actually working?

Why This Matters for Security Teams

segregation of duties is only meaningful when it prevents one identity from completing a full abuse path end to end. That means checking actual permission combinations across banking, finance, admin, and pipeline systems, not just confirming that roles look distinct on paper. Current guidance suggests this should be treated as a runtime control problem, not a spreadsheet exercise, especially where service accounts, API keys, and machine tokens can move faster than human approvals. The NIST Cybersecurity Framework 2.0 emphasises governance, access control, and continuous oversight, which is the right lens for proving the control is enforced rather than merely documented. The same concern appears in NHI programmes, where only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.

Teams usually discover failure only after an identity has already chained privileges across systems, because the check was never designed to catch cross-platform combinations before they became an abuse path.

How It Works in Practice

To test whether segregation of duties is actually working, security teams should follow the path an attacker or over-privileged operator would take and ask whether any single identity can finish the workflow without a second, independent approval. That means validating effective access, not stated access, across identity providers, PAM, application roles, batch jobs, CI/CD credentials, and service accounts. The NIST Cybersecurity Framework 2.0 provides the right operational framing: identify assets, protect access, and continuously monitor whether policy is actually preventing misuse. In practice, this often requires access graph analysis, SoD rule testing, and transaction-level logging that proves a single identity could not create, approve, and release value in the same chain.

A useful control test is to define the critical workflow first, then map every role, token, and automation path that can touch it. For example:

• Can one service account create a payment, approve it, and export the record?
• Can an engineer both change a production policy and deploy the code that enforces it?
• Can an API key or secret rotate itself and then re-authorise its own use?
• Does PAM block standing privilege, or only record that a privileged session happened?

This is where NHI visibility matters. The Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges and only 20% of organisations have formal offboarding and revocation processes for API keys, which helps explain why SoD fails when non-human identities are ignored in access reviews. The practical answer is to test for end-to-end separation at runtime, then enforce JIT access, short-lived secrets, and independent approval gates where the workflow demands it. These controls tend to break down in legacy ERP and CI/CD environments because permissions are fragmented across systems that cannot evaluate separation as one continuous transaction.

Common Variations and Edge Cases

Tighter segregation of duties often increases operational friction, so organisations have to balance risk reduction against release speed, support load, and emergency response needs. Best practice is evolving, but there is no universal standard for exactly how many approvals or role splits are enough in every environment. The key exception is break-glass access: it can be allowed, but only if it is tightly time-boxed, independently reviewed, and excluded from normal SoD evidence.

Edge cases usually appear where human and non-human identities overlap. A developer may have a human role in one system and a pipeline token in another, while an automation account may inherit rights through nested groups or inherited IAM policies. That is why current guidance increasingly favours continuous verification over periodic certification. The NIST Cybersecurity Framework 2.0 is useful here because it supports ongoing monitoring, while Ultimate Guide to NHIs shows how often secrets, API keys, and service accounts remain outside mature governance. In practice, SoD tends to look healthy in audit packs but fail in production when temporary exceptions become permanent access paths or when automation is allowed to self-service its own privilege changes.

Related resources from NHI Mgmt Group

• How do security teams know whether password reset controls are actually working?
• How do organisations know whether federated governance is actually working?
• How do organisations know whether AI governance is actually working?
• How do organisations know whether their authorization model is actually working?