Why do SoD controls fail when access review sits with the same team that provisions access?

Because the review is no longer independent. If the same team can create the entitlement and later attest that it is appropriate, the control becomes a confirmation loop rather than a challenge function. That weakens fraud prevention, auditability, and the credibility of the access governance programme.

Why This Matters for Security Teams

Segregation of duties fails when the approval function is no longer independent from the provisioning function. That creates a self-approval loop: the same operational team can grant access, then later certify that the access was appropriate. The result is not just weaker governance but weaker detection, because review becomes a formality instead of a challenge control. NHI Management Group’s Top 10 NHI Issues shows how often identity controls degrade when ownership, entitlement management, and review are not separated cleanly.

This matters even more in environments with secrets, service accounts, and API-driven entitlements, where access is often provisioned quickly and reviewed much later. The OWASP Non-Human Identity Top 10 treats privileged NHI misuse as a core risk because the control plane is only as strong as the independence of the reviewers. In practice, many security teams discover the issue only after an audit exception, an entitlement dispute, or a breach investigation exposes that the reviewer was effectively rubber-stamping their own work.

How It Works in Practice

SoD is meant to create friction where conflicts of interest could hide. In access governance, that usually means one party requests or provisions access, while a different party validates whether the access is necessary, proportionate, and still in use. When the same team owns both steps, the control cannot challenge its own decisions. That is especially problematic for high-risk privileges, shared service accounts, and long-lived NHIs documented in the NHI Lifecycle Management Guide, where entitlement drift accumulates quietly over time.

Operationally, the control should separate request, approval, implementation, and certification. A healthy model usually includes:

• Independent approvers from a different function, such as application ownership, security, or business control owners.
• Evidence-based reviews that check last use, scope, sensitivity, and actual system-to-system dependencies.
• Policy rules that prevent the reviewer from attesting to entitlements they provisioned or administered.
• Time-bound access for privileged NHIs, with automatic expiration and recertification for exceptions.

For NHIs, this needs stronger evidence than human access review. Service account ownership, secret rotation status, token scope, and workload purpose should be visible at review time. NHI Management Group’s Lifecycle Processes for Managing NHIs and the OWASP Non-Human Identity Top 10 both reinforce that lifecycle ownership and entitlement review must be separated if the control is to remain credible. These controls tend to break down in lean operations teams where the same engineers provision, operate, and certify access because there is no true independent challenge function.

Common Variations and Edge Cases

Tighter SoD often increases operational overhead, so organisations must balance control strength against staffing constraints and delivery speed. Current guidance suggests that full separation is most important for privileged, financial, regulated, or production access, while lower-risk requests may use compensating controls. Where absolute separation is impractical, best practice is evolving toward documented compensating review, manager attestation outside the provisioning chain, and periodic spot checks by internal audit.

There are also environments where technical and organisational separation diverge. In small teams, one person may need to provision access in emergencies, but they should not be the sole reviewer afterward. In platforms with automated workflows, the approval function can be embedded in policy-as-code, but the policy owner still must not be the same individual who implements exceptions. The 52 NHI Breaches Analysis is useful here because it shows how quickly entitlement weaknesses turn into broader compromise once credentials and access paths are left uncleared. For teams that want a deeper inventory of recurring failure patterns, the LLMjacking research is a reminder that compromised NHIs are often abused far faster than governance cycles can respond.

There is no universal standard for this yet, but the principle is consistent: if the same team can create access and bless it, SoD becomes documentation, not control.

Related resources from NHI Mgmt Group

• When should organizations review access controls?
• Why do manual access review reports fail in practice?
• Why do time based access controls still need identity governance and review?
• Who is accountable when VPN-based access controls fail under the Online Safety Act?