SAP ERP overview
For organizations that employ SAP ERP (Enterprise Resource Planning), it’s often one of the most critical systems they run on. It collects and fulfills customer orders, requests and tracks payments, and delivers financial data to executives and investors. In short, it’s the backbone of business. If SAP ERP goes down or is compromised, business can stop.
Despite its importance, some SAP ERP environments still need to better align with Zero Trust security standards frequently employed by modern cloud and SaaS solutions. This is often due to SAP’s flexibility, which means no two implementations are identical and changes often require significant, specialized effort.
As an identity architect with in-depth experience in SAP security from several different vantage points, I can offer a perspective on how SAP ERP deployments can be modernized to take advantage of the latest security benefits.
Common problems/challenges
Before we dive into what a future state looks like, let’s talk about some of the common areas that present the greatest opportunities for improvement.
Nomenclature and terminology
When working with a vendor as large as SAP, getting the right terminology and nomenclature straight can be a challenge. I struggled to find an appropriate title for this blog because I wanted to make sure I was referring to the right SAP technology.
SAP offers a wide variety of products, and some of the newer offerings follow different models from what I’ll cover here. In this post, when I refer to SAP ERP, I am referring to the suite of products that SAP has built and expanded since 1972. You can usually identify this suite with a few keywords: ABAP, S4/HANA, ECC, Basis, or Netweaver.
Legacy authentication
Despite SAP’s advancements in web UI technology, it’s still common for organizations to access SAP through the traditional Windows client known as SAPGUI. While Zero Trust authentication is possible for SAPGUI (more on that later), it’s challenging to deploy and configure. As a result, many organizations continue relying on passwords for authentication.
With passwords come all the familiar challenges: a suboptimal user experience, the need for password synchronization tools, and low-assurance authentication methods.
But the biggest concern isn’t user experience; it’s the potential security risk. In SAPGUI, network encryption is closely associated with authentication. In many deployments, this means usernames and passwords travel across the internal network in clear text. If password synchronization tools are used, this can also expose Active Directory passwords. Finally, if Entra ID Hybrid mode is enabled, the same risk could extend to Entra credentials.
Using a VPN or enabling Windows Authentication can help reduce some of this risk, but they aren't complete solutions. A true Zero-Trust strategy assumes the network is compromised and enforces strong authentication at every layer without relying solely on network-based protections.
Incomplete RBAC projects and configuration drift
The SAP authorization model is highly detailed and complex. Early in my admin career, I had to study SAP’s ADM940 course on security and authorizations. It wasn’t a light read, but it taught me how SAP security functions.
SAP security is often thought of in terms of Transaction Codes (tcodes), each associated with a business task. However, behind every user action, dozens or even hundreds of disparate authorizations are checked. These authorization checks can be different depending on user conditions or the SAP version being deployed (more on that later).
Complexity is one thing, but scale is another. Now that we’ve established the complexity of roles within SAP, let’s talk about scale. Many Role-Based Access Control (RBAC) projects face hurdles when trying to cover 100% of access with dedicated job roles. This unrealistic goal may lead to a near 1:1 relationship between the number of users and roles. While this problem is not specific to SAP deployments, it manifests itself in a number of ways, which can complicate an SAP landscape.
SAP provides tools for managing roles that are helpful when used consistently. But in many environments, consistency is rare. What works in one SAP system often doesn’t work the same way elsewhere.
As a result, many organizations rely on low-assurance methods of assigning access:
- Copying from an existing user: SAP even has this “model as” feature built in.
- Access is assigned based on transaction codes (T-Codes) T-codes are a simplistic method of determining the access level of a given role.
Both approaches bring challenges. Modelling users based on existing personnel risks propagating inappropriate access that may have accumulated over time. T-codes give only a partial view of what a user can do. Furthermore, there’s a common misconception that T-codes can be assigned directly — they can't. Finally, newer SAP modules aren't based on T-codes, so this method is gradually becoming obsolete.
We’ve been down this road before
It should be no surprise that various iterations of solutions to this problem have been employed in the past (and are still in use today). Here’s one example of how identity management and identity governance products have been used to provide partial solutions:
Component summary
Note: I’m purposefully using generic terms for these components- very often identity products will serve one or more of these functions.
Enterprise Directory Service
This component is responsible for runtime access control services. For situations where local SAP authentication occurs, this would be where the user’s password would be synchronized. For situations where SSO is configured in SAP, legacy Kerberos authentication services would be provided by this service.
Enterprise Provisioning Service
This component is responsible for performing role-based access control and provisioning of access throughout the environment. This service helps ensure the proper user accounts are set up in the proper systems, and that the proper access is set up on those accounts (including the directory service).
SAP GRC Module
This module serves many purposes, including taking over automated SAP provisioning from the global provisioning service, performing segregation of duty scanning, and obtaining the proper access approvals for any SAP access that is requested.
While this design can help meet compliance requirements, it comes with some challenges that may limit the success of the deployment.
- Approvals for SAP access are completely different from those for other enterprise applications. This means different auditing systems, different workflow engines for administrators, and different approval processes for approvers. It can also mean a confusing user experience – one that will be challenging for the user to understand if approvers are not approving tasks quickly.
- The enterprise provisioning service has limited visibility into the access that exists in each SAP system. While SAP GRC has reliable mechanisms for synchronizing data between itself and individual SAP systems, the fact that the enterprise-wide system does not have direct access to the system of record can make it difficult to identify and track down synchronization errors when they do occur.
- This design doesn’t generally allow collaboration between the runtime access controlled by the directory service and the at-rest access managed by the provisioning service. For example:
- What if we need to grant temporary access for just an hour?
- What if we want authentication to change based on the level of access a user has?
- What if we need stronger authentication for SAP power users compared to users with limited access?
In this model, two separate platforms control two different types of access. As a result, Zero Trust use cases like these can typically only be patched together through complex, fragile orchestration — not supported natively.
There’s a Better Way!
At Okta, our vision is to enable any organization to safely use any technology. This means that SAP, as a critical component to any organization that employs it, must be managed in a standardized way that lends itself to an enterprise-wide Zero Trust strategy.
Component summary
Okta Platform
Here, Okta provides enterprise-wide identity management, identity governance, and privileged access services. It helps ensure that identities are properly synchronized and managed according to policy. It provides a single access request/approval experience, a single access certification experience, and finally, a single, context-aware authentication platform for the organization.
SAP GRC
For larger, compliance focused SAP deployments, SAP GRC plays a critical role. It provides the fine grained segregation of duty scanning capabilities required to help with compliance requirements. Embedded with this capability is the domain expertise that SAP is best suited to provide. What constitutes inappropriate access? What access collides with which other access? Those questions are deeply rooted in the SAP product’s domain, and are best answered by SAP itself. I would argue that this ruleset is one of the most valuable components of the SAP GRC product.
While GRC plays an important role in this architecture, it functions more as an API and administrative tool — not something that end users or approvers typically interact with.
This diagram illustrates at a high level the roles and responsibilities of Okta and GRC in this recommended deployment pattern.
At the surface, this strategy has some clear end-user and administrative benefits:
- One system responsible for all identity synchronization tasks enterprise-wide.
- One approval process, request process, and audit process enterprise-wide.
- Critical SAP security controls are maintained.
- Core auditing platforms receive the latest information directly from SAP systems, with no chance for intermediary failure.
At a high level, this is about using the right tool for the right job. But today, we operate in a world where Identity is Security and Okta gives you an identity security fabric that turns identity tools into security tools.
You may have heard the term “converged identity platform.” It’s one recognized by industry leaders and analysts. When put into practice, the concept can benefit the security of not only your SAP deployment but also your entire enterprise.
Previously, I mentioned two types of access: “at rest” and “runtime”.
- “At rest” access refers to the users, accounts, entitlements, and roles that are set up throughout your enterprise. In SAP, this means your user master records and their role assignments. I refer to this access as “at rest” because it is relatively stable, and does not consider any runtime context when SAP authorization checks are evaluating it.
- “Runtime” access is what happens when a user actually tries to do something. What device are they on? What is the posture of that device? What network are they coming from? Is there anything abnormal about their behavior? How did they authenticate, and how recently?
For a true defense in depth, Zero Trust strategy, both types of access must work together. It’s not enough for a user to have access — they should only use that access under the right conditions.
By bringing all of this together in a single platform, like Okta, you can apply these layers of security in a scalable way. The result is a modern, Zero Trust approach that helps ensure your SAP environment is protected with the same rigor as your other critical infrastructure.
Summary
If you’re still with me — thank you for spending some of your time here. My goal with this post was to bring clarity to three main ideas:
- A quick overview of the identity modernization opportunities available to SAP customers today.
- An analysis of why traditional and siloed approaches can limit the enablement of a true next-level security model.
- A modern design approach that uses SAP’s strengths, including its security features — while connecting SAP into the broader enterprise security programs many organizations are building today.
If you want to learn more about what a converged identity platform looks like in practice, check out our latest webinar here.
These materials and any recommendations within are not legal, privacy, security, compliance, or business advice. These materials are intended for general informational purposes only and may not reflect the most current security, privacy, and legal developments nor all relevant issues. You are responsible for obtaining legal, security, privacy, compliance, or business advice from your own lawyer or other professional advisor and should not rely on the recommendations herein. Okta is not liable to you for any loss or damages that may result from your implementation of any recommendations in these materials. Okta makes no representations, warranties, or other assurances regarding the content of these materials. Information regarding Okta's contractual assurances to its customers can be found at okta.com/agreements.
This blog does not necessarily represent Okta's position, strategies or opinion.
