The Five SAP Authorization Combinations That Quietly Break Your Control Environment

When most organizations review SAP access, they look at the obvious things: role names, transaction codes, the SoD matrix that GRC spits out every quarter, and whether managers clicked “approve” on the certification dashboard before the deadline. All of that matters. None of it is enough.

The exposures that actually lead to losses rarely sit inside a single role or a single transaction. They live in the combinations - small permissions that look innocuous on their own but, when one user holds enough of them, quietly add up to end-to-end capability. The ability to initiate a transaction, alter the data that supports it, push it through, and erase the breadcrumbs afterward. That is where fraud begins, and that is where most reviews stop looking.

The Association of Certified Fraud Examiners’ Occupational Fraud 2024: A Report to the Nations found that organizations lose an estimated 5% of revenue to occupational fraud annually, with a median per-case loss of USD 145,000 and a median duration of 12 months before detection. More than half of those cases involved either the absence of internal controls or the override of existing ones. Override is the keyword. Override is almost always an access problem.

This article walks through five SAP authorization combinations that consistently show up in fraud investigations and audit findings. Each is paired with a real, publicly documented case so you can read the source material yourself. None of these scenarios are exotic. All of them are common. Most are sitting in your production system right now.

Why “Combinations” Matter More Than Roles

A traditional access review asks process questions. Is the user still employed? Is the role still needed? Was it approved? Were SoD conflicts mitigated? Was the certification completed on time? Useful, but it measures whether the paperwork was done - not whether the company is actually exposed.

A fraud-focused review asks capability questions. If this user wanted to steal, could they? Who can both create a vendor and pay it? Who can change a bank account number the morning of a payment run? Who can post a journal and then alter the change log? Which dormant technical IDs still have wide-open RFC access that nobody has looked at in three years?

The difference matters because access accumulates. A temporary permission granted during a go-live becomes permanent. A power user picks up a role each time there’s an emergency. A technical ID created in 2015 still holds SAP_ALL because nobody is sure what will break if it’s removed. On the certification report, every line was approved by somebody. In the live system, one user can now do five things they were never meant to do together.

That is the gap this article addresses.

1. Vendor Master + Automatic Payment - The Classic Billing Scheme

Authorization objects to watch:

• F_LFA1_APP: Vendor master application authorization (determines which activities a user may perform on vendor master records across FI and Purchasing)
• F_LFA1_BEK: Vendor account authorization by authorization group
• F_BNKA_MAN: Bank master maintenance
• F_REGU_BUK: Automatic payment processing at the company code level (the object behind transaction F110)

Why this is dangerous

This is the textbook procure-to-pay fraud setup, and it is the single most common SoD conflict flagged in SAP GRC Access Control’s default ruleset, the Big Four audit rulesets, and the rulesets shipped by Pathlock, Onapsis, and Saviynt. One person can create a vendor (or, more often, modify the bank account of an existing one), then run or release the payment program. There is no second pair of eyes between “I made this change” and “money left the bank.”

Billing schemes - fraudulent invoices submitted through legitimate AP channels are among the highest-frequency asset misappropriation sub-schemes in the ACFE 2024 report, and they consistently rank near the top for combined frequency and median loss.1

A real case

In March 2026, a federal jury in Georgia convicted Kayricka Wortham, a former Amazon operations manager, and her partner Brittany Hudson of stealing approximately USD 9.4 million from Amazon through a fake-vendor scheme that ran from roughly January to June of 2022. Wortham fed fictitious vendor information to subordinates who entered it into Amazon’s vendor system; Wortham and a co-conspirator inside Amazon then approved the vendors, after which fake invoices were submitted and approved for payment. The proceeds went toward a roughly USD 1 million home, a Lamborghini Urus, a Tesla Model X, a Porsche Panamera, and other assets. The mechanics map almost perfectly onto the SAP authorization combination above: vendor creation capability + payment approval capability, with no enforced separation.

Red flags an auditor should look for:

New vendors whose names, addresses, or bank routing numbers closely resemble existing vendors. Bank account changes within a few days of a payment run. The same user ID appearing in vendor master change logs (table CDHDR/CDPOS filtered for LFA1, LFBK, LFB1) and in F110 payment run logs (REGUH, REGUP). Invoices that consistently fall just below the next approval threshold. Vendors with no purchase order activity but recurring payment activity.

What good looks like

Vendor master maintenance, bank data changes, and payment execution belong to at least three different people. Bank account changes specifically should trigger a callback-confirmation control with the vendor’s known contact - not the email address on the change request, since vendor email compromise is now one of the fastest-growing AP fraud vectors. If the team is too small to fully separate the duties, the mitigation language should explicitly name a compensating control. For example, a weekly review of the LFBK change log by someone outside AP, retained as audit evidence.

2. User Admin + Role Assignment + Profile Maintenance + Password Reset - The “Manufacture Your Own Privilege” Combo

Authorization objects to watch:

• S_USER_GRP: User group administration (with ACTVT 01, 02, 05, 06 being the dangerous ones; ACTVT 05 is lock/password reset)
• S_USER_AGR: Role assignment
• S_USER_PRO: Profile maintenance (the legacy path that still works and still grants SAP_ALL)
• S_USER_AUT, S_USER_TCD, S_USER_VAL: The supporting cast that lets an admin build new authorizations from scratch

Why this is dangerous

This is the basis-level equivalent of leaving the master key in the lock. A user holding all four can create an account, assign any role to it (including SAP_ALL), reset any other user’s password, and log in as that user. Every external auditor’s ITGC program treats unmitigated combinations of these objects as either a significant deficiency or a material weakness under SOX, depending on whether compensating controls actually function.

The risk is amplified by S_USER_GRP with a blank or * value in the user group field — which means the admin can reach every user in the system, including the CFO, the basis lead, and any firefighter ID.

A real-world pattern

A published industry case study documents exactly how this combination gets weaponized in practice. A manufacturing organization lost approximately USD 1.5 million in a fraud that traced back to a consultant’s ID left active for eight months after the project ended. In the QA system, the same ID still held SAP_ALL “just for testing,” and a trusted RFC connection from QA to Production made lateral movement trivial. When the consultant’s old laptop was compromised, the attacker followed the path: VPN → QA → trusted RFC to Production → modify table → change vendor bank account → payment goes out. No malware. No exploit. Just temporary access that nobody re-evaluated, combined with privileged role assignments that were never cleaned up.

The pattern is identical to the password-reset and privilege-escalation risk described above: the absence of routine recertification and the failure to enforce least privilege on user administration creates a path that requires no technical sophistication to exploit.

Red flags

Privileged role assignments performed outside the GRC workflow (visible in SUIM and table AGR_USERS change logs). Emergency / firefighter IDs with validity periods measured in years rather than hours. Password resets clustered around month-end or before high-value transactions. Any case where the user who assigned a role and the user who approved the access request are the same person.

What good looks like

User creation, role assignment, and password reset are split across at least two roles, ideally held by different people. Firefighter access goes through SAP GRC Emergency Access Management (or equivalent) with mandatory log review by a control owner who is not the firefighter user. Change documents on tables USR02, USR04, USH02, AGR_USERS, and USRBF2 are monitored, not just logged.

3. Direct Table Maintenance with Change Activity: Bypassing the Application Entirely

Authorization objects to watch:

• S_TABU_DIS: Table maintenance by authorization group (especially with &NC& or * in the auth group field)
• S_TABU_NAM: Direct access by table name
• S_TABU_CLI: Cross-client table maintenance - ACTVT 02 (change) and 06 (delete), together with SE16N, SM30, SM31, or SE16 in the user’s transaction set

Why this is dangerous

Every business rule in SAP - tolerance limits, posting period controls, three-way match settings, release strategies, account determination - ultimately lives in a configuration table. So does every audit trail. A user with broad change activity at the table layer can do four things that are nearly impossible to detect through normal monitoring:

