What breaks when SoD checks happen only after access is already granted?

Why This Matters for Security Teams

Segregation of duties only works when conflict detection happens before credentials or entitlements are issued. If review occurs after provisioning, the organisation has already created an active path into finance, admin, or production systems, and the control has shifted from prevention to incident response. That gap matters because non-human identities often retain privileges far longer than expected, especially when approvals are tied to tickets instead of runtime policy. The Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which is exactly the condition that makes delayed SoD checks dangerous.

For security teams, the practical failure is not just policy drift. It is that access can be used before anyone notices the conflict, which means audit findings arrive after data exposure, workflow abuse, or fraud opportunity. The OWASP Non-Human Identity Top 10 frames overprivileged and poorly governed machine access as a core risk, while NHI Mgmt Group’s research shows how quickly static access assumptions break under real operational pressure. In practice, many security teams discover SoD violations only after a service account or API key has already been used to touch sensitive systems.

How It Works in Practice

Effective SoD enforcement for NHIs is not a post-provisioning review step. It is a pre-approval decision that evaluates the requested access against role, workload, environment, and task context before issuance. That means the system should simulate the access path, identify conflicts such as requestor versus approver, create versus approve, or develop versus deploy, and block or route for exception handling before any secret or token is released. In mature programmes, this evaluation is paired with short-lived credentials, scoped service identities, and policy-as-code so the decision is repeatable and auditable.

Practitioners often combine entitlement analysis with runtime guardrails. For example, a workflow may allow a build agent to read a repository, but not to approve its own deployment, and a separate control may require a second identity to sign off on production changes. That distinction matters because non-human workflows can chain actions faster than a human reviewer can react. The 52 NHI Breaches Analysis shows how often machine credentials become the entry point for broader compromise, and the NIST SP 800-53 Rev 5 Security and Privacy Controls reinforces that access controls must be designed to prevent misuse, not merely document it.

• Define SoD rules at request time, not after account creation.
• Map each NHI to an owner, purpose, and approved transaction path.
• Use policy checks that block conflicting combinations before secrets are issued.
• Revalidate access when workload scope, environment, or approver changes.

These controls tend to break down when access is granted through legacy IAM pipelines that cannot evaluate workflow context before the account or token is activated.

Common Variations and Edge Cases

Tighter SoD enforcement often increases approval latency and operational overhead, requiring organisations to balance control strength against delivery speed. That tradeoff is real, especially in CI/CD, shared service accounts, and emergency change paths where teams want rapid execution. Current guidance suggests using exception workflows with compensating controls rather than weakening SoD rules broadly, but there is no universal standard for every environment yet.

Edge cases usually appear where identities are shared, delegated, or ephemeral. A build system may need broad read access but no approval authority, while an incident-response automation may need temporary elevation that would be disallowed in normal operation. In those cases, the right question is not whether access is technically possible, but whether the access path is time-bound, logged, and independently approved. NHI Mgmt Group’s Ultimate Guide to NHIs — Key Challenges and Risks is useful here because it highlights how excessive privileges and poor visibility make post-grant detection too late for meaningful prevention.

When SoD checks happen after access is already granted, the organisation is not enforcing separation of duties so much as documenting a breach of it. The safer pattern is to fail closed, then allow narrowly scoped exceptions only when a second control explicitly justifies the risk.

Related resources from NHI Mgmt Group

• What breaks when organisations try to secure SaaS access with MFA after the app inventory is already fragmented?
• What breaks when RAG apps rely only on retrieval quality and skip access checks on indexed content?
• What breaks when SAP access controls are not revalidated before and after migration?
• What breaks when organisations cannot see how access is granted through roles, groups, and trust relationships?