Independent control breaks down. The user can complete an end-to-end financial action without a second person validating necessity, accuracy, or beneficiary details. In practice that can mean self-approved purchase orders, journal entries, or payments that look legitimate in the audit trail but bypass the control objective the workflow was meant to enforce.
Why This Matters for Security Teams
When SAP users can create and approve their own transactions, the control is no longer independent. That breaks segregation of duties, weakens auditability, and turns a workflow check into a formality. The risk is not only fraud; it also includes accidental self-approval of incomplete, inaccurate, or policy-violating actions that appear legitimate in the system record.
This matters because ERP controls are usually relied on to prevent one person from initiating and finalising a sensitive financial event. If the same identity can both submit and approve, the organisation loses the second set of eyes that is meant to catch bad data, missing support, or inappropriate beneficiaries. Current guidance from the NIST Cybersecurity Framework 2.0 reinforces that access control must support separation, accountability, and continuous oversight, not just successful login.
NHI Management Group’s research on non-human identity risk also shows why this pattern is dangerous at scale: the Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, a reminder that over-permissioning is common even when organisations believe controls are in place. In practice, many security teams encounter SoD failures only after an audit finding, disputed payment, or fraud review has already exposed the gap, rather than through intentional control testing.
How It Works in Practice
In SAP, the issue usually appears when the approval path is configured so that a requester can also act as the approver, either directly or through an insufficiently constrained role. The technical problem is not just user convenience. It is an authorisation design flaw that allows a single identity to satisfy two control steps that should remain separate.
Best practice is to treat the approval step as a distinct control point with independent policy enforcement. That usually means role design, workflow configuration, and exception handling all need to be aligned. In mature environments, approval authority is limited by amount thresholds, cost centre, vendor, document type, and business unit, with periodic review to ensure approvers are not also originators for the same transaction class. Where possible, access should be mapped to business roles rather than named individuals, and emergency exceptions should be time-bound and logged.
For teams implementing broader identity governance, the relevant model is not only classic IAM but also workload-style control thinking: permissions should be granted for a specific task, then revoked when the task is complete. The Ultimate Guide to NHIs highlights the operational cost of long-lived excessive privilege, while NIST Cybersecurity Framework 2.0 places emphasis on enforcing access boundaries and monitoring for misuse. In SAP terms, that translates to workflow rules that enforce independent approvers, exception queues with extra review, and control evidence that shows who initiated, who approved, and whether those identities were truly independent.
- Separate request and approval authorities for the same financial object.
- Block self-approval at the workflow layer, not only through policy documents.
- Review role assignments for inherited approver rights across templates and composite roles.
- Test emergency access and delegation paths for accidental bypass conditions.
These controls tend to break down when organisations rely on generic shared roles, poorly governed delegation, or custom SAP workflows that do not preserve a clean maker-checker separation.
Common Variations and Edge Cases
Tighter approval controls often increase operational overhead, requiring organisations to balance transaction speed against independent review. That tradeoff is real in high-volume finance teams, where rigid approval chains can create bottlenecks if not designed around business risk.
There is no universal standard for every SAP workflow pattern, so current guidance suggests tailoring controls to transaction value, materiality, and fraud exposure. Low-risk, repetitive requests may be handled with lighter approvals, but that should be a deliberate exception, not an accidental default. Shared service centres, temporary access for month-end close, and delegated authority during leave periods are common edge cases that need explicit time limits and post-event review.
This is also where SoD tooling can mislead teams if it checks only static role conflicts. A user may appear compliant in role-based reporting while still being able to create and approve through workflow routing, substitution rules, or emergency access. Organisations should test the actual business process, not just the role matrix. The Ultimate Guide to NHIs is useful here because it frames privilege as a lifecycle problem, not a one-time assignment, and that lens applies directly to privileged SAP approval paths.
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-03 | Addresses excessive, persistent privilege that enables self-approval paths. |
| NIST CSF 2.0 | PR.AC-4 | Separation of duties is an access control requirement for transaction approval. |
| NIST AI RMF | Governance and accountability apply when workflow decisions bypass independent review. |
Review privileged SAP roles and remove permissions that let one identity create and approve the same transaction.