1. Alter a control parameter just long enough to push a transaction through, then put it back (e.g., temporarily widening tolerance limits in T169G or invoice block reasons in T169P).
2. Modify posted financial data directly in BKPF / BSEG, bypassing the application layer that would normally write a change document.
3. Change vendor bank data in LFBK without going through XK02 / BP, which means the standard FI change-document trail may not capture it the same way.
4. Delete or modify rows in CDHDR, CDPOS, or the security audit log tables - the classic “cover your tracks” move that undermines every other detective control in the system.

A real audit finding

A publicly available KPMG audit working paper documents exactly this risk and how it materializes in practice. During testing of General IT Controls at an SAP customer, KPMG identified ten users from the BASIS and ABAP Development teams who held the combination of S_DEVELOP (object type DEBUG, ACTVT 01/02) together with SE16N, SA38, and SE38 transaction access - effectively giving them the ability to make direct table changes in production via the &SAP_EDIT command. KPMG then performed a critical test: they assigned SAP_ALL and SAP_NEW to a test user and attempted to edit the audit-log tables SE16N_CD_KEY and SE16N_CD_DATA. Those edits were blocked (SAP has internal hardcoded checks on those specific tables). However, the same user was able to edit the user master table USR02 directly - the table that holds password hashes and lock status.

This is the SOX-significant finding pattern in concentrated form: direct table change capability bypasses the application layer entirely, and while SAP protects some audit-log tables from edit, it does not protect the broader universe of sensitive tables. SAP has continued to release notes addressing this risk - including OSS Note 1468636 (&SAP_EDIT controls) and Note 3140539 (new SAL event definitions for SE16N change access).

Red flags

Direct table changes during close windows. SM30 / SE16N activity from user IDs outside the configuration team. Auth groups granted as * or &NC& in any production role. The Log Data Changes flag missing on sensitive tables in SE13. The system change option in SCC4 set to “modifiable” on a production client outside of a controlled change window.

What good looks like

Production clients set to “not modifiable” via SCC4, with unlocking treated as a logged, approved event. S_TABU_DIS and S_TABU_NAM restricted to ACTVT 03 (display) for normal admins and developers. Change activity at the table level reserved for firefighter access only, with full session recording and post-hoc review. Table change logging enabled at the system level (rec/client parameter) and on every sensitive table individually. Cross-client maintenance (S_TABU_CLI) treated as a separate critical privilege. Apply SAP Note 1468636 to restrict &SAP_EDIT and Note 3140539 to enable detection in the security audit log.

4. Journal Posting + Period Control - Where Financial Statements Get Reshaped

Authorization objects to watch:

• F_BKPF_BUK: Accounting document by company code (ACTVT 01 = post, 02 = change)
• F_BKPF_BLA: Document type authorization (some document types bypass workflow and substitution rules)
• S_TCODE for OB52: Open and close posting periods
• F_FAGL_LDR: Ledger group authorization (in S/4 / new G/L environments)

Why this is dangerous

Asset misappropriation is the most frequent category of occupational fraud (89% of cases in the ACFE 2024 study), but financial statement fraud is the most expensive - the median loss for the 5% of cases involving financial statement misstatement was USD 766,000, more than six times the asset-misappropriation median.1 And financial statement fraud is almost always an access-and-override story: someone with the ability to post manual journals also has the ability to reopen a closed period, or to post to a document type that skips the normal workflow, or to backdate an entry past the cutoff.

PCAOB Auditing Standard 2401 explicitly identifies this pattern as a management override technique: “recording fictitious journal entries, particularly those recorded close to the end of an accounting period to manipulate operating results.”

A real case

In August 2024, the SEC settled enforcement actions against National Energy Services Reunited Corp. and related parties involving a finance director at a subsidiary who had sole responsibility for providing the subsidiary’s financial results to the parent’s consolidated accounting system and for performing account reconciliations. According to the SEC, the finance director manipulated the company’s books and records by artificially inflating net assets and operating income by tens of millions of dollars, was able to misstate the subsidiary’s cash without any verification at the corporate level (because corporate treasury did not have access to subsidiary bank accounts), and covered up the scheme by preparing false certifications and fabricated bank documents. The company subsequently restated three years of financial statements, with operating income overstated by approximately 24% in one of the affected years.

