For many years, SAP Security was built around roles, profiles objects, authorizations in the RBAC model. Users were created in SAP, assigned roles, and given access to transactions and authorization objects required for their jobs. Security teams analyzed Segregation of Duties (SoD), reviewed critical access, managed privileged or emergency access, and periodically asked managers to confirm whether users still needed their assigned roles.
That model was appropriate for the SAP environments that most organizations operated a decade ago.
The problem is that the environment has changed much faster than the security model.
A modern enterprise SAP landscape may now include SAP S/4HANA, Fiori applications, SAP Business Technology Platform (BTP), SAP Build Work Zone, APIs, integrations, extensions, cloud identity services, technical users, automation and AI-driven applications. A single business process may cross several applications and systems, involve both human and non-human identities, and ultimately execute actions without a person directly performing every step.
Yet many organizations continue to ask essentially the same security questions they asked in 2015: Which roles does the user have? Which transactions are assigned? Does the user have a SoD conflict? Has the manager approved the access?
Those questions remain relevant. They are simply no longer enough.
The fundamental challenge facing SAP Security today is therefore not just modernization of technology. It is modernization of the security model used to understand access and business risk.
The SAP Security perimeter is no longer the SAP system
Traditional SAP Security was largely centered around the application itself. In an ECC-centric environment, the security boundary was relatively easy to define. Users authenticated into SAP, roles determined what they could do, transactions provided the primary entry points to business functionality, and authorization objects enforced the underlying permissions.
Modern SAP landscapes are much less contained.
A business user may authenticate through an enterprise identity provider, access SAP Build Work Zone, launch a Fiori application, invoke a service hosted on SAP BTP and ultimately consume or update data in S/4HANA. The same business process may then trigger an integration with another enterprise application through an API.
From the user’s perspective, this may appear to be one seamless business experience.
From a security perspective, it is a chain of identities, applications, authorizations, services, APIs and trust relationships.
This distinction is becoming increasingly important. The question “What access does this user have in SAP?” assumes that SAP is a single, clearly bounded environment. In a modern architecture, it is more appropriate to ask what business capabilities an identity can access across the SAP ecosystem, how those capabilities are exposed, what systems participate in their execution, and what data can ultimately be reached.
That is a much broader security problem than role administration.
The T-code is no longer the complete definition of access
Transaction codes remain important, particularly for organizations that continue to use traditional SAP GUI applications. They are also still relevant when analyzing existing roles and authorization design. The problem arises when the T-code becomes the mental model for understanding business access.
The transition to S/4HANA and Fiori illustrates why.
A business user increasingly interacts with SAP through applications rather than directly thinking about transactions. The user sees an application that supports a business activity such as approving a purchase order, maintaining a supplier or reviewing financial information. Behind that experience may be a combination of catalogs, spaces, pages, services and authorization objects.
The business capability remains the same even though the technical path to that capability may have changed.
Consequently, access governance needs to establish the relationship between the business process, application, identity, authorization, service and data. A review that only asks whether a user has a particular transaction may miss another route through which the same business capability is exposed.
This does not make transaction-based security obsolete. It means transaction analysis needs to become one layer within a broader access model rather than the definition of access itself.
BTP has expanded the SAP Security landscape
SAP Business Technology Platform represents one of the clearest examples of why the traditional SAP Security model needs to evolve. Organizations are using BTP to develop applications, build extensions, integrate systems, expose and consume APIs, and create new digital capabilities around their SAP environments.
These capabilities introduce security concepts that are not represented simply by an S/4HANA PFCG role.
Depending on the architecture, security teams may need to understand identities, role collections, entitlements, applications, services, destinations, APIs, trust configurations and integrations. Each of these components can contribute to an access path that ultimately reaches an SAP business process or data.
This creates a potential governance gap. An organization may have a mature S/4HANA role design and an extensive SoD ruleset, while having comparatively limited visibility into how BTP applications and services extend access beyond the traditional SAP authorization boundary.
The answer is not to create a separate security universe for BTP. BTP needs to become part of the organization’s overall SAP Security architecture, with appropriate governance for identity, authorization, application exposure, service access, integration and monitoring.
Build Work Zone makes the access model even more complex
SAP Build Work Zone provides another important example of the changing SAP access experience. Organizations can bring applications, business content and services together into a unified digital workplace. Users may see applications from S/4HANA, BTP and other enterprise systems through a common experience.
The user sees one unified workplace. The underlying authorization model may involve several systems.
This matters because application visibility and actual authorization are not the same thing. A user being presented with an application does not by itself determine what the user can ultimately perform. The security architecture behind that application determines which services can be invoked, which backend systems can be reached and which business data can be accessed.
For SAP Security teams, this means that the governance question has expanded from “Which roles does this user have?” to “Which business applications and capabilities are available to this identity, and what authorization path exists behind each of them?”
As organizations increasingly build extensions and applications outside the traditional ABAP stack, this broader perspective becomes essential.
SoD was designed around people. Business processes are increasingly executed by digital identities.
Segregation of Duties has traditionally been designed around human identities. A user is assigned roles, the roles provide business functions, and the ruleset determines whether combinations of those functions create a conflict.
That remains a valuable control.
But the assumption that a human user is the primary actor in every business process is becoming increasingly difficult to sustain.
Automation, APIs, workflows, bots, service accounts and AI-driven applications are increasingly participating in enterprise processes. Activities that once required several people may now be executed through a combination of human and digital identities.
This changes the nature of access risk.
Imagine a process in which an AI agent or automated workflow creates a vendor and subsequently initiates a payment-related activity. A traditional SoD analysis may evaluate the technical identity used by the automation and determine that it performs one specific function. If the conflicting capabilities are distributed across different service accounts, applications or APIs, there may be no conventional SoD conflict associated with a single human user.
Yet the business process may still contain the very concentration of control that SoD was originally designed to prevent.
A recent SAP Security discussion illustrates this emerging concern with a deliberately provocative example: an AI agent creates a vendor and pays that vendor, while a traditional ruleset sees only one service user performing one technical function.
The important point is not the specific example. It is the underlying limitation of the traditional model.
The risk cannot always be identified by examining one user ID in isolation.
It may only become visible when the complete digital execution chain is considered.
The unit of SoD analysis needs to evolve
The future of SAP access governance cannot be limited to identifying conflicting roles assigned to human users. It needs to understand relationships between human identities, non-human identities, applications, AI agents, APIs, services and business processes.
Consider a procure-to-pay process that begins in a third-party application, invokes an API on BTP, creates or updates information in S/4HANA, triggers an automated workflow and ultimately initiates a downstream financial process. Looking at each authorization individually may not reveal a traditional SoD conflict. Looking at the complete execution path may reveal that the combination of permissions allows a digital process to bypass the separation of responsibilities that the organization intended to establish.
This introduces the concept of digital access risk.
The question is no longer simply whether a person has incompatible access. It is whether a combination of identities, applications and automated capabilities can collectively perform incompatible business activities.
The same principle applies to AI agents. Once an AI agent can retrieve information, invoke applications, call APIs or initiate business actions, its permissions become part of the organization’s control environment. Security teams need to understand what the agent can access, which identity it uses, what systems it can reach, which actions it can initiate, and whether multiple individually permissible actions can be chained together to produce an unacceptable business outcome.
This does not make traditional SoD obsolete. It makes traditional SoD one component of a broader digital access governance model.
The future requires organizations to consider human identities, digital identities, AI agents and cross-system business processes as participants in the same risk ecosystem.
Cross-system risk is becoming as important as SAP-system risk
Modern business processes rarely remain inside one SAP system.
A customer onboarding process, for example, may involve a customer-facing application, identity services, BTP, S/4HANA and external systems. Procurement may involve supplier portals, integration platforms, S/4HANA, workflow and financial applications. Employee processes may cross HR platforms, identity systems and SAP applications.
Traditional access governance can struggle when the analysis stops at the boundary of one system.
An individual permission may appear harmless when evaluated independently. The risk may emerge only when that permission is combined with another capability in another system.
This is why cross-system access needs to become part of SAP Security governance. The relevant question is not simply whether each individual system has implemented appropriate controls, but whether the combined digital access path preserves the intended separation of business responsibilities.
That is a significant shift from application-centric security to business-process-centric security.
Access reviews also need to become more evidence-driven
The same evolution is required for User Access Reviews.
Traditional reviews often provide managers with lists of users and their assigned roles and ask them to approve or reject the access. While this provides a formal governance mechanism, the quality of the decision depends on the information available to the reviewer.
A manager may understand an employee’s responsibilities perfectly well but may not know what hundreds of technical authorizations actually enable. A role name alone rarely provides enough evidence to determine whether access is still appropriate.
Modern access reviews should therefore incorporate business context and actual usage wherever possible. Reviewers should be able to understand which applications and capabilities a user has, which critical activities have been performed, when access was last used, whether the user’s responsibilities have changed, and whether the access remains necessary.
This represents an important transition from access confirmation to evidence-based access governance.
Assigned access tells us what an identity can potentially do. Usage, business responsibility and contextual information help determine whether that capability is actually required.
Non-human identities can no longer remain outside the governance model
The growing use of integrations and automation also increases the importance of non-human identities. Technical users, communication users, service accounts, integration identities and application identities can have significant access to business processes and data.
Yet these identities do not fit neatly into traditional manager-based access reviews.
Who approves a service account? Who owns it? What application depends on it? What APIs can it invoke? What data can it access? When was it last used? What happens when the application it supports is retired?
These are security questions, not merely operational questions.
The risk becomes even more significant when a digital identity has broad privileges and operates continuously. A compromised human account may be detected through behavioral anomalies or a change in the user’s business activity. A compromised service identity may continue executing legitimate-looking system calls until its activity is detected through other means.
Consequently, non-human identity governance needs to become a first-class component of SAP Security.
Cloud changes the responsibility model
The move to cloud and operating models such as RISE with SAP (Private Cloud), or Grow with SAP (Public Cloud) introduces another dimension to the security conversation. Cloud does not eliminate security responsibility; many enterprises think that Security is fully owned by SAP. However, it changes how responsibility is distributed between SAP, the customer and other service providers.
Organizations therefore need to understand where responsibilities sit for identity, authentication, authorization, configuration, integrations, data protection, monitoring and incident response.
This becomes particularly important at the boundaries between services. A security control can be technically strong within one platform while the overall business process remains exposed through an integration, identity configuration or application extension elsewhere.
The statement “SAP manages it because it is in the cloud” is not a security model.
A mature organization needs a clear understanding of what it owns, what SAP owns, what other providers own, and where the controls intersect.
From periodic compliance to continuous security
Traditional SAP Security governance has often followed a periodic cycle: design roles, assign access, perform reviews and produce evidence for audit.
That cycle remains necessary, but it is increasingly insufficient.
Applications change. Users change responsibilities. Integrations are introduced. APIs are connected. BTP services are deployed. Technical identities are created. Privileged access is granted. Automated processes evolve. AI capabilities are introduced.
These changes do not wait for the next quarterly access review.
The security model therefore needs greater visibility between formal review cycles. Authorization changes, privileged activity, unexpected administrative behavior, unusual technical-user activity and other security-relevant events may need to be identified and investigated as they occur.
The objective is not to monitor everything or generate an endless stream of alerts. It is to establish meaningful visibility into the events that could materially affect business risk.
The traditional model of design, assign, review and audit is evolving toward a more continuous model of design, assign, observe, detect, respond and improve.
SAP Security and cybersecurity can no longer operate independently
The increasing complexity of SAP environments also means SAP Security can no longer operate entirely as an isolated application function.
SAP systems support critical financial, procurement, manufacturing, supply chain, HR and customer processes. A security event inside SAP can therefore have consequences far beyond the SAP team.
This makes collaboration between SAP Security, IAM, Cybersecurity, Security Operations, Internal Audit, Risk and Compliance increasingly important.
The goal is not to turn every SAP Security professional into a SOC analyst. It is to ensure that security-relevant SAP activity is understood within the broader enterprise security architecture.
A suspicious privileged action, unexpected authorization change, unusual technical-user activity or abnormal access to sensitive information may be significant to the organization’s overall security posture, even if it occurs inside an SAP application.
The boundaries between SAP Security and enterprise cybersecurity are therefore becoming less rigid.
What should SAP Security leaders do differently?
The answer is not to discard the controls organizations have spent years building.
PFCG remains important. SoD remains important. Firefighter and privileged access controls remain important. User Access Reviews remain important. Audit evidence remains important.
The change needs to be in the scope and context of those controls.
A modern SAP Security program should be capable of understanding at least six dimensions of access.
- Identity - Who or what is accessing the environment?
- Application - Which applications and business capabilities are available?
- Authorization - What is the identity technically permitted to do?
- Data - What sensitive information can ultimately be reached?
- Execution path - Which APIs, services, integrations, workflows and other identities participate in the process?
- Behavior - What is actually happening, and does it correspond with expected business activity?
This model provides a more realistic representation of today’s SAP environment than a role-only or transaction-only view.
The real problem is not outdated technology. It is an outdated mental model.
Organizations do not necessarily need to replace every SAP Security control they implemented over the last decade. They need to recognize that those controls were designed for a different architecture and extend them to address today’s reality.
S/4HANA changed the application architecture. Fiori changed the user experience. BTP expanded the platform beyond the traditional SAP application stack. Build Work Zone changed how users consume applications. APIs and integrations created new paths between systems. Cloud changed the operating model. Automation reduced the dependency on human intervention. AI is beginning to introduce digital actors capable of executing business actions.
The security model must evolve with all of them.
The biggest mistake would be to treat these developments as separate security projects. They are connected parts of the same transformation.
The identity that enters the environment, the application that exposes a capability, the API that connects systems, the service account that executes an action, the AI agent that initiates a process and the data that is ultimately accessed can all be part of one business transaction.
That is the level at which future SAP Security needs to operate.
The organizations that make this shift will not necessarily have the largest number of security tools or the longest list of SoD rules. They will be the organizations that understand how human and digital identities interact with applications, authorizations, data and automated business processes across system boundaries.
If your SAP Security strategy still looks almost exactly like it did in 2015, your technology may have moved to S/4HANA, your users may be working through Fiori and Build Work Zone, your applications may be running on BTP, and your business processes may increasingly depend on APIs, automation and AI.
But if your security model still begins and ends with “Which roles does this user have?”, then the technology has moved forward while the security model has stayed behind.
And in 2026, that is no longer simply a maturity issue. It is a business risk.
Where Does Your SAP Security Program Stand?
The SAP landscape has evolved significantly, but has your security program evolved with it? Use this quick self-assessment to understand whether your organization is still relying on a traditional, role-centric model or has moved toward modern, risk-based governance across S/4HANA, BTP, digital identities, automation and AI.
Conclusion
SAP Security is no longer confined to protecting users, roles and transactions within an SAP system. The architecture has expanded, the way users consume applications has changed, and business processes are increasingly distributed across S/4HANA, Fiori, BTP, Build Work Zone, APIs, integrations and external platforms. At the same time, automation and AI are introducing digital identities that can perform activities that were once performed exclusively by people.
This does not make the security controls organizations have relied on for years irrelevant. PFCG, SoD, privileged access management, User Access Reviews and other established controls continue to have an important role. What has changed is the context in which they must operate. A role-centric view of access is no longer sufficient when risk can emerge from the interaction between identities, applications, APIs, automated processes and multiple systems.
The next stage of SAP Security is therefore not about replacing everything that came before. It is about expanding the definition of what needs to be governed. Security teams need to understand not only who has access, but also what business capabilities can be reached, how those capabilities are executed, which human and digital identities participate, what data is exposed, and whether the complete process preserves the intended controls and separation of responsibilities.
For organizations still operating with a 2015 security mindset, this is the time to reassess. The objective should not simply be to pass the next audit or complete the next access review. It should be to build a security model that reflects the SAP environment the business actually operates today - and the increasingly automated, interconnected environment it is moving toward.
Your SAP landscape has already changed. The question is whether your SAP Security model has changed with it.
