SAP segregation of duties checks need governance, not spreadsheets

At a glance

What this is: This is an analysis of why SAP segregation of duties checks fail when teams rely on spreadsheets instead of governance tied to SAP authorization logic.

Why it matters: It matters because IAM and IGA teams managing SAP access need controls that can keep up with derived roles, org-level values, and audit evidence requirements.

Context

SAP segregation of duties in ECC and S/4HANA becomes a governance problem when access is assembled through roles, organizational values, and historical decisions that are hard to unwind. The article argues that manual checks are not failing because the control is unimportant, but because the control design no longer matches how SAP actually grants access.

Spreadsheets and periodic exports cannot reliably capture conflicts that emerge across PFCG roles, derived roles, temporary assignments, custom transactions, and cross-system access. In SAP environments, the question is not whether SoD exists, but whether the organisation can prove it is checking SoD against the real authorization model in a repeatable way.

Key questions

Q: What breaks when SAP SoD checks are done with spreadsheets only?

A: Spreadsheets miss how SAP combines roles, organisational values, derived access, and cross-system privileges into effective execution power. They also age quickly, so the control becomes a retrospective report rather than a live governance process. The result is inconsistent evidence, missed conflicts, and poor audit defensibility.

Q: Why do SAP SoD conflicts appear even when individual roles look clean?

A: Conflicts often emerge from accumulated access rather than from a single role. Derived roles, temporary assignments, emergency access, copied templates, and organisational values can create the toxic combination only when evaluated together. That is why role-level review alone is not enough.

Q: How should organisations prevent toxic SAP access before it reaches production?

A: Use preventive SoD checks during provisioning and role design, then simulate the effect of the requested access against approved rules before changes are granted. This shifts governance from after-the-fact cleanup to pre-authorisation control, which is far easier to defend in audits and business reviews.

Q: What evidence do auditors expect from SAP SoD governance?

A: Auditors expect repeatable analysis, clear rule definitions, review history, and traceable decisions across users, roles, and time. They want to see that SoD is governed continuously, not reconstructed from ad hoc exports when an audit starts.

Technical breakdown

Why transaction-based SoD checks miss SAP authorization reality

SAP segregation of duties is not limited to transaction codes. In ECC and S/4HANA, the effective privilege comes from authorization objects, organisational levels, derived roles, and access paths that can bypass what users see on the screen. If SoD rules are built only on transactions, they miss the way SAP composes access into real execution power. That is why a user can look clean in a report but still hold conflicting access once the underlying authorization model is considered.

Practical implication: Model SoD on SAP authorization paths, not just transaction lists.

How role proliferation and org-level values create hidden conflicts

Mature SAP landscapes accumulate risk through copied roles, template drift, temporary assignments, firefighter access, and organisational values that widen scope. A single role may look harmless, but when it is combined with derived roles or reused across systems, it can create a conflict that is invisible in isolation. This is why manual matrices age badly. They do not capture how access accumulates over time across the full role set.

Practical implication: Review SoD at the combined user-and-role level across all active assignments.

Why S/4HANA and Fiori expand the analysis surface

S/4HANA simplified the user experience but did not simplify the control problem. Access can be exercised through Fiori catalogs, OData services, CDS views, background jobs, and APIs, so screen-based review is no longer enough. The technical issue is that the same business action may be reachable through multiple backend paths, each with different authorization dependencies. SoD logic must therefore cover the full execution chain, not just the interface layer.

Practical implication: Include backend services and API access paths in SoD rule coverage.

Threat narrative

Attacker objective: The objective is to obtain conflicting business execution power inside SAP without the control model detecting it in time.

1. Entry occurs when a user or role assignment creates access through copied templates, derived roles, emergency access, or inconsistent authorization values rather than through a single, well-governed role.
2. Credential access in this context is the accumulation of incompatible privileges across multiple SAP roles, which a spreadsheet can miss because it does not evaluate effective authorization paths.
3. Escalation happens when access spans multiple processes or systems, turning a seemingly ordinary assignment into toxic combination risk across procure-to-pay, record-to-report, or adjacent applications.
4. Impact is audit failure, uncontrolled business execution power, and increased exposure to fraud or segregation-of-duties violations that cannot be explained or evidenced cleanly.