This case illustrates the exact pattern the SAP authorization combination enables: when a single person controls both the posting capability and the reconciliation / verification capability, with no independent review at the consolidation layer, financial-statement misstatement becomes mechanically possible and the only thing standing between the capability and the misstatement is the integrity of the individual.

Red flags

Round-number journals at quarter-end (“$2,000,000.00” is almost never a real accrual). Reversals in the following period without supporting documentation. The same user appearing in both OB52 activity and F-02 / FB01 posting activity within the same close window. Document types used for manual entries that bypass the normal substitution and validation framework. Use of FBV0 (park and post) by users who would not normally have posting authority - a classic workaround.

What good looks like

Period open/close is segregated from journal posting. Manual journals above a defined materiality threshold require an independent approver, with the approval captured in the system, not on email. Document change logs (BKPF-CPUDT, BKPF-CPUTM, and the change document framework for FI) are reviewed monthly by someone outside the posting team. Standard journal entry analytics - Benford analysis, weekend/late-night posting, round-dollar testing are run continuously rather than once a year for the external auditors. Independent reconciliation of subsidiary or business unit balances by someone outside the posting and reconciliation chain.

5. Broad RFC + Background Job Authority + Legacy Technical IDs: The Risk Nobody Looks At

Authorization objects to watch:

• S_RFC: Authorization check for RFC access (with function group field set to * is the danger)
• S_RFCACL: Trust relationship between systems
• S_BTCH_JOB, S_BTCH_ADM, S_BTCH_NAM: Background processing
• S_DEVELOP: Especially with ACTVT 02 on object type DEBUG (debug-with-replace, which is its own critical-rated risk in every ruleset)

Why this is dangerous

A growing share of meaningful activity in modern SAP landscapes does not go through SAP GUI. It goes through RFC calls from middleware, scheduled batch jobs, RPA bots, BTP integrations, and the long tail of technical service users created during go-live and never reviewed since. These IDs are typically excluded from access reviews (“it’s a system ID, not a user”), they almost never get recertified, and they frequently hold authorizations far broader than the integration actually needs.

The fraud and breach scenarios here are less about a single dramatic theft and more about exfiltration, lateral movement, and persistent abuse. An RFC user with S_RFC set to * and a SAP_ALL-adjacent role can call almost any function module remotely, including BAPI calls that create vendors, post documents, or pull mass employee data.

A case documented in a CISA advisory

In May 2019, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) issued Alert AA19-122A in response to publicly released exploit tools dubbed “10KBLAZE” - tools that targeted SAP systems with misconfigured Message Server and Gateway access control lists. CISA confirmed that approximately 900 U.S.-facing SAP systems were detected in this vulnerable condition. Onapsis, the security firm whose research underpinned the alert, estimated that approximately 90% of an estimated 1,000,000 SAP production systems worldwide suffered from the misconfigurations the exploits targeted - and that successful exploitation could give an unauthenticated remote attacker full command of business-critical SAP systems, including the ability to create users with arbitrary privileges, modify or extract regulated data, and delete business application data entirely.

