SoD controls become brittle, hard to evidence, and easy to lose during upgrades or refactoring. If access rules are embedded in custom logic, a migration can remove the enforcement point while leaving the business risk unchanged. The result is a governance gap that looks like modernization success but behaves like control erosion.
Why This Matters for Security Teams
When SoD is embedded inside legacy SAP custom code, the control is no longer a clear policy boundary. It becomes part of an application implementation that can be bypassed, duplicated, or quietly removed during upgrades, refactoring, or emergency fixes. That creates a gap between what audit evidence suggests and what the system actually enforces. NHI Mgmt Group’s Ultimate Guide to NHIs — Standards frames this as a governance and lifecycle problem, not just a technical one, and the same logic applies to access segregation in ERP environments.
The risk is amplified because customisations often outlive the staff who wrote them. A control may look stable until a patch replaces the code path, a transport changes the authorization object, or a new integration route never inherited the old check. Current guidance from NIST Cybersecurity Framework 2.0 still points teams back to managed access, continuous oversight, and recoverable evidence rather than hidden enforcement points. In practice, many security teams discover SoD erosion only after an upgrade has already gone live and the exception trail is gone with it.
How It Works in Practice
Legacy SAP SoD controls usually fail in one of three ways. First, the control is coded directly into a custom transaction, user exit, or enhancement spot, so the rule exists only where that code executes. Second, the business process is split across multiple modules, but the SoD check covers only one path, leaving alternate routes untouched. Third, change management treats the custom logic as functional code, not as a security control, so testing verifies that the process still works but not that the segregation rule still blocks risky combinations.
In a healthier model, SoD should be expressed as policy, reviewed as policy, and evidenced as policy. That means defining the sensitive combination at the role and workflow layer, not burying it in bespoke logic. Teams usually pair RBAC with compensating approvals, JIT access, and monitored exceptions so the control can be demonstrated even when the application changes. NHI Mgmt Group guidance on Ultimate Guide to NHIs — Standards is relevant here because the same lifecycle discipline applies to service accounts, API keys, and other machine identities that often execute SAP-adjacent processes. For the control-plane side, NIST Cybersecurity Framework 2.0 reinforces the need to identify, protect, detect, respond, and recover around access governance, not just around system availability.
- Keep SoD definitions outside custom code where possible, so they survive transport and refactoring.
- Test the control after patches, upgrades, and configuration changes, not only during initial rollout.
- Capture evidence that shows the rule was enforced, not just that the application still functions.
- Review machine identities that trigger SAP workflows, because a service account can bypass the intended human approval path.
These controls tend to break down when a business-critical workaround is hard-coded for a specific module and then reused as a general integration pattern.
Common Variations and Edge Cases
Tighter segregation often increases operational friction, requiring organisations to balance auditability against release speed and process continuity. That tradeoff becomes sharper in SAP landscapes with heavy custom development, because the same team may own both the business logic and the security exception path. There is no universal standard for this yet, but current guidance suggests that the more control logic is embedded in code, the more brittle the governance model becomes.
One common edge case is a compensating control that exists only on paper. For example, a manual review may be documented in the control library, while the actual SAP workflow no longer generates a review queue after a process redesign. Another edge case is shared technical accounts, which can blur accountability and make SoD evidence meaningless even when the functional control still exists. A third is multi-system orchestration: the SoD check may work in SAP, but downstream APIs, batch jobs, or external middleware can still complete the prohibited action.
Practitioners should treat custom SoD as a temporary exception, not a permanent design pattern. When a business process truly requires bespoke logic, the evidence needs to show the control objective, the owners, the test method, and the fallback if the control fails. That is the operational lesson in both SAP governance and broader NHI security: if the enforcement point is fragile, the risk is not reduced, only hidden.
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-01 | Custom SAP logic often hides machine-identity access paths and weakens control visibility. |
| NIST CSF 2.0 | PR.AC-4 | SoD failures are access-control failures when customisations outlive the policy they enforce. |
| NIST AI RMF | Autonomous workflows and policy drift require ongoing governance and accountability. |
Assign ownership for policy changes and continuously monitor whether controls still work as intended.
