Why do segregation of duties conflicts still appear after periodic reviews?

Because periodic reviews only see the access state that exists at the moment of review. If roles, approvals, or transaction paths change between cycles, conflicts can reappear before anyone notices. The gap closes when SoD rules are enforced in provisioning and lifecycle workflows rather than documented after the fact.

Why This Matters for Security Teams

segregation of duties conflicts are not a one-time audit problem. They are a control drift problem. If a user, service account, or automation path can gain conflicting capabilities after a review, the organisation can look compliant on paper while still being exposed in production. That is why periodic certification alone is not enough for modern identity estates, especially where non-human identities and automation change faster than review cycles.

This gets more serious when privileges are tied to workflows that can be re-used, inherited, or temporarily expanded. The Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which helps explain why SoD drift often appears in the same environments where access is already too broad. In practice, many security teams encounter the conflict only after a failed audit, a fraud event, or a production incident has already exposed the gap.

Periodic reviews are also limited because they confirm snapshots, not decision logic. The NIST Cybersecurity Framework 2.0 emphasises continuous governance outcomes, which is the right direction for SoD enforcement as well. In practice, many security teams encounter SoD conflicts only after a review cycle has passed and a role change has already reopened the same conflict.

How It Works in Practice

SoD conflicts reappear when enforcement happens too late in the lifecycle. A reviewer may remove a conflict from today’s access list, but the provisioning system, approval workflow, or downstream application role model can reintroduce it tomorrow. The practical fix is to move SoD checks into the paths where access is requested, changed, or delegated, rather than relying on after-the-fact evidence.

That usually means three things:

• Checking SoD rules during provisioning so conflicting entitlements are blocked before they are issued.
• Re-evaluating SoD when roles change, not just when a quarterly or monthly review runs.
• Linking SoD policy to the lifecycle of both human and non-human identities, including service accounts, API keys, and automation tokens.

For NHI-heavy environments, this matters because the identity may not behave like a person at all. A service account may inherit permissions through deployment tooling, a pipeline may mint credentials into a new environment, or an agent may call tools in a sequence that no reviewer expected. Current guidance suggests using policy-as-code and runtime checks where possible, because pre-approved access lists do not capture these changing paths. The NIST identity guidance is strongest when SoD is treated as an enforced control objective, not a documentation exercise, and the same operational logic appears in the Ultimate Guide to NHIs when discussing lifecycle control and visibility gaps.

When organisations can connect approvals, entitlement changes, and transaction monitoring, SoD conflicts are caught at the point of creation instead of at the next review. These controls tend to break down when roles are copied manually across systems because the conflict logic is not propagated with the access change.

Common Variations and Edge Cases

Tighter SoD enforcement often increases workflow friction, requiring organisations to balance faster provisioning against stronger conflict prevention. That tradeoff is unavoidable in environments with frequent change, especially where business teams expect near-instant access and security teams need to preserve control boundaries.

There is no universal standard for SoD automation maturity yet. Some organisations use coarse role conflicts, others use transaction-level rules, and more advanced teams model context such as environment, time, approver identity, and tool chain. The right depth depends on the process being protected. For example, a finance approval path may need strict preventive checks, while a low-risk operational workflow may tolerate detective review with escalation.

Edge cases also matter for NHIs. Shared service accounts, break-glass credentials, CI/CD automation, and agentic systems can all create apparent SoD conflicts even when no human user is involved. The control objective is still the same: no identity should be able to create, approve, and execute a sensitive action without an effective separation boundary. As the Ultimate Guide to NHIs shows, visibility and rotation gaps make these exceptions harder to detect than organisations assume. Best practice is evolving toward continuous enforcement rather than periodic exception clean-up.

Related resources from NHI Mgmt Group

• Why do segregation of duties failures still happen in mature finance programmes?
• What breaks when segregation of duties relies on annual spreadsheet reviews?
• Why do segregation of duties conflicts still happen in mature IAM programmes?
• What breaks when organisations rely only on periodic access reviews?