What do teams get wrong when they rely on roles to prove SoD?

Why This Matters for Security Teams

Relying on roles to prove separation of duties creates a false sense of control because a clean-looking role name does not prove clean privilege. A role can still combine create, approve, and release permissions through nested groups, inherited entitlements, service paths, or emergency exceptions. That matters because SoD is about effective privilege at the moment of action, not how access is labeled in a directory.

This is especially important in non-human identity environments, where service accounts and automation often accumulate rights over time. NHI Mgmt Group notes that Ultimate Guide to NHIs highlights how widespread excessive privilege and weak visibility remain across NHI estates. Current guidance in NIST Cybersecurity Framework 2.0 also points teams toward stronger access governance rather than trust in naming conventions alone.

In practice, many security teams discover SoD failure only after a control exception, audit finding, or abuse path has already been exercised.

How It Works in Practice

Effective SoD testing starts by mapping what an identity can actually do across systems, not by reading the role catalog. A single role may look acceptable in isolation, yet become risky when combined with inherited groups, delegated administration, API scopes, CI/CD permissions, or break-glass access. For NHI governance, that means reviewing the permission graph around each identity and validating whether conflicting capabilities can be activated by the same actor.

Teams should test SoD at the level of permission combinations. That includes creation plus approval, request plus fulfilment, deploy plus rollback, and change plus attestation. The practical question is whether one identity can complete a sensitive workflow end to end without another independent control intervening. This is why role reviews alone are insufficient. They do not capture effective privilege, accumulated access, or exception paths.

Good practice is to pair entitlement analysis with policy enforcement and logging. If a control is meant to block a conflicting action, it should be evaluated at request time and not inferred from role membership. For NHI-heavy estates, the operational posture described in Ultimate Guide to NHIs is useful because it ties access governance to lifecycle control, visibility, and revocation, not just identity assignment.

• Review effective permissions, including inherited and temporary access.
• Test whether one identity can both request and approve the same change.
• Validate exception paths such as break-glass, support escalation, and pipeline overrides.
• Recheck SoD after role changes, token scope updates, and privilege grants.

These controls tend to break down in fast-moving CI/CD and automation environments because permissions change faster than periodic role reviews can detect conflict.

Common Variations and Edge Cases

Tighter SoD enforcement often increases operational friction, requiring organisations to balance control strength against delivery speed. That tradeoff is real, especially where automation must move quickly and human approvers are not always practical. Best practice is evolving, but current guidance suggests using compensating controls rather than weakening SoD requirements just because a workflow is automated.

There are also edge cases where role-based evidence can be useful, but only as a starting point. In shared admin models, a role may be safe only if the underlying permissions are limited, the task window is short, and approval is enforced externally. In service-to-service flows, SoD may depend more on workload identity, scoped tokens, and policy enforcement than on human-style role separation. That is why NHI teams should treat role names as documentation, not proof.

For organisations building stronger access governance, the NIST CSF logic of identifying, protecting, and continuously validating access controls is more reliable than static role attestation alone. The recurring failure mode is assuming that a formal role structure means the conflict cannot exist, when the real issue is whether conflicting rights can be exercised together in practice.

Related resources from NHI Mgmt Group

• What do teams get wrong when they rely on human-in-the-loop controls for AI?
• What do teams get wrong when they treat SoD as only an audit requirement?
• What do teams get wrong when they add custom roles and fine-grained permissions?
• What do teams get wrong when they rely on application code for permission checks?