Treat SAP service accounts, API users, and Communication Arrangements as first-class identities in SoD analysis. The practical test is whether a non-human identity can initiate, modify, and complete a sensitive business process without human separation of duties. If it can, the control model is incomplete and the audit trail is too narrow.
Why This Matters for Security Teams
S/4HANA service accounts, API users, and Communication Arrangements are not just technical plumbing. They can create, post, approve, and integrate business transactions at machine speed, which makes them part of the control environment, not outside it. Security teams that treat these identities as low-risk “background” access often miss the fact that a single over-privileged account can bypass segregation of duties, widen audit scope, and mask fraud or process abuse.
This is why NHI governance has to connect identity, business process, and audit evidence. NHI Management Group’s Ultimate Guide to NHIs — Regulatory and Audit Perspectives and Top 10 NHI Issues both stress that visibility and lifecycle control are foundational, especially where credentials are long-lived and permissions drift over time. Current guidance from the NIST Cybersecurity Framework 2.0 also reinforces identity governance as part of broader risk management, not a separate admin task.
In practice, many security teams encounter a SoD failure only after an audit finding, a process exception, or an unexplained posting has already occurred, rather than through intentional design.
How It Works in Practice
The practical model is to govern SAP NHIs by business effect, not by account type alone. That means mapping each service user, technical user, RFC destination, API user, and Communication Arrangement to the business process it can influence, then testing whether it can initiate, modify, and complete a sensitive workflow without human separation of duties. If the answer is yes, the control model is incomplete.
Security teams should require three layers of control:
- Least privilege at the SAP role level, with permissions reviewed against business process impact rather than system ownership.
- Credential governance with short TTLs where possible, strict rotation where TTLs are not possible, and explicit offboarding for dormant integrations.
- Monitoring that joins identity activity to transaction context, so logs show what the NHI did, which process it touched, and whether the action crossed SoD boundaries.
That approach aligns well with SAP governance work already being done in audit and compliance programs. The Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is useful here because lifecycle discipline is what prevents technical users from becoming permanent back doors. For control design, teams can also use the NIST CSF identity concepts alongside SAP role review processes to support repeatable review, approval, and evidence collection.
Where this gets operationally important is integration-heavy S/4HANA landscapes: API chains, middleware, and scheduled jobs can combine privileges in ways that are not obvious from a single role assignment. These controls tend to break down when service accounts are reused across multiple business processes because privilege ownership becomes blurred and audit evidence no longer maps cleanly to one control objective.
Common Variations and Edge Cases
Tighter governance often increases operational overhead, so organisations have to balance control depth against release speed and integration complexity. In SAP environments, that tradeoff shows up most clearly when teams manage legacy RFC users, shared technical accounts, or vendor-managed integrations that were never designed for modern lifecycle controls.
There is no universal standard for every SAP deployment, but current guidance suggests treating these cases as exceptions with compensating controls, not as reasons to relax the model. For example, a shared interface account may be unavoidable in a legacy system, but it should still be constrained by network boundaries, monitored for unusual transaction combinations, and reviewed with a documented business owner. Where possible, teams should move toward narrower purpose-built identities rather than broad technical reuse.
Another edge case is audit scope. If an NHI can only submit data but cannot approve or post it, the SoD risk is different from an account that can both create and finalize financial or procurement actions. That distinction matters in SAP because process depth, not just access breadth, determines whether the identity can drive a complete harmful workflow. NHI Management Group’s research on Top 10 NHI Issues is especially relevant here, because over-privilege and weak rotation are still common failure modes in production.
For teams formalising control baselines, the key question is simple: can the NHI complete a business process that a human SoD model was supposed to split apart? If yes, the account is governance-critical, regardless of how SAP labels it.
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-03 | Covers rotation and lifecycle risk for SAP technical and service accounts. |
| CSA MAESTRO | Provides governance patterns for autonomous and machine-driven identities in enterprise workflows. | |
| NIST CSF 2.0 | PR.AC-4 | Identity and access governance is central to SoD and least-privilege enforcement. |
Tie SAP NHI entitlements to business process risk and review access as part of identity governance.
