ECC-era rules break because they model transactions and old authorization objects, while S/4HANA adds Fiori start authorizations, CDS-based checks, and API access paths. That mismatch can hide real conflicts or create false confidence that segregation exists. Teams need to revalidate the ruleset against the current app and data control surface.
Why ECC SoD logic stops matching the control surface in S/4HANA
ECC-era segregation-of-duties logic usually assumes a transaction-code world. S/4HANA changes that model by moving important actions into Fiori launchpad access, CDS-backed authorisation checks, and API-mediated workflows. If the ruleset still watches only classic t-codes and old object combinations, it can miss the real route to the business function.
That is why a rule can look clean on paper while the user still has effective access through a newer path. The control problem is not only “which job role?” but “which app, service, or data action can actually reach the sensitive process?”
What kinds of SoD conflicts become invisible or misleading
When the ruleset is not remapped, two failure modes appear. First, a true conflict may be hidden because the risky capability now lives behind a Fiori app, OData service, or CDS check that the ECC matrix never models. Second, a false conflict may remain in place because the old transaction is blocked even though the user can still complete the same business step another way.
The result is distorted assurance. Teams may think they have segregated procurement, payments, journal posting, or master-data change paths when the actual entitlement surface still permits one person, role, or automation path to combine those powers.
For a deeper SoD ruleset perspective, Segregation of Duties (SoD) Guide is the right starting point because it treats conflicts, mitigations, and the extension of segregation into service-style access as first-class governance problems.
How teams should revalidate SoD in S/4HANA
Revalidation should start from the current process path, not the legacy role catalogue. Map each critical business activity to the actual launchpad tile, backend service, CDS-based check, and API path that can trigger it, then test whether the SoD rule still catches the real combination of access needed to complete that activity.
This is where rule design and access design have to meet. If a business action can be reached by multiple interfaces, the control needs coverage across those interfaces, and the review needs to distinguish between a blocked transaction and a still-usable alternative path.
If you need a reference for the broader SAP exposure pattern that motivates this kind of revalidation, SAP Kubernetes secrets exposure 2023 shows how SAP-adjacent access material can become operationally sensitive when it is exposed outside the intended control boundary.
Risk and Threat Considerations
Outdated SoD rules create two security risks at once, control blind spots and false assurance. The first leaves a real business function reachable through a newer access path; the second makes teams believe a toxic combination is prevented when only the old ECC entry point was removed.
Failure mechanism: The ruleset is anchored to transactions and legacy authorization objects, while S/4HANA decisions are enforced through Fiori start authorisations, CDS checks, and APIs that the old model does not fully represent.
Impact: An attacker, insider, or over-privileged user can preserve practical access to sensitive business actions, bypass intended segregation, and pass reviews that rely on an incomplete rule matrix.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack surface, CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-5 — Account Management | SoD accuracy depends on current account and access assignment governance. |
| Recommendation — Review and revalidate privileged and business access assignments against active business paths. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Incomplete SoD mapping can leave users with more effective access than intended. |
| AU-6 — Audit Record Review, Analysis, and Reporting | SoD assurance needs evidence that actual execution paths match intended separation. | |
| Recommendation — Limit each role to the minimum access needed across all S/4HANA access paths. Review logs and audit trails for actions that bypass legacy transaction-based controls. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The question is about whether access rules still enforce separation in the current system. |
| Recommendation — Align access-control rules to the live S/4HANA application and service surface. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | API-mediated S/4HANA actions can preserve sensitive functions outside ECC transaction checks. |
| Recommendation — Test API function authorization to ensure critical business actions remain segregated. | ||
Practitioner Guidance
What to verify: Validate each critical SoD rule against the live business path, not the historical transaction list. For every high-value process, confirm the launchpad entry, backend service, and data-level check all align with the intended conflict definition.
Common mistake: Treating “transaction blocked” as equivalent to “process blocked” is the fastest way to miss a real segregation failure in S/4HANA. If a user can still reach the same outcome through a different app or API, the rule is incomplete.
What good looks like: The control matrix is expressed in terms of actual business capability, the review evidence shows coverage across UI and service paths, and exceptions are limited, documented, and revalidated after each functional change.
Practitioner takeaway: In S/4HANA, SoD is only trustworthy when it is anchored to the current application and data access surface, not to ECC-era transactions that no longer represent how the process is actually executed.