Who is accountable for SoD risk when SAP access spans humans and machine identities?

Why This Matters for Security Teams

Segregation of duties fails fast when SAP access is judged only by named employees instead of by every identity that can execute the same business action. In SAP landscapes, the risk often sits in service accounts, communication users, technical RFC users, and background jobs that can bypass the human review process entirely. That is why NHI Management Group treats SoD as a business-process control, not a personnel-only checklist.

The practical concern is not just who requested access, but which identity can create, approve, post, export, or change the same record path. Current guidance suggests that identity reviews must cover humans and machine identities together, because an unreviewed technical account can preserve toxic access long after a user leaves. NHI Mgmt Group’s Ultimate Guide to NHIs shows how broad the exposure can be, while the OWASP Non-Human Identity Top 10 frames the same issue as an identity governance failure, not a narrow secrets problem.

For teams measuring materiality, NHI Management Group reports that 97% of NHIs carry excessive privileges, which makes SoD violations far more likely when technical identities are left out of recertification. In practice, many security teams encounter SoD drift only after an audit finding, a fraud review, or an outage caused by a privileged background account that was never mapped to a business control owner.

How It Works in Practice

The right model starts by defining the business process, then mapping every identity that can participate in that process. For SAP, that usually means humans, service accounts, communication users, batch jobs, integration users, and any external system account that can trigger postings or approvals. The control owner should not ask only, “Who has access?” but also, “Which identities can combine to complete a disallowed SoD chain?”

In practice, this requires identity inventory, role mining, and transaction-level analysis. A human user might not violate SoD alone, but the pair of a human approval role and a machine posting role can still create the same conflict if the machine identity is invisible to review. Best practice is evolving toward unified governance across NHI risk visibility and enterprise access controls, with policy aligned to what the identity can actually do in runtime conditions rather than what its title suggests.

Operationally, teams should:

• classify SAP identities by type, owner, purpose, and system boundary
• include technical users in SoD rule sets and periodic certification
• tie each machine identity to a business service and control owner
• review privileged combinations across humans and non-human identities together
• retire or rekey dormant technical accounts with the same rigor as leavers

NIST’s Cybersecurity Framework 2.0 supports this by pushing governance, access control, and continuous monitoring as an integrated function. These controls tend to break down when SAP landscapes have unmanaged integration sprawl, because the identities that create SoD risk are often owned by infrastructure teams rather than by the process owner.

Common Variations and Edge Cases

Tighter SoD governance often increases administrative overhead, requiring organisations to balance stronger fraud prevention against slower access provisioning and more frequent recertification. That tradeoff is especially visible when machine identities are short-lived, shared, or generated by orchestration tools.

There is no universal standard for this yet, but current guidance suggests three edge cases deserve special handling. First, shared technical accounts are a poor fit for SoD because attribution becomes weak and compensating controls are hard to prove. Second, interface users that only “move data” can still create SoD exposure if they write into posting or approval paths. Third, emergency access and temporary support accounts should be treated as high-risk exceptions, not as routine grants.

The safest operating model is to assign accountability to the control function that owns the business process, then force that owner to govern every identity class that touches the process. That includes human users, service accounts, and communication users, even when separate tools manage them. For broader context on technical identity sprawl and renewal failure, see Top 10 NHI Issues and the 2024 ESG Report: Managing Non-Human Identities. In mixed SAP environments, the model works until ownership is fragmented across ERP, security, and integration teams, because no one sees the full SoD chain end to end.

Related resources from NHI Mgmt Group

• Who is accountable when machine identities retain access after they should be retired?
• Who should own password governance when identity spans humans and non-human identities?
• Who should own access governance when identity spans human and machine accounts?
• Who is accountable when AI or machine identities are over-privileged?