Cost, Segregation of Duties, and Need: the three checks that belong before access is assigned
The most expensive decision in an SAP access request is usually the one nobody realizes has been made.
Most SAP access discussions focus on approvals. Far fewer focus on what is actually being approved.
A user requests access to a transaction code or Fiori application to perform a specific task. The request is raised, reviewed, approved, and provisioned through established workflow processes. From a governance perspective, everything appears to work exactly as designed.
The user receives the requested access. Along with access they never asked for.
Figure 1.0 – The Process vs Outcome
In my experience, this is not the exception. It is the default outcome in most SAP landscapes.
The transaction requested by the user rarely exists in isolation. It is typically delivered through a role that contains additional authorizations, business activities, and sometimes additional risk.
The outcome is familiar to most SAP security and GRC teams. Users accumulate access that was never explicitly requested, never individually justified, and rarely revisited.
Over time, these inherited authorizations become a source of licensing inefficiency, Segregation of Duties conflicts, audit observations, and excessive entitlement.
What to Look for in the Right SAP Security Services Partner
That gap, between the one transaction a user needs and the ten that ride along with it, is where licensing money leaks, Segregation of Duties conflicts breed, and audit findings are written.
It almost never shows up on the request. It surfaces a year later, in a license true-up, a remediation cycle, or an observation that reads “access is not aligned with job responsibilities.” By then nobody remembers why the access was granted.
This is the most common pattern I see across SAP landscapes, and the most expensive one no one budgets for. The fix is not a better approval workflow. It is three checks that run before the role is ever assigned: what it costs, what it conflicts with, and what it is actually for.
In role redesign projects, license optimization exercises, and SAP Access Control remediation programs, I rarely encounter an SAP landscape where this pattern does not exist in some form. The only difference is the scale.
Figure 2: Three checks before assignment
How one becomes ten
Over-provisioning is rarely a decision. It is a side effect of how roles are built.
The transaction the user needs does not live alone. It lives inside a role designed around a job function, not a task. To obtain the one transaction, the user inherits the entire footprint of that job.
Reference users make it worse. “Copy the access from someone on the team who already does this.” The new joiner inherits everything the reference user accumulated over five years, including access that person should have lost three roles ago.
Composite and derived roles compound it further. A composite bundles single roles for convenience. The requestor wanted one capability inside one single role. They received the composite, and with it everything else the composite contained.
Then there is the path of least resistance. Building a tight, task-scoped role takes design effort. Granting an existing broad role takes one click. Provisioning optimizes for speed, and breadth is faster than precision.
None of this is malicious. All of it is normal. And all of it produces the same outcome. A user entitled to far more than the task in front of them requires.
The Three Checks in Practice
The point of intervention is the request, not the review. Before a role is assigned, three questions should be answered, in order. What does it cost. What does it conflict with. What is it actually for.
Cost check: the licensing implication
This is the check most security teams never run, because licensing is treated as a procurement problem rather than a provisioning one.
In SAP’s named-user licensing model, a user is measured by what they are authorized to do (by assignment), not by what they actually do (by execution). The classification follows the entitlement.That single fact is why an SAP access decision can become a finance problem.
A broad role can move a user up a classification tier. One high-value authorization provisioned among the ten unused transactions can reclassify a user from a lower tier to a heavier one, and subscription models such as RISE express that weight as Full User Equivalents (FUE). Multiply the shift across a few thousand users and the distance between what is licensed and what is used becomes a number that surfaces at the annual measurement.
SAP measures that consumption through its own tooling, USMM and the License Administration Workbench, at audit time. Organizations tend to discover their position after the cost is committed, not before.
In my experience, the discussion usually starts during a license review. The discovery that triggers the conversation often happened years earlier during a perfectly routine access request.
Consider a plant with 200 users who each need one self-service capability. Display a report. Enter their own time. Nothing beyond that.
Classified correctly as Self-Service Use, those users consume very little. SAP’s RISE metric converts roughly thirty self-service users into one Full User Equivalent, so 200 users sit at close to seven FUE.
Source: SAP RISE Full User Equivalent metric (illustrative conversion).
Now provision them the way most landscapes actually do. Each user receives the standard plant job role, a composite that happens to contain maintenance and posting transactions none of them will run. That single inclusion reclassifies all 200 from Self-Service Use to Core Use, and the conversion changes from thirty per FUE to five per FUE.
Seven FUE becomes forty.
Figure 3: FUE consumption explained
The same 200 people, doing the same work, now consume more than five times the entitlement. None of the added weight buys any added activity. It is paid for, measured at the annual true-up, and never used.
Put a representative rate against it and the gap stops being abstract. At an illustrative three thousand per FUE per year, the thirty-three unnecessary FUE in this one plant cost close to one hundred thousand per year. Recurring. Actual pricing is always contract-specific and negotiated, but the shape of the number does not change. The same pattern repeated across every plant and cost center becomes the largest line item nobody decided to spend.
The cost check asks one thing at the point of request. Does this assignment change how the user is classified, and is that change justified by the task.
SoD check: the conflict that rode along
The user asked to create a purchase order. The role they received also carried approve purchase order and maintain vendor master.
The user did not request a conflict. The bundle introduced one.
I have yet to meet a business manager who deliberately requested a Segregation of Duties violation. Most SoD issues originate from role design decisions that were made long before the access request was raised.
This is the part that is easy to miss. SoD risk is almost never created by the access a person asks for. It is created by the access that arrives uninvited alongside it. Create and approve. Vendor and pay. Maintain and post. Each extra transaction expands the combinatorial surface where two innocent capabilities become one toxic combination.
Trace it through one role. A procurement analyst needs ME53N, display purchase requisition. Read only. The intent is to look, not to touch.
The role that carries ME53N is a procurement operations composite. Along with that display transaction, it grants the ability to create and change purchase requisitions and purchase orders (ME51N, ME21N, ME22N), release purchase orders (ME29N), maintain the vendor master (XK01, XK02), post incoming invoices (MIRO), and run payments (F110).
One read-only request. Roughly a dozen capabilities delivered.
Now read the combinations the way a ruleset does. Create a purchase order and release it, and the user can raise and approve their own spend. Maintain the vendor master and run payments, and the user can set up a vendor and pay it. Create the order, post the invoice, and the same person owns the transaction from requisition to settlement.
The analyst asked to view a requisition. The role handed them create-and-approve, vendor-and-pay, and order-to-invoice. Three high-risk conflicts, none requested, all now real.
Source: standard Procure-to-Pay segregation of duties risks.
Multiply that across a team. Twenty analysts provisioned from the same composite means the same three conflicts replicated twenty times, each one a separate line in the next access review, each one requiring a mitigating control, a control owner, and quarterly evidence. The SoD backlog that consumes the GRC team did not come from twenty deliberate risk decisions. It came from one role assigned twenty times.
Most organizations run their SoD ruleset as a detective control. The conflict is found in the next access review, flagged, routed for remediation, mitigated with a control nobody monitors. The same ruleset, run as a simulation before assignment, would have stopped the conflict from ever existing.
Source: ISACA segregation of duties guidance; SOX Section 404 IT general controls
Detection after the fact is rework. Simulation before the fact is control.
Need check: the nine with no justification
Here is a simple exercise I often suggest to SAP security teams. In workshops, this exercise rarely lasts more than a few minutes before someone says, “That access was always there.” That answer is usually the problem.
Pick a user. Open their access. Then ask someone to explain why every transaction exists. Not the role. The transaction. The exercise becomes uncomfortable surprisingly quickly.
The need check is the principle of least privilege applied at the level of the individual authorization, not the role.
Source: NIST SP 800-53, AC-6 Least Privilege.
It asks the question that role-based provisioning quietly skips. Does each capability in this assignment map to a documented requirement for this specific user. Not for the role. Not for the team. For this person, doing this job.
When the answer is no for ten of eleven transactions, the role is wrong for the request. The honest response is to scope a smaller role, not to approve the oversized one because it happens to contain what was asked for.
What the unused ten actually cost
The extra access does not sit quietly. It compounds. Unused access rarely stays harmless forever. It stays harmless until someone changes roles, an auditor asks questions, or an attacker finds the account first.
It becomes dormant authorization. Ten transactions that are never executed still appear in every entitlement report, every access extract, every audit pull. Usage data shows they were never run, often visible in transaction usage in ST03N. Entitlement shows they were always granted. That gap is exactly what an auditor circles.
More than once, I have seen organizations spend weeks explaining access during an audit only to conclude that nobody could identify the original business requirement that justified it.
As a field marker, it is common to open an access review and find that a third or more of users hold at least one high-value transaction they have never executed. The exact share moves with the landscape. The direction does not.
It degrades the control meant to catch it. The periodic user access review exists to confirm that access matches need. When every user carries three times the access they use, reviewers face a wall of entitlements and approve in bulk. Over-provisioning makes the review too noisy to do its job. The control that should detect access creep becomes the first casualty of access creep.
And it widens the blast radius. Every authorization a user holds is a capability an attacker inherits if that account is compromised. Ten unused transactions stay unused right up until the account is phished. Then they are ten live capabilities.
Compliant and controlled are not the same state. A role can pass the ruleset, clear the workflow, and satisfy the auditor’s sample, and still leave the organization holding access it cannot explain, paying for licenses it does not consume, and carrying conflicts it never reviewed.
Running the three checks in practice
Each check maps to tooling that already exists in most SAP landscapes. The work is not buying a new capability. It is moving an existing one to the point of request.
The cost check lives in user classification. USMM and the License Administration Workbench measure consumption after the fact. The same logic, applied before assignment, asks whether the role about to be granted carries an authorization that lifts the user into a heavier type. Read the entitlement alongside actual usage from ST03N and the unused weight becomes visible before it is licensed, not after.
The SoD check lives in risk analysis. SAP Access Control runs the ruleset every day as a detective scan. Run that same risk analysis as a simulation on the proposed assignment, inside the request, and the conflict is shown to the approver before it exists. The control does not change. Its timing does.
The need check lives in the authorization defaults and the usage record. SU24 defines what a transaction proposes to pull in. SUIM shows what a user already holds. ST03N shows what they actually run. Read together, they answer whether each authorization in the request maps to something this user does, or only to something the role assumes.
Same tools, earlier. That is the whole move.
Where this gets hard
There is an honest objection to all of this, and experienced teams raise it immediately. Task-scoped roles multiply. Replace a handful of broad job roles with many precise ones and the catalog grows, derived roles proliferate, and the maintenance load climbs. Over-provisioning is traded for role explosion.
The answer is not to abandon precision. It is to right-size from evidence rather than from guesswork. Role mining built on actual usage, drawn from ST03N and the role usage record, shows which authorizations in a role are ever exercised and which are dead weight. Roles are cut to what is used, derived roles are kept disciplined against a clean master, and new roles are designed task-first instead of cloned from the nearest person.
Precision without usage data creates sprawl. Precision built on usage data removes it.
Precision Requires More Than Better Roles
Role redesign is necessary, but it does not solve the underlying challenge of context.
Many organizations still rely on static role assignments that are designed around job functions rather than the specific context in which access is needed. As business processes become more dynamic, the gap between what a user needs and what a role delivers becomes harder to manage.
This is one reason why Attribute-Based Access Control (ABAC) continues to attract attention. Instead of granting access solely through predefined roles, ABAC evaluates attributes such as business unit, geography, cost center, project assignment, employment status, or other contextual factors before authorizing access.
The objective is not to replace role-based access control overnight. It is to introduce greater precision into access decisions. In environments where the same role serves hundreds or thousands of users, attribute-driven controls can help reduce the entitlement expansion that often accompanies traditional role assignments.
For many SAP organizations, the future is unlikely to be RBAC or ABAC. It is more likely to be a combination of both, where roles establish baseline access and contextual attributes refine it.
The Problem Does Not End With Human Users
Everything above describes a human request. The same bundling reaches identities that never raise a ticket. Technical and communication users, RFC connections, and the service and agent identities multiplying across the autonomous enterprise are provisioned the same way: a broad role, granted once, rarely revisited. A technical user holding a posting authorization it has never called is the bundled ten with no person attached to it.
The migration to S/4HANA is the moment this becomes cheap to fix. Roles are rebuilt, classifications are reset, and the landscape is already in motion. Carrying the bundled ten across the migration locks the cost and the conflict into the new system. Applying the three checks during the rebuild leaves them behind.
This is one of the reasons I believe the conversation becomes more important in the Autonomous Enterprise. Humans occasionally challenge whether access is still needed. Service accounts, technical users, and AI agents rarely do.
Shift the three checks left
Over the years, I have become less interested in who approved access and more interested in how the role was designed in the first place. Most access problems are created long before the approval workflow begins. The pattern is fixable, and the fix is structural rather than procedural.
Move the three checks to where access is designed and requested, not where it is reviewed. A cost check, an SoD simulation, and a need test belong in the request screen, not in next quarter’s certification.
Right-size the roles. Task-scoped roles cost more to build and far less to own. A role that grants what the task needs and nothing more makes all three checks pass by construction.
Make usage visible at the point of decision. An approver who can see that a requested role contains ten transactions the team never executes will scope it differently. Evidence at the moment of decision changes the decision.
Make it measurable. Three numbers tell leadership whether the checks are working: the ratio of entitlement to actual usage across the user base, the count of Segregation of Duties conflicts introduced per provisioning cycle, and the rate of authorizations granted and never run. When those move in the right direction, the program is working. When they hold flat, the checks are theater.
The goal is not to slow provisioning. It is to make the fast path the precise one.
The organizations that manage access most effectively are not the ones with the strictest approval workflows. They are the ones that minimize the gap between what is requested and what is granted.
Closing Perspective
Every over-provisioned user in an SAP landscape began as a reasonable request for a single transaction. The breadth was never decided. It accumulated.
The three checks do not add bureaucracy. They relocate it. The work of explaining ten unjustified transactions happens either now, in a five-minute scoping decision, or later, across a license true-up, an SoD remediation cycle, and an audit response. The total effort is far higher when it is deferred, and by then the access is entrenched.
One transaction code was requested. Eleven were granted. The discipline that closes that gap is not stricter approval. It is the willingness to ask, before assignment, what the other ten are actually for.
In most cases, the issue was never negligence. It was simply the accumulation of small decisions that nobody revisited.