Breaches seen in the wild

• SAP Kubernetes secrets exposure 2023: Kubernetes secrets committed to GitHub exposed 203 valid registry credentials, including SAP artifact repository access. SAP closed it after Aqua's report.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Spreadsheet SoD is a control artefact, not a governance model: manual matrices can record findings, but they cannot keep pace with SAP access that changes through derived roles, org-level values, and cross-system combinations. That makes the apparent control weaker than the business thinks it is. The practitioner implication is that SoD governance must be tied to SAP authorization logic, not document management.

Role proliferation is the real source of SoD decay: the most dangerous conflicts are rarely created by a single role. They emerge when copied roles, temporary assignments, emergency access, and historical exceptions accumulate into effective privilege that no one reviews as a whole. Practitioners should treat role sprawl as a governance failure, not a reporting inconvenience.

Cross-system access turns SoD into a process-control problem: SAP may look clean in isolation while related systems complete the toxic combination. That means a narrow SAP-only review can overstate control maturity and understate business risk. The practitioner conclusion is that SoD must follow the business process end to end.

Preventive governance matters more than quarterly detection: waiting for audit season turns SoD into a backlog exercise. The better model is to test conflicts before role changes reach production, then preserve evidence continuously rather than reconstructing it later. The practitioner implication is that audit readiness should emerge from normal control operation.

Derived roles create a hidden authorisation dependency chain: a control model that assumes template review equals risk review misses the effect of organisational values and inherited access. That assumption fails because the final privilege is often decided at assignment time, not design time. The implication is that SAP governance needs rule logic that evaluates effective access, not just static role content.

What this signals

Governance has to move from reporting to decision time: in SAP environments, SoD cannot be a quarterly reconciliation exercise if role assignments, derived access, and emergency privileges keep changing. The control point needs to sit where access is granted, because that is where the effective risk is created.

Effective access, not role content, is the unit of control: SAP teams that govern only template roles will continue to miss conflicts introduced by organisational values and inherited assignments. The practical shift is to judge the privilege that exists after all dependencies are resolved, not the role definition alone.

For practitioners

• Map SoD rules to SAP authorization logic Define conflicts using authorization objects, organisational values, derived roles, and execution paths instead of relying on transaction-code pairs alone.
• Run snapshot-based SoD checks Evaluate each access snapshot against approved rules after role redesigns, transports, and access reviews so findings stay aligned to the current landscape.
• Add preventive checks before provisioning Simulate role assignments and access requests before production change so toxic combinations are blocked before they reach the business.
• Extend SoD review across connected systems Include non-SAP access paths when business processes span multiple platforms, because a clean SAP report can still hide end-to-end conflict.

Key takeaways

• SAP SoD fails when manual methods track role lists but not the authorization paths that actually create business power.
• The risk compounds across derived roles, org-level values, emergency access, and connected systems, which is why spreadsheet reviews go stale quickly.
• Preventive checks, snapshot-based analysis, and process-aligned rule logic are the controls that make SAP SoD defensible in practice.

Key terms

• Segregation of Duties: Segregation of Duties is a control principle that prevents one person or role from combining incompatible permissions that could create fraud, error, or undetected change. In ERP environments, it must account for roles, transactions, approvals, and compensating controls across business processes.
• Derived role: A derived role is a role computed from context rather than assigned permanently to a user or service. It helps teams express conditional access without exploding role counts, but it depends on reliable attributes, clean policy design, and strong governance over how those roles are inferred.
• Organisational Value: An organisational value is a field-level scope attribute that changes what a SAP role can act on, such as company code or plant. These values can quietly widen or narrow effective access, so SoD analysis must evaluate the assigned value, not just the role name.
• Preventive SoD Check: A preventive SoD check evaluates access before it is granted or redesigned so toxic combinations are stopped early. It is stronger than after-the-fact review because it turns SoD into an approval control rather than a cleanup exercise.

Deepen your knowledge

NHI governance, identity lifecycle management, and secrets management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM or identity governance programme, it is worth exploring.