A practitioner's guide to role design models, least privilege, and segregation of duties across the SAP landscape.
Access control failures in SAP rarely start with an attacker. They start with an authorization. A role that carries too many transaction codes, a role that has wider authorizations, a role copied from a template during implementation, or one that quietly accumulates authorizations across multiple project go-lives until it grants more access than anyone intended. By the time an auditor finds it, or a failure occurs, the damage may already have been done.
Many enterprises consider role design to be the last item on their priority list. Getting SAP live is always the priority, and role design is often pushed to a post-go-live activity. This guide highlights the importance of role design, shares best practices, identifies common mistakes, and provides practical recommendations that enterprises can adopt.
What is SAP role design?
SAP role design is the structured process of defining authorizations PFCG so that each role grants only the access required to perform the job function. A well-designed role maps to a real business task, uses a well-structured naming convention, aligns to segregation of duties, and licensing tiers that can be assigned, reviewed and revoked without manual rework.
Role design is the layer where the principle of least authorization (POLA) is built-in. It’s the building block of authorization design.
A typical role structure is as follows:
While there are many types of roles, the fundamental role is the Single Role, which contains the actual authorizations, including transactions, Fiori apps, authorization objects, and their field values.
Before explaining the different role types, it is important to understand the fundamental access control concepts:
- Role-Based Access Control (RBAC)
- Attribute-Based Access Control (ABAC)
- Rule-Based Access Control
- Policy-Based Access Control (PBAC)
Role-Based Access Control (RBAC)
In this concept, authorization is granted through pre-defined role. This is the primary model used in SAP through PFCG roles. SAP offers various role types such as:
- Single Roles
- Composite Roles
- Roles with inheritance capability – Master/Derived Roles
Additionally, Business Role(s) can be created in SAP GRC or SAP Cloud IAG which is collection of single roles (includes derived roles too) from multiple systems.
Enabler roles is also a concept which is used by some of the enterprises when they are unsure on how to manage with complex organization level combination requirements.
The fact - there is no single correct way to design SAP roles.
The choice depends on the size of the landscape, the complexity of the organizational structure, and how much governance capacity the organization can sustain. Most mature landscapes will use a blend of them, and some landscapes will choose one that fits their business requirements.
Each role type is outlined below.
Single roles
The flat and the most adopted model. Every role is individual and doesn’t either inherit or adopt the authorization. Transaction codes, Fiori apps, authorizations, restrictions are within the role.
The weakness is assignment overhead. A user with a broad job may carry twenty or thirty single roles, and user master maintenance becomes heavy. In a lean, single-country landscape this model is a pleasure to audit, and I have recommended it more than once for organizations that valued clarity over convenience. On a large multi-country programme or wider organization structure, this model becomes maintenance heavy.
Master and Derived roles
Derived roles solve a specific problem: the same job function performed across different organizational units. A purchasing clerk in one company code and a purchasing clerk in another need identical transactional access but must be restricted to their own organizational values. Without derivation, that means maintaining dozens of near-identical roles by hand, replicating every transactional change across all of them.
The master-derived model separates the two concerns - The master role owns the functional content, the menu, transactions, apps, authorization objects and restrictions. The derived roles inherit that automatically and carry only the organizational values that differ. Change a transaction in the master, regenerate the children, and the update propagates.
The design intent is that organizational values are the only thing a derived role ever adjusts. However, one point to be noted is that the model breaks the moment someone maintains authorizations directly in a child role, because the inheritance link weakens and the roles drift apart. Other challenge is that when the changes are pushed from the master role, it will overwrite the authorizations that are directly maintained in the child roles.
Composites/Business roles
A role bundle that contains many single (or) derived roles to match a job or position. In ECC or S/4HANA this is the composite role; in GRC or IAG, it is the business role grouping (contains roles and privileges from many systems.) One assignment provisions an entire job. This aligns naturally with HR position management and with identity provisioning, and it is the model most organizations reach for when they connect SAP access to an identity governance tool: a joiner in a given position receives the matching composite or business role automatically.
The risk is over-provisioning. When a job profile is defined loosely, everyone in that job inherits everything the profile grants, including access that only some post-holders genuinely need. The pattern I see repeatedly is a composite that began as a clean job model and, over successive go-lives, became the catch-all for anything the department requested, until a role named for a single clerk quietly granted half the module. Job-aligned design works when the underlying job catalog is genuinely well defined and maintained.
Task and enabler roles
The enabler model separates what a user can do from where they can do it. Functional, or task, roles hold the transactions and activity-level authorizations with organizational fields left open. Enabler roles hold only the organizational values: company codes, plants, sales organizations, or structural authorizations in HR. A user receives the task roles for their function plus the enabler role for their organizational scope.
The decoupling is combinatorial. Rather than deriving a fresh role for every function-and-organization combination, one task role plus one enabler covers the same authorization, and the total role count drops sharply. Here is an example:
The challenge is segregation of duties analysis, especially when they needs to be setup at authorization objects/values level. Without governance and tooling that understand the model, its flexibility turns into opacity, and I have seen review teams badly underestimate a user's real access because they read the task role and stopped there.
Attribute-Based Access Control (ABAC)
Attribute-Based Access Control makes the access decision at runtime, based on attributes rather than static roles. Those attributes can describe the user (department, plant, location), the resource (document type, data classification), or the context (time of day, device, network, or a transaction value threshold). A policy engine evaluates the attributes against defined rules and grants or denies authorization accordingly. The assignment is dynamic, fine-grained control that a purely static role model cannot express. For example: access that opens only during a period-end window, or that restricts automatically when a payment exceeds a threshold.
Standard SAP ABAP/NetWeaver based authorization model was not built as a policy engine, and pure ABAC has never been a natural fit for the traditional authorization object model.
In my experience, I have seen some enterprises implement ABAC using the NextLabs solution. If you are new to this concept, I strongly recommend reading their whitepaper using the link below.
The real momentum toward attribute-driven and policy-driven authorization is in the identity governance and cloud layers, where attributes and context increasingly drive both provisioning and runtime decisions.
In practice, ABAC in the SAP landscape is almost never a replacement for RBAC. It is a layer on top of it. Roles establish the baseline of what a job can do; attributes and policies refine that baseline with context. The hybrid is what I consistently recommend: keep a clean RBAC foundation so access stays explainable and auditable, then apply ABAC only where a genuine dynamic condition justifies the added complexity.
One mistake I have often seen is organizations adopting ABAC with the assumption that a fully policy-driven model will solve all their authorization challenges and simplify access management. In practice, this is rarely the case. Without careful design and governance, ABAC can introduce significant complexity and become difficult to manage.
Rule-Based Access Control (RuBAC)
Rule-Based Access Control (RuBAC) grants or restricts access based on predefined business or security rules rather than solely on a user's role. These rules evaluate specific conditions, such as the time of access, network location, device type, IP address, system status, or other contextual factors. Instead of replacing Role-Based Access Control (RBAC), Rule-Based Access Control typically works alongside it by enforcing additional security policies before access is granted.
In SAP environments, Rule-Based Access Control is commonly used to strengthen existing role-based authorizations. For example, an organization may allow users to execute sensitive transactions only during business hours, prevent logins from untrusted networks, require additional approval for privileged access outside normal working hours, or restrict emergency access (Firefighter IDs) based on predefined policies. By adding contextual controls on top of traditional SAP roles, Rule-Based Access Control helps organizations reduce risk while maintaining the flexibility of their RBAC-based authorization model.
If you are interested in implementing or learning more about Rule-Based Access Control (RuBAC) in SAP, explore ThreatSenseAI TADS Protect solution. It enables organizations to implement policy-based controls such as login restrictions based on time, day, network, Wi-Fi, device, and other contextual conditions, making it easier to strengthen SAP security without changing the underlying role design.
https://threatsenseai.com/solutions/threatsenseai-data-security/tads-protect
Policy-Based Access Control (PBAC)
Policy-Based Access Control (PBAC) makes access decisions using centrally managed security policies rather than relying solely on roles or attributes. These policies can evaluate multiple factors at the same time, including a user's role, attributes, risk score, and other contextual information. PBAC provides a flexible and dynamic authorization model that is well suited for modern enterprise and cloud environments where access decisions often depend on more than just a user's assigned role.
In SAP landscapes, PBAC is increasingly relevant as organizations adopt cloud services, Zero Trust security models, and centralized identity and access management platforms. Solutions such as SAP Cloud Identity Services, or third-party policy engines can use centrally defined policies to control access across multiple SAP and non-SAP applications. Rather than replacing RBAC, PBAC extends it by applying additional policy checks, enabling organizations to enforce consistent security controls while reducing risk across hybrid and cloud environments.
Choosing between the models
Wondering which model fits your organization? In my experience, most landscapes are hybrid: a single-role or task-and-enabler foundation, job-aligned composites or business roles for assignment, derived roles where organizational repetition is heavy, and selective ABAC for contextual based authorization (as this is not a standard feature of SAP). The deciding factors are landscape size, organizational structure, the maturity of the job catalog, and the governance capacity to keep the chosen model aligned to audit and compliance requirements such as SOX, HIPPA, ITGC etc.,
4 key principles to adopt while designing roles
Least privilege is a design decision, not a cleanup task
The most common mistake in SAP authorizations is treating least privilege as something to remediate later. Organizations provision broad access to keep the business moving, promise to tighten it after go-live, and never do. The access remains, the risk compounds, and the eventual clean-up costs far more than disciplined design would have.
Least privilege has to be engineered at the authorization object level, not just the transaction level. Granting a transaction code or a Fiori app is only the visible half of access. The authorization objects behind it, activity fields like ACTVT, organizational fields, and object-specific values, determine what a user can actually do once inside. A role that grants a transaction code with ACTVT set to a wildcard is a role that grants create, change, delete and display where the job may only require display. Precise field values are where least privilege lives or dies.
Two practices make this sustainable:
- Build reusable roles - around business tasks rather than individual users.
- Avoid full authorization values, except where a genuine business case exists and the risk has been accepted in writing. Wildcards are not inherently wrong, but each one should be a deliberate, documented choice rather than a shortcut.
A naming convention is not cosmetic
Many enterprises do not give much importance to role naming conventions. In practice, however, a well-defined naming convention makes the difference between a role catalog that governs itself and one that no one can navigate. A consistent naming standard allows approvers to understand the purpose of a role from its name alone, enables automated tools to classify and process roles, and helps auditors trace access without having to open every role to understand what it has.
A practical naming convention should capture the essential characteristics of a role, such as the role type, functional area or module, business process, access it is providing and environment or organizational scope. The exact format is less important than applying it consistently across the entire SAP landscape. The moment exceptions are allowed, the naming standard begins to lose its value, and the role catalog gradually becomes difficult to manage.
Here is an example of a well-defined role naming convention:
Derived roles benefit the most from a strong naming convention because the relationship between a master role and its derived roles should be immediately obvious. When a single master role for Accounts Payable is used to generate multiple derived roles for different company codes or plants, the naming should clearly identify both the business function and the organizational scope. Otherwise, the maintenance effort that the derived role model was designed to reduce simply reappears in another form, making administration, troubleshooting, and audits more difficult.
Segregation of duties belongs in the design phase
Segregation of duties is usually treated as a detection problem: run a ruleset, find the conflicts, remediate. That is necessary but backwards. The cheapest SoD conflict to fix is the one that was never designed into a role in the first place.
SoD-aware role design means checking a role against the organization's ruleset before it is built, not after it is assigned. When two conflicting business activities, creating a vendor and paying a vendor, for example, are packaged into the same single role, no amount of assignment discipline can separate them. The conflict is baked into the design. Splitting functions into distinct single roles at design time keeps the composite layer flexible: an organization can decide who gets which combination, and mitigating controls apply only where combinations are genuinely required.
The practical rule is to design single roles narrowly enough that conflicts are visible at assignment, then let composite roles or user assignment carry the combination decisions. This keeps the audit story clean. A reviewer can see exactly which role introduced a conflict and why the combination was approved, rather than untangling a monolithic role that quietly holds both sides of a control.
Role ownership and lifecycle governance
A role without an owner is a role that only grows. Every SAP role should have a named business owner accountable for what it grants and a defined review cadence. Ownership is what makes periodic access recertification meaningful, because someone with functional context can attest that the role still reflects a real job and still grants the right access.
Governance extends across the full lifecycle. Role creation should follow a change process with documented justification. Role decommissioning matters as much as creation, because retired job functions leave behind roles that are available in the catalog and can reattach to users through bulk assignments. A role model that is never pruned becomes an attack surface of its own.
Common role design mistakes
These are the patterns that surface in nearly every SAP access review, ordered by the risk they carry.
| Mistake | Severity | Description |
|---|---|---|
| Wide/Open Authorization Values | High | Roles built with wildcard field values, especially on activity and organizational fields, granting significantly more access than the job function requires. These are the findings that frequently become audit exceptions. |
| Conflicting Functions in a Single Role | High | Both sides of a Segregation of Duties (SoD) conflict packaged into one role. This is referred to as an Intra-role conflict and is often one of the most difficult risks to remediate. |
| Direct Authorization Maintenance in Derived Roles | High | Changing authorizations directly in derived roles instead of the master role, breaking inheritance and defeating the purpose of the role design. |
| No Naming Convention (or an Abandoned One) | Medium | A role catalog that no one can easily navigate, where the purpose of a role can only be understood by opening and analyzing it. |
| Copy-and-Modify Role Sprawl | Medium | Creating new roles by copying existing ones and making small changes, resulting in near-duplicate roles that dramatically increase maintenance effort. |
| Roles Without Owners | Medium | Roles that have no clearly assigned business or technical owner, leaving access unreviewed and accountability undefined over time. |
Role design in the S/4HANA landscape
S/4HANA reshapes role design around the Fiori experience without discarding the underlying authorization model. Access is now delivered through business roles that group Fiori catalogs, spaces and pages, while the classic PFCG role and authorization object layer still governs what the backend permits. Both layers have to be designed together. A business role that surfaces a Fiori app the user cannot execute in the backend produces a broken experience, and a backend authorization with no corresponding frontend entry point is invisible access waiting to be misused.
The core principles carry over unchanged. Least privilege still lives at the authorization object level. Segregation of duties still has to be designed in, and the SoD ruleset has to account for both classic transactions and Fiori apps that reach the same underlying functions. The migration from ECC to S/4HANA is, in practice, one of the best opportunities an organization gets to rebuild a role model on clean design principles rather than carrying decades of accumulated authorization debt into the new landscape.
Additional References:
- Role design strategy for SAP S/4 HANA Public Cloud - Best practices
- SAP Role Design for Success: Best Practices and Tips
- SMART - a holistic approach to Role design
- Best practices and recommendations for developing roles in SAP HANA
- Using Authorization Variants in PFCG
Closing Perspective
Role design is where SAP security is decided long before any access review runs. The organizations that struggle with access control are rarely short of tools; they are short of a role model that was designed with intent. Least privilege engineered at the authorization object level, segregation of duties built in rather than remediated, a naming convention applied without exception, a deliberate choice of role model, and clear ownership across the lifecycle: these are not advanced techniques. They are the fundamentals, and they are fundamental precisely because so much depends on getting them right the first time.
The migration to S/4HANA gives most organizations a rare chance to start that discipline from a clean slate. The ones who take it will spend the next decade governing their access. The ones who carry their old role model forward will spend it explaining their findings.