What makes this case especially relevant to the authorization-combinations theme is that the underlying problem was not a code vulnerability. The SAP security notes (#821875, #1408081, #1421005) had been available for more than ten years. The risk persisted because organizations had legacy RFC configurations and gateway/message-server ACLs that nobody had revisited since go-live, exactly the “set it and forget it” governance gap this article describes. Larry Harrington, former Chairman of the Board of the Institute of Internal Auditors, noted at the time that “this risk to SAP customers can represent a weakness in affected publicly-traded organizations that may result in material misstatements of the company’s annual financial statements (Form 10-K).”

Red flags

Service or interface IDs that have never been recertified. S_RFC granted with * in the function group or function module field. Background jobs created or scheduled by generic IDs. High-volume data extracts outside of the documented integration catalog. Technical IDs with interactive login capability (user type Dialog rather than System or Communication). RFC destinations stored in SM59 with hardcoded credentials and trust relationships pointing at non-production systems.

What good looks like

Every technical ID has a named human owner, a documented purpose, and an annual recertification. RFC authorizations are scoped to the specific function modules the integration actually uses, not the function group, and certainly not *. Interactive logon is blocked on system / communication user types. SM19 / SM20 security audit logging is enabled and reviewed for RFC activity. Trust relationships in SM59 and SMT1 are reviewed quarterly. Gateway and Message Server ACLs configured per SAP Notes 821875, 1408081, and 1421005. SAP’s published guidance for securing RFC communications, and the SAP Security Baseline, are followed rather than treated as aspirational.

The Common Thread

Across the cases above - and across most of the fraud investigations and SOX deficiency findings that originate in SAP, the same handful of root causes show up:

Temporary access was never removed. A user accumulated roles over years and nobody re-evaluated the total picture. The review process validated ownership instead of capability. Technical IDs sat outside governance entirely. Urgency was treated as a reason to bypass controls rather than to invoke a controlled emergency-access process. And the completion of the access review certification was treated as the same thing as the access being correct, which it isn’t.

The ACFE data points to the same pattern from a different angle: more than half of occupational frauds involve either the absence of an internal control or the override of an existing one, and tips remain the most common detection method (43% of cases), well ahead of internal audit, management review, or any automated control.1

What Mature Organizations Do Differently

The shift is from periodic certification to continuous assurance. The specific practices vary, but the pattern is consistent:

Preventive SoD checks happen at the moment of access request, not six months later in a quarterly report. Continuous monitoring runs against the live system for both SoD conflicts and sensitive-access usage, with exception alerts rather than gigabyte reports. Dormant access is removed automatically rather than waiting for the next certification cycle. Technical and interface IDs are governed under the same framework as human users, with named owners and recurring recertification. Emergency access is genuinely emergency - short-lived, fully logged, and reviewed by someone who is not the user. And the output of all of this is audit-ready evidence with ownership trails, not screenshots saved in SharePoint the week before the auditors arrive.

The Closing Thought

Most fraud doesn’t begin with a breach. It begins with a permission that nobody re-evaluated, combined with another permission that looked fine on its own, granted to someone whose role drifted over time. The dangerous combinations aren’t visible in org charts or role names or completed certification dashboards. They emerge in the quiet space between approvals.

That is the space auditors, GRC leaders, and SAP security teams should be looking at first.

References

1. Association of Certified Fraud Examiners. Occupational Fraud 2024: A Report to the Nations. 
2. SAP Authorization Object F_LFA1_APP — Vendor: Application Authorization. SAP standard documentation. 
3. United States Secret Service / U.S. Attorney’s Office, Northern District of Georgia. “Jury convicts owner of Amazon delivery business for fraud schemes and forging federal judge’s signature” (March 2026). 
4. Industry case study describing an SAP insider-breach pattern in a manufacturing organization with approximately USD 1.5M loss. 
5. KPMG audit working paper, SAP Direct Table Maintenance - Background and Testing, documenting field testing of S_DEVELOP / SE16N &SAP_EDIT capability against SAP audit-log and user-master tables.
6. SAP OSS Notes 1468636 (CO-OM tools: SE16N use of &SAP_EDIT) and 3140539 (SAL new event definition for change access in SE16N). 
7. PCAOB Auditing Standard 2401, Consideration of Fraud in a Financial Statement Audit. 
8. Cleary Enforcement Watch. “Trio of SEC Enforcement Actions Underscores Importance of Internal Controls” (September 2024) - covering National Energy Services Reunited Corp. enforcement action. 
9. CISA Alert AA19-122A: New Exploits for Unsecure SAP Systems (May 2019). 
10. Onapsis. 10KBLAZE Threat Report. 
11. Onapsis press release, May 2019, including quote from Larry Harrington (former IIA Chairman).