How should security teams enforce segregation of duties in SAP environments?

Why This Matters for Security Teams

segregation of duties is not just an audit concept in SAP. It is a practical control that stops one identity from creating, approving, and executing a high-risk business action end to end. In ERP environments, toxic combinations often emerge through role aggregation, emergency access, custom transactions, or poorly governed service users. Once that happens, the issue is not only fraud risk; it is also the loss of reliable financial controls and change accountability.

Current guidance suggests treating SoD as a prevention problem, not a detection problem. That means encoding conflicts into role design, workflow gates, and periodic recertification so the risky combination is blocked before assignment. This aligns with the broader access-control principles in NIST Cybersecurity Framework 2.0, especially around controlled access and governance. It also matters because SAP access rarely stays static; temporary elevation, shared admin accounts, and integration accounts can accumulate privilege without being noticed.

NHI governance is relevant here because many SAP functions are executed by non-human accounts that bypass the human approval path unless they are explicitly covered. The same access patterns that create NHI exposure in other systems also show up in ERP, where secrets, batch jobs, and technical users can silently inherit broad authority. The operational lesson from NHIMG research on ASP.NET machine keys RCE attack is that long-lived credentials and excessive privilege become incident pathways when governance is weak. In practice, many security teams discover toxic SAP combinations only after an audit exception, a payment error, or a privilege abuse investigation has already occurred.

How It Works in Practice

Effective SAP SoD enforcement starts with a defined conflict matrix, then moves that matrix into the access lifecycle. Security teams should map business-sensitive actions such as vendor setup, payment release, journal posting, master data changes, and role administration into machine-readable rules. Those rules then feed role engineering, access request approvals, and periodic reviews so the control is enforced consistently rather than interpreted case by case. This is where IAM, PAM, and RBAC need to work together: RBAC defines the baseline role, PAM handles elevation, and the SoD engine prevents conflicting combinations from being granted at all.

A practical design usually includes four steps:

• Identify toxic combinations by business process, not just by transaction code.
• Classify access by risk tier so conflicts can be blocked, compensating-controlled, or escalated.
• Use workflow approvals that check conflicts at request time, not after provisioning.
• Revalidate SoD periodically because SAP role changes, project access, and emergency assignments drift over time.

For teams modernising their control model, NIST Cybersecurity Framework 2.0 provides a governance structure, while ASP.NET machine keys RCE attack is a useful reminder that once privileged access is static and reusable, attackers and insiders can chain it into broader compromise. The strongest SAP programmes also tie SoD to secrets management and technical identities, because a service account with update rights and reusable credentials can bypass the human approval process entirely. That is why current guidance increasingly treats SoD as an entitlement control plus an operational monitoring control, not just a segregation report. These controls tend to break down when custom SAP roles, emergency access, and interface users are exempted from the same policy engine because exceptions become the normal path to production access.

Common Variations and Edge Cases

Tighter SoD enforcement often increases process friction, so organisations need to balance control strength against release speed, supportability, and business continuity. That tradeoff is especially visible in SAP environments with shared admin teams, outsourced operations, or frequent break-glass use.

One common exception is emergency access. Best practice is evolving, but current guidance suggests making emergency elevation time-bound, fully logged, and automatically reviewed after use rather than allowing standing privileged access. Another edge case is technical and interface accounts. These identities may not map cleanly to human SoD rules, yet they still need conflict coverage because they can post transactions, trigger workflows, or move sensitive data without manual oversight. A third case is custom code and integrations. If a bespoke Z interface or batch job can perform multiple sensitive actions, the control must look at effective capability, not only the named role.

For governance maturity, teams should align SAP SoD design with NIST Cybersecurity Framework 2.0 and treat compensating controls as temporary, not as a permanent substitute for clean role design. Where the organisation relies on long-lived service credentials, the risk profile resembles the broader NHI problems documented in NHIMG research, including the persistence of exposed secrets and over-privileged machine access. The operational reality is that SoD fails fastest in environments with heavy customisation, because rule exceptions multiply until no one can explain which combinations are actually safe.

Related resources from NHI Mgmt Group

• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams govern non-human identities in cloud environments?
• How should security teams govern SAP access during an S/4HANA migration?
• How should security teams govern non-human identities at scale?