What breaks when segregation of duties checks are handled outside the provisioning workflow?

Why This Matters for Security Teams

segregation of duties only works when it is enforced before access becomes active. If SoD checks happen after provisioning, the workflow can approve a request, create the entitlement, and only then detect that the combination is unsafe. That creates a time window where a user or service account can act with conflicting privileges, which is exactly when audit teams expect controls to prevent harm, not explain it later.

This is more than a policy defect. Once provisioning is decoupled from SoD evaluation, remediation becomes manual, exceptions become sticky, and evidence becomes harder to reconstruct. NHI Management Group notes that only 20% of organisations have formal processes for offboarding and revoking API keys, a sign that delayed control enforcement is common across identity operations (Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs). When SoD is treated as a downstream review, the organisation often discovers the conflict only after operational access has already been granted.

Current guidance suggests aligning SoD with the approval and provisioning path rather than the review queue, because controls that fire too late cannot prevent misuse. In practice, many security teams encounter SoD failures only after access has already been used, rather than through intentional prevention.

How It Works in Practice

The practical fix is to make SoD a gating control inside the provisioning workflow, not a separate audit step. At request time, the system should evaluate the requested entitlement against current role, existing access, business context, and any incompatible combinations. If the request would create a conflict, it should be blocked, routed for compensating approval, or transformed into a safer alternative such as just-in-time access with tighter duration.

For NHI and automated workflows, this matters even more because secrets, service accounts, and API keys can be provisioned instantly and used continuously. A provisioning engine should check for conflicting functions before issuing credentials, and it should also re-check when the entitlement changes, when a role assignment shifts, or when a workflow is re-authorised. NIST guidance on access control and separation of duties in NIST SP 800-53 Rev 5 Security and Privacy Controls supports this kind of preventative design, where control enforcement is embedded in the system rather than assumed in a later review.

Operationally, teams usually need four mechanics:

• Policy-as-code rules that evaluate incompatible access combinations at request time.
• Workflow integration so the ticket, approval, and entitlement issuance are one control plane.
• Lifecycle monitoring so access changes trigger re-evaluation, not just periodic recertification.
• Revocation automation so blocked or corrected access is removed immediately, not at the next review cycle.

This approach aligns with the NHI lifecycle model described in the NHI Lifecycle Management Guide, where governance must follow the full identity lifecycle rather than a single approval moment. It also fits real incident patterns such as GitHub Action tj-actions Supply Chain Attack, where automated workflows can expose secrets before downstream controls notice the risk. These controls tend to break down when provisioning is handled by fragmented ticketing, because the system cannot reliably see all active entitlements in one decision path.

Common Variations and Edge Cases

Tighter SoD enforcement often increases approval friction, so organisations have to balance control strength against delivery speed. That tradeoff becomes sharper when provisioning spans multiple systems, business units, or cloud tenants, where no single workflow owns the full access picture.

One common edge case is exception handling. If every conflict is manually approved, SoD becomes a paper process with little preventive value. Best practice is evolving toward bounded exceptions with expiry, compensating controls, and explicit revalidation. Another edge case is machine access: service accounts and API keys may not fit human-role SoD patterns, so teams should not force a human-centric model onto autonomous workloads. Instead, they should separate duties across pipelines, environments, and approval authorities.

There is no universal standard for this yet, but mature programs treat SoD as a runtime policy decision backed by lifecycle evidence. That means the provisioning system must know what access already exists, what action is being requested, and whether the combination is incompatible before issuance. Where that visibility is missing, the control usually degrades into after-the-fact review and delayed cleanup. The gap is especially visible in environments with high secret sprawl and poor lifecycle hygiene, which is why the NHI guidance on governance and rotation remains directly relevant.

Related resources from NHI Mgmt Group

• What breaks when Travel Rule checks are added as a manual back-office process instead of an in-app workflow?
• What breaks when AI security checks happen outside the release workflow?
• What breaks when customer onboarding relies on manual review and fragmented compliance checks?
• What breaks when access is granted without continuous context checks?