Why Most SAP Access Models Are Built on the Wrong Assumption
In most SAP environments, access governance naturally revolves around roles, but understanding SAP authorization objects vs roles is critical to knowing what truly controls access. Audits are conducted at the role level. Controls are designed around roles. Periodic access reviews focus on roles. Even GRC workflows are built using roles as the foundation.
But here’s something that often gets overlooked.
In SAP, roles are not what actually control access. They are simply containers that help administrators organize and manage authorizations efficiently.
When a user executes a transaction or launches a Fiori app, SAP does not check which roles the user has. It goes deeper. It evaluates the authorization objects assigned to the user and, more importantly, the specific field-level restrictions maintained within those objects.
This gap between how access is governed and how access is enforced is one of the most overlooked structural weaknesses in SAP security today.
Most SAP environments are governed at the role level, but controlled at the authorization level. That is where risk lives.
It is also one of the primary reasons why organizations struggle with recurring audit findings, inaccurate SoD risk reporting, and overuse of emergency access.
Understanding the Control Layer SAP Actually Uses
From an implementation standpoint, roles are a convenience layer. They help bundle access for provisioning. They make administration scalable. They are necessary.
But they are not the control layer.
When a user executes a transaction such as FB01 or a Fiori app, SAP performs a runtime check against authorization objects and their field values. Each authorization object represents a specific control dimension. These dimensions include company code, plant, activity type, document type, and more.
For instance, a user may have posting access with ACTVT = 01, but restricted to BUKRS = 2000.
From a role perspective, the user appears to have posting access. From a control perspective, that access is limited to a specific company code.
If you want to understand how this runtime evaluation really works, including how SAP determines which authorization objects are checked during execution, read the article: How SU24 Check Proposals help establish runtime checks:
For example, when posting a financial document, SAP checks whether the user has the required activity value for a specific company code within an authorization object. If the field values do not match, access is denied regardless of the role assigned.
This behavior is not conceptual. It is how SAP is built. During execution, the system performs authorization checks against authorization objects and their field values stored in the user master record. SAP explicitly documents that the AUTHORITY-CHECK evaluates whether the required object and field values exist for the user before allowing execution.
https://help.sap.com/doc/abapdocu_752_index_htm/7.52/en-US/abapauthority-check.htm
This is not a theoretical distinction. It is how the system behaves in every execution.
Where Governance Breaks Down in Practice
Over the last two decades of SAP security transformations, one pattern appears consistently. Organizations design roles as if they are the control mechanism. They are not.
This creates a structural disconnect.
A role may contain multiple authorization objects with broad field values. Another role may contain restricted values. From a reporting standpoint, both roles look similar. From an enforcement standpoint, they behave very differently.
This is where audit and reality begin to diverge.
In several client environments, we have seen users flagged with high-risk SoD conflicts based on transaction combinations. A deeper analysis at the authorization object level showed that field restrictions prevented the actual execution of those conflicting activities. The risk existed on paper but not in execution.
In large SAP environments, a significant portion of SoD conflicts fall into this category, where risks are identified at the transaction level but are not executable due to field-level restrictions.
The reverse is more dangerous.
Users may appear compliant from a role design perspective, but permissive field values within authorization objects allow unintended access. These scenarios rarely get detected in traditional SoD analysis.
This is also acknowledged in industry research. SAPinsider highlights that many organizations rely heavily on transaction-level SoD without incorporating authorization-level context, leading to both false positives and blind spots.
https://sapinsider.org/prevent-false-conflicts-with-supplemental-rules-in-sap-access-control/
Why SoD Analysis Alone Does Not Reflect True Risk
Most GRC implementations analyze risk using transaction codes/Fiori Apps or function-level mappings. Many of the GRC implementations use default global ruleset which has the risks defined at the transaction code/Fiori app level. As a result, risk analysis is often limited to transaction code or Fiori app level.
This approach was practical when systems were simpler. It is no longer sufficient with complex designs and interconnected systems.
Ignoring field-level risk definitions results in inflated risk reports that business teams stop trusting which is termed as “false positives”. At the same time, it creates gaps where real risks are not identified because the analysis does not go deep enough.
The Role Design Problem That Follows
When roles are treated as control units, they tend to grow. Access gets added to avoid delays. Business pressures override design discipline. Over time, roles become broad, overlapping, and difficult to rationalize.
To compensate, organizations rely more on firefighter access.
This is not a coincidence.
It is a direct outcome of designing roles without grounding them in authorization object logic. When field-level controls are not well defined, roles either become too restrictive or too permissive. Both scenarios lead to operational inefficiencies.
In one large manufacturing environment, more than 35 percent of production changes were executed using emergency access. The root cause was not user behavior. It was poorly structured authorization values within roles.
Read our expert recommendation on – How SAP FFIDs are becoming a routine rather than emergency:
https://sapsecurityexpert.com/expert-recommendations/sap-ffid-usage-risks-emergency-access-routine
What Auditors Are Beginning to Expect
Audit expectations are also evolving.
Earlier, demonstrating that a user was assigned an approved role was often sufficient. Today, that is not enough in mature environments.
Auditors are increasingly asking a deeper question.
What actually prevents unauthorized access?
Answering that requires visibility into authorization objects and their field values. It requires demonstrating that controls are not just assigned but enforced.
Guidance aligned with frameworks such as COSO and ISO 27001 Annex A.9 emphasizes effective access control, not just documented access structures.
Without authorization-level clarity, that evidence remains weak.
What Needs to Change in SAP Security Strategy
Access design should begin with identifying critical authorization objects and defining appropriate field values. Roles should then be built as structured aggregations of these controlled authorizations.
SoD analysis needs to evolve to incorporate context. Static transaction conflicts must be supplemented with authorization-aware evaluation, especially for high-risk functions.
Monitoring must move beyond what users have to what users actually do. Usage-based insights help validate whether assigned access is being exercised within expected boundaries.
SAP itself provides capabilities that support this direction. Tools such as Security Optimization Service and Read Access Logging can enhance visibility when implemented correctly.
The Bottom Line
Roles make access manageable. They are necessary for governance and administration. Authorization objects make access enforceable. They are the actual control layer.
Confusing the two creates a system where governance appears strong, but enforcement remains uncertain.
That is the gap most enterprises are operating in today.