How should security teams uncover toxic access combinations across ERP and identity systems before quarterly reviews miss them?

Security teams should connect ERP, identity, and application data into one governance view so entitlements can be evaluated in context, not in silos. The goal is to detect segregation of duties conflicts, inherited access, and role drift as changes happen. Continuous monitoring, cross-system correlation, and policy-based reviews reduce the chance that clean-looking access masks real toxic combinations.

Why This Matters for Security Teams

toxic access combination rarely show up as a single bad entitlement. They emerge when ERP roles, inherited identity permissions, and application-specific grants combine into a path that looks legitimate in each system but unsafe in aggregate. Quarterly access reviews are too slow for environments where joins, transfers, vendor onboarding, and emergency access can change privilege in days, not months. The operational problem is not just over-access; it is cross-system context loss.

That is why security teams need governance views that correlate business roles, directory groups, ERP roles, and actual application usage in one place. NHI Management Group’s Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which is a useful reminder that entitlement sprawl is usually systemic, not accidental. For access review design, NIST’s SP 800-53 Rev. 5 remains relevant because it ties access control, auditability, and continuous oversight together instead of treating review as a periodic paperwork exercise.

In practice, many security teams discover toxic combinations only after a finance close, audit finding, or fraud investigation has already exposed the gap.

How It Works in Practice

The practical answer is to build a unified entitlement graph that maps users, service accounts, ERP business roles, directory groups, application permissions, and SoD rules into a single control layer. That allows reviewers to evaluate not just whether an access item is approved, but whether the full combination creates a conflict. Current guidance suggests using policy-based review logic rather than static spreadsheets, because the risk sits in relationships: a user may hold two harmless roles in isolation, yet become able to create and approve the same financial transaction when combined.

Start by normalizing identity data from the IdP, ERP, PAM, and key business applications. Then enrich it with ownership, risk classification, and usage signals so the review engine can flag dormant access, inherited access, and role drift. The OWASP Non-Human Identity Top 10 is useful here because the same visibility and lifecycle issues that affect service accounts also affect human-adjacent administrative paths: secret sprawl, over-privilege, and poor rotation all distort review outcomes. NHI Management Group’s State of Non-Human Identity Security reports that only 1.5 out of 10 organisations are highly confident in securing NHIs, which shows how often access governance lacks reliable context.

• Correlate ERP approvals, directory entitlements, and application usage before the review is sent to managers.
• Define SoD rules as machine-readable policy, not narrative policy text.
• Flag entitlements that are valid individually but toxic in combination.
• Prioritise changes, exceptions, and privileged paths for continuous review instead of waiting for the quarter close.

These controls tend to break down in heavily customised ERP environments because role inheritance, indirect assignment, and local overrides can hide the true effective permission set.

Common Variations and Edge Cases

Tighter cross-system review usually increases data-integration and policy-maintenance overhead, so organisations must balance stronger prevention against the cost of normalising messy identity and ERP records. That tradeoff matters most where business roles are fluid, contractors move quickly, or local subsidiaries have different approval models. In those environments, a single global SoD catalog can create false positives unless it is tuned to the actual operating model.

Best practice is evolving around exception handling. Some teams use risk-based thresholds so low-impact conflicts are routed for attestation while high-impact combinations trigger automated removal or temporary restriction. Others add continuous monitoring to catch drift between quarterly certifications, especially for privileged users and shared accounts. There is no universal standard for this yet, but the direction is clear: review must follow effective access, not just recorded entitlement.

For broader governance context, the Top 10 NHI Issues highlights how excessive privilege and weak monitoring repeatedly undermine control programs, while 52 NHI Breaches Analysis shows how quickly access paths become operational incidents once visibility is lost. The same lesson applies to ERP governance: if the organisation cannot see inherited and indirect access in near real time, quarterly reviews will always be too late.

Related resources from NHI Mgmt Group

• How should security teams evaluate privileged access management before deploying it across human, machine, and certificate identities?
• How should security teams reconcile identity records between governance systems and actual access in complex environments?
• How should security teams run access reviews for non-human identities?
• How should security teams run SOX access reviews across multiple in-scope systems?