Why do application-level access reviews miss SoD risk in connected systems?

Why This Matters for Security Teams

Application-level access reviews are useful for spotting obvious entitlement drift, but they are blind to the process-level risk that emerges when multiple systems combine into one transaction path. A user can look compliant in CRM, ticketing, data export, and admin tooling, while still being able to approve, move, and exfiltrate the same record end to end. That is how separation-of-duty failures survive clean audits.

This problem is amplified in connected systems because access is often distributed across SaaS platforms, APIs, and automation accounts rather than concentrated in one IAM boundary. Traditional review workflows focus on whether a single entitlement is justified, not whether the full chain of actions is safe. NHI Management Group’s Ultimate Guide to NHIs — Key Challenges and Risks shows how broad, poorly governed access becomes hard to see once identities and secrets multiply across services. Current guidance also aligns with the NIST Cybersecurity Framework 2.0, which pushes organisations toward stronger identity assurance and governance outcomes rather than isolated entitlement checks.

In practice, many security teams discover SoD violations only after a fraudulent workflow, privileged misuse, or data exposure has already crossed system boundaries.

How It Works in Practice

SoD risk in connected systems has to be evaluated as a business process, not as a list of independent permissions. The question is not simply, "Can this person approve this request?" It is, "Can this person approve, modify, fulfil, and attest to the same transaction across the tools that actually execute it?" That requires correlating identities, roles, service accounts, and event logs across systems.

Operationally, mature programmes map critical workflows first, then identify incompatible steps that must never sit with the same human, agent, or service identity. For example, a requester should not also be the approver, exporter, reconciler, and audit signer for the same asset. This is especially important where non-human identities automate parts of the workflow. NHI Management Group’s Ultimate Guide to NHIs notes that NHIs outnumber human identities by 25x to 50x in modern enterprises, which makes process correlation harder and more urgent. The OWASP Non-Human Identity Top 10 is also relevant because service accounts, API keys, and automation tokens can quietly bridge systems that app-level reviews treat as separate.

• Map the transaction path end to end, including humans, bots, and service accounts.
• Define toxic combinations at the workflow level, not just the entitlement level.
• Correlate access across SaaS, APIs, and back-office systems before certifying compliance.
• Use event and activity telemetry to validate what identities can actually do together.

Where possible, align review design to NIST SP 800-53 Rev 5 Security and Privacy Controls so SoD is tied to control effectiveness rather than a checkbox attestation. These controls tend to break down in highly federated SaaS estates where identity data is fragmented and no single system has full process visibility.

Common Variations and Edge Cases

Tighter SoD enforcement often increases review effort and workflow friction, requiring organisations to balance stronger prevention against faster operations. That tradeoff becomes visible in shared service centres, delegated admin models, and emergency break-glass processes, where rigid rules can slow legitimate work.

There is no universal standard for this yet, so current guidance suggests risk-based SoD design: apply the strictest correlation to high-impact workflows such as payments, provisioning, refunds, exports, and production changes. Lower-risk tasks can use lighter review thresholds. The main edge case is automation. When an agent or integration performs multiple steps, the SoD question shifts from "who has access" to "which identity can chain those steps without independent oversight." That is where app-level review fails most often, because each permission looks defensible in isolation.

Teams should also watch for "shadow SoD" failures created by admin consoles, direct database access, or privileged vendor support accounts. Those paths often bypass the controls that business users see in the front-end application. For a broader view of how weak governance and excessive privilege compound risk, the Top 10 NHI Issues and the 52 NHI Breaches Analysis both illustrate how hidden identity paths undermine apparently clean access reviews.

Best practice is evolving toward continuous SoD monitoring, but organisations with fragmented logging or weak identity linkage will still struggle to prove whether a transaction was safe after the fact.

Related resources from NHI Mgmt Group

• How should security teams run access reviews for non-human identities?
• When do NHI access reviews create more value than a one-time cleanup?
• When does JIT access create more risk than it reduces?
• Why do traditional access reviews miss non-human identity risk?