They create segregation-of-duties risk because the same administrative surface can register services, change aliases, manage launchpad content, and inspect logs. If one person or role can do all of those tasks, they can influence both what users access and how backend services are reached, which weakens control separation.
Why This Matters for Security Teams
SAP Fiori transaction codes matter because they often sit at the intersection of user experience, backend service exposure, and administrative control. If a single role can register services, adjust aliases, and shape launchpad access, the same person can influence both what users see and what the system will execute. That collapses separation of duties into one surface, which is exactly the kind of control overlap security teams try to prevent. NHI Management Group’s research on the Ultimate Guide to NHIs shows why this matters: 97% of NHIs carry excessive privileges, and weak privilege discipline is a recurring driver of exposure.
The risk is not only accidental misuse. In SAP environments, administrative actions that look routine can alter execution paths, expose hidden capabilities, or create indirect access to sensitive backend functions. That is why the issue aligns with broader identity governance concerns in the NIST Cybersecurity Framework 2.0, where least privilege and access control are treated as operational controls, not paperwork. In practice, many security teams encounter SoD violations only after a change has already expanded effective access, rather than through intentional design.
How It Works in Practice
Transaction codes in SAP Fiori can be risky when they become a shortcut to multiple control domains. A user or support role may not just launch a task. They may also register services, maintain catalog or group content, map aliases, and inspect logs. That combination creates a governance problem because the same role can approve the path and then verify its own work. Current guidance suggests treating these capabilities as separate control planes even when they are exposed through one administrative interface.
A practical control model usually includes:
- Separate roles for service registration, launchpad administration, and log review.
- Approval workflow for changes that affect service exposure or backend routing.
- Periodic SoD review of transaction code assignments and derived roles.
- Monitoring for high-risk combinations of configuration and audit access.
- Restriction of privileged access to time-bound use cases where possible.
That approach maps well to the Top 10 NHI Issues because the same pattern appears in service accounts and automation: too much standing privilege, too much path overlap, and too little independent oversight. The OWASP NHI Top 10 also reinforces a familiar lesson for practitioners, which is that access should be minimized at the identity and action level, not only at the UI level. These controls tend to break down when SAP customizations blur the line between operational support and administrative authority because the same role can silently accumulate multiple control functions.
Common Variations and Edge Cases
Tighter SoD enforcement often increases operational overhead, requiring organisations to balance control integrity against support speed. That tradeoff is real in SAP estates where transport urgency, break-glass access, and small security teams can make perfect separation difficult. Best practice is evolving, but the current direction is clear: if a role can both change access and confirm the effect of that change, the control design is too permissive.
Edge cases arise when transaction access is indirect. For example, a role may not explicitly administer launchpad content, but a custom wrapper or composite role can still grant the same effective authority. Another common exception is emergency access. That should be time-bound, logged, and independently reviewed, not treated as a normal operating role. In mature programs, SoD analysis also extends to service identities and API-facing components, because human and non-human control overlap can produce the same risk pattern.
For teams building stronger governance, the safest lens is to ask whether one identity can influence request creation, request approval, and evidence collection. If the answer is yes, the SoD boundary is already weakened. This is especially true in environments with broad delegated admin rights or loosely governed transport paths, where administrative convenience can obscure the actual control surface.
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 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 | Excess privilege and control overlap are central to this SoD risk. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access is the core control principle behind SoD. |
| CSA MAESTRO | GOV-03 | Governance of privileged automation and admin actions applies to shared SAP control surfaces. |
Separate identity, administration, and audit duties so one principal cannot alter and validate access.
