They often over-focus on what users see in the interface and undercount backend execution paths. Fiori, OData, CDS views, background jobs, and APIs can all carry the same business risk through different routes. A credible SoD programme has to inspect those routes, not just screen transactions.
Why This Matters for Security Teams
SoD failures in S/4HANA are often treated as a user-interface problem, when the real risk sits in the backend execution model. A single business action can be initiated through Fiori, OData, CDS views, batch jobs, RFC-enabled functions, or APIs, and each route may bypass the transaction codes auditors traditionally inspect. That makes classic rule sets brittle unless they are tied to actual execution paths and underlying privileges.
This is where identity and privilege visibility matters. NHI Management Group notes that 97% of NHIs carry excessive privileges in practice, which is a reminder that over-entitlement is not limited to service accounts and scripts; it also shows up in application-layer access that can execute business logic outside the expected front door. The broader lesson aligns with the Ultimate Guide to NHIs and the control intent in NIST Cybersecurity Framework 2.0: account for what can actually perform the action, not just what a reviewer can see on a screen.
In practice, many security teams discover SoD conflicts only after a payment, posting, or master-data change has already been executed through a non-obvious path, rather than through intentional design-time review.
How It Works in Practice
Credible SoD analysis in S/4HANA starts by mapping business-risky functions to all executable access paths, then testing whether any one identity can complete the full chain alone. That means looking at end-user roles, technical roles, background processing, integrations, and the privileges behind OData services and CDS consumption. A transaction that appears segregated at the GUI level may still be reachable through a batch job or API that uses a broader technical role.
Security teams usually get better results when they combine role design with runtime evidence. Current guidance suggests reviewing:
- Fiori catalog and group access, not just SAP GUI transactions.
- OData services and API authorisations that can invoke the same business object.
- Background jobs, RFC destinations, and technical users that execute on behalf of business functions.
- Derived roles and inherited authorisations that silently widen the effective access surface.
That operational view is consistent with the Ultimate Guide to NHIs, which emphasizes visibility into non-human execution paths and lifecycle controls, and with the control logic in NIST Cybersecurity Framework 2.0, which prioritizes access governance and continuous risk management. The practical goal is to decide whether a user, service, or job can create incompatible outcomes, then enforce compensating controls where technical separation is not possible.
Teams also need to verify whether SoD checks are performed at provisioning time only, or whether they are re-evaluated when roles, interfaces, and integrations change. Because S/4HANA landscapes are dynamic, static role catalogs age quickly unless they are paired with periodic recertification and exception tracking. These controls tend to break down when custom extensions proliferate faster than the SoD rule set can be updated, because the business logic moves faster than the review model.
Common Variations and Edge Cases
Tighter SoD controls often increase design and review overhead, so organisations have to balance stronger separation against release speed and operational friction. That tradeoff becomes sharper in S/4HANA environments with heavy customisation, where no universal standard exists for every extension pattern and guidance is still evolving.
One common edge case is shared technical accounts. They may be necessary for middleware or scheduling, but they can also collapse separation if multiple business processes depend on the same credential. Another is CDS-based exposure: a view may look harmless until it is combined with write-capable service logic elsewhere in the stack. A third is emergency access. Break-glass roles are legitimate, but they should be time-bound, logged, and reviewed as exceptions rather than treated as normal access.
For teams using broader identity governance, the main lesson is to align SoD with actual execution authority. That means treating APIs, jobs, and service identities as part of the control surface, not as exceptions outside the programme. The NHI security gap documented by NHI Mgmt Group is a useful reminder that invisible privilege paths are usually where segregation breaks first.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | SoD breaks when non-human access paths are over-privileged or untracked. |
| NIST CSF 2.0 | PR.AC-4 | Access authorisation must cover all execution paths, not only UI transactions. |
| NIST AI RMF | The governance lesson is continuous risk monitoring across changing system behaviour. |
Inventory SAP technical identities and reduce privileges on jobs, APIs, and integrations to the minimum needed.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
