SAP and Zero Trust: Applying Zero Trust Principles to ERP Security

Why SAP Needs Zero Trust Architecture

Traditional SAP security relies on network segmentation, firewalls, and perimeter-based controls. The assumption is that if a user is on the corporate network or connected through a VPN, they are who they say they are. This approach has proven inadequate for several reasons that directly affect enterprise SAP deployments.

First, SAP systems are highly interconnected. An SAP ERP instance communicates with CRM, SRM, S/4HANA Cloud, BTP environments, third-party applications, and legacy systems through RFC interfaces, IDocs, and web services. Each of these communication channels represents a potential attack surface. Attackers who compromise a single trusted system — such as a connected HR application — can pivot into the SAP environment using valid but stolen RFC credentials. Second, insider threats, whether malicious or accidental, bypass perimeter controls entirely. A disgruntled Basis administrator with SAP_ALL access or a finance user with excessive authorization for sensitive transactions like F-02 (parking invoices) can cause significant damage without triggering traditional network alerts.

The zero trust model directly addresses these weaknesses by enforcing explicit verification at every access point, not just at the network edge. For SAP, this means implementing continuous monitoring for segregation of duties violations, detecting anomalous ABAP program executions, and auditing every authorization change in real time. The top 10 SIEM tools on the market can ingest SAP audit logs, but they lack the SAP-specific parsing and contextual understanding needed for true zero trust enforcement — a gap that purpose-built solutions must fill.

Core Pillars of Zero Trust for SAP

Zero trust architecture rests on several foundational principles. When applied to SAP environments, each pillar requires specific implementation considerations that diverge significantly from general IT zero trust models.

Verify Every Access Request

In an SAP zero trust model, authentication is not a one-time event at login. Every transaction code execution, every RFC call, every BAPI invocation, and every data export must be validated against the user's current context — including their role, device posture, location, time of day, and historical behavior patterns. This is fundamentally different from the default SAP behavior, where once a user logs in with a valid password and system access, they can execute any transaction assigned to their roles for the duration of the session.

To implement continuous verification, organizations need real-time transaction monitoring that can detect when a user attempts to execute a sensitive transaction outside their normal pattern. For example, if a procurement user attempts to execute F-02 (post financial documents) for the first time, or a service account typically used for batch processing suddenly triggers a BAPI that reads employee bank details, the system should either block the action or raise an immediate alert requiring secondary approval. CyberSilo SAP Guardian provides this capability by correlating user identity, authorization context, and historical behavioral baselines for each transaction execution.

Enforce Least-Privilege Access Continuously

Least privilege in an SAP environment is not a one-time role design exercise. It requires ongoing monitoring and re-validation because user roles, organizational structures, and business processes change constantly. An employee who transfers from accounts payable to procurement should not retain F-53 (vendor payment) authorization. A contractor whose project ends should not have their SAP access linger for months. A critical SAP security baseline requirement is periodic user access review (UAR), but manual reviews are slow, error-prone, and often miss gradual accumulation of excessive privileges.

A zero trust approach to SAP least privilege requires automated segregation of duties (SoD) monitoring for every transaction execution, not just during periodic reviews. It also requires detection of authorization creep — the gradual expansion of a user's effective privileges over time due to role modifications, composite role additions, or derived authorization inheritance. SAP GRC tools handle some of this, but they typically focus on preventative controls during role design, rather than continuous runtime monitoring. A zero trust SAP monitoring solution fills this gap by detecting when a user's actual runtime behavior exceeds the boundaries of their intended role, even if the underlying authorization technically allows it.

Assume Breach and Microsegment SAP Systems

Zero trust assumes that the attacker is already inside the network. For SAP, this means organizations must design their system architecture to limit lateral movement even if a user account or a connected application is compromised. In practice, this translates to microsegmenting SAP systems at multiple layers.

First, network-level segmentation isolates the SAP application layer from the database layer. The SAP application server should never directly communicate with the database using a privileged account like SAPSR3 with full table access — an attacker who compromises the application server should not automatically be able to query HANA tables. Second, within the SAP ecosystem, RFC trust relationships must be strictly controlled and monitored. An RFC connection from a dev environment to production should be read-only by default, with any use of the RFC that attempts to write data or trigger transactions flagged as anomalous. Third, in hybrid SAP landscapes spanning on-premise S/4HANA and SAP BTP, every cloud-to-on-premise API call must be verified independently, with no implicit trust granted to cloud services.

CyberSilo SAP Guardian supports this microsegmentation model by monitoring RFC destinations, detecting unauthorized RFC calls, and flagging trust relationships that violate defined zero trust policies. When an RFC connection that should be read-only suddenly executes a transactional write, the solution can trigger an automated or manual response before data exfiltration occurs.

Implementing Zero Trust in SAP ERP

Implementing zero trust in an existing SAP ERP or S/4HANA environment is a phased process. It is not a single configuration change or a tool deployment — it requires a systematic alignment of people, processes, and technology around the zero trust principles.

Phase One: Audit and Inventory

Before any controls can be enforced, organizations need complete visibility into their SAP landscape. This means building an inventory of all SAP systems (production, dev, test, sandbox), all user accounts (including service accounts, RFC users, and background processing users), all RFC destinations and trust relationships, all authorizations and composite roles, and all critical transactions and ABAP programs that handle sensitive data.

Many organizations underestimate the number of service accounts in their SAP environment. A typical global enterprise running SAP ECC 6.0 or S/4HANA will have hundreds of system accounts for batch processing, interface communication, and background jobs — many of which have SAP_ALL or SAP_NEW authorizations left over from system migrations. These accounts are prime targets for attackers because they have elevated privileges, are rarely monitored, and often have hardcoded passwords that never expire. A zero trust audit must identify every such account and prioritize it for immediate least-privilege re-certification.

The audit phase also involves mapping data flows. Understanding which SAP tables hold sensitive data (for example, USR02 for password hashes, PA0006 for personal employee data, BKPF for financial postings) and which transactions access them is essential for defining monitoring rules. Without this base map, organizations cannot implement appropriate data-centric security controls.

Phase Two: Define Policies and Baselines

With the inventory complete, the next step is defining zero trust policies specific to the SAP environment. These policies translate zero trust principles into concrete rules that the monitoring system can enforce. Example policies include:

• No user account (including service accounts) should have SAP_ALL or SAP_NEW authorization in production. Any use of these authorizations must be treated as a security incident requiring immediate investigation.
• All RFC connections between systems must have a defined purpose and a responsible owner. Any RFC call that does not match the documented purpose must be flagged as anomalous.
• Access to sensitive tables (VBRK for billing documents, KNB1 for customer master data, LIKP for delivery data) must be restricted to users with specific roles. Any direct table read by a user outside these roles must generate an alert.
• Background job execution must be limited to service accounts that have explicitly assigned authorizations. Privileged user accounts should not run background jobs in production.
• Transaction code execution for critical financial transactions (FB01, FB50, F-28, F.13) must require multi-factor approval, enforced through transactional monitoring.

Baseline creation is equally important. Before detecting anomalies, the monitoring system must learn what "normal" looks like for each user, each transaction, and each system interface. CyberSilo SAP Guardian builds behavioral baselines over a defined learning period (typically 30 to 90 days) by ingesting SAP security audit logs (SM19/SM20), authorization trace data (SUIM), and system change logs (SCU3, CDHDR). These baselines become the reference for detecting deviations that indicate potential zero trust violations.

Phase Three: Deploy Continuous Monitoring

With policies defined and baselines established, the organization deploys continuous monitoring across the SAP landscape. This monitoring must cover several specific domains:

• Authorization monitoring: Real-time detection of authorization changes, role modifications, user creation, and privilege escalation. Any change to an authorization object (especially S_TCODE for transaction access, S_TABU_DIS for table access, and S_ADMI_FCD for administrative functions) should trigger an immediate review.
• Transaction monitoring: Continuous validation of each transaction execution against the user's role, historical pattern, and device context. The monitoring system should know, for example, that a user belonging to the AP_ACCOUNTANT role should execute FB60 and F-43, but not F-53 (vendor payment) or FB50 (GL posting).
• ABAP program monitoring: Detection of unauthorized or modified ABAP programs, especially custom Z-programs that access sensitive data. Zero trust requires that any new or modified ABAP program must pass a security review before it can execute in production — the monitoring system enforces this by flagging execution of unapproved or unregistered programs.
• RFC and interface monitoring: Validation of all inter-system communication against defined trust policies. RFC calls that originate from unexpected systems, use unexpected function modules, or access unexpected tables should be blocked or alerted.
• User behavior analytics: Application of machine learning-based analytics to detect anomalous user behavior that indicates credential compromise, insider threat, or policy violation. This includes identifying users who suddenly access transactions they have never used before, users who connect from unusual network locations, or accounts that exhibit batch-like behavior during business hours.

CyberSilo SAP Guardian provides coverage across all five domains by integrating with SAP's security audit log, the ABAP application server, and the HANA database. The solution correlates events across these layers to build a comprehensive picture of each access request and authorization decision.

Zero Trust for SAP Cloud and Hybrid Environments

With the adoption of SAP S/4HANA Cloud and SAP Business Technology Platform (BTP), the zero trust challenge becomes more complex. Cloud environments erase the physical network perimeter entirely, and the shared responsibility model between SAP and the customer creates new trust boundaries that must be continuously validated.

SAP BTP Zero Trust Considerations

SAP BTP introduces several specific zero trust requirements that differ from traditional SAP on-premise deployments. BTP applications communicate via APIs, use OAuth 2.0 and SAML 2.0 for authentication, and interact with on-premise SAP systems through cloud connectors. Each of these elements requires careful trust verification.

For BTP, zero trust means that every API call to an on-premise SAP system must be explicitly authorized, not implicitly trusted because it comes from a legitimate BTP subaccount. This requires an API gateway that validates tokens, checks IP allowlists, and enforces granular access policies at the function module level. Additionally, the cloud connector itself must be treated as a privileged gateway that is monitored for unauthorized use. Any configuration change to the cloud connector — such as adding a new on-premise system or modifying backend access rules — should trigger a security alert.

Organizations running SAP S/4HANA Cloud must also consider that they do not have direct access to the underlying ABAP application server for monitoring. Instead, they rely on SAP's built-in audit logging capabilities (the SAP Audit Log service in BTP) and API-based security monitoring. This makes the choice of monitoring solution even more critical — it must be able to ingest cloud-native security logs alongside traditional SAP audit data to maintain a unified zero trust posture.

The SIEM tool cost guide provides useful benchmarks for organizations comparing the total cost of monitoring SAP cloud environments versus traditional on-premise deployments, but the cost of not implementing zero trust — data breaches, compliance violations, and audit failures — far exceeds any tool investment.

Maintaining Consistent Zero Trust Across Hybrid Landscapes

Most large enterprises run a hybrid SAP landscape — some systems on-premise, some in SAP's cloud (S/4HANA Cloud, SuccessFactors, Ariba), and some in hyperscaler clouds (AWS, Azure, GCP). Maintaining consistent zero trust policies across this heterogeneous environment is one of the most difficult SAP security challenges.

The key is to establish a unified policy definition layer that applies equally to all systems, regardless of where they are hosted. For example, the policy that "no user should execute both procurement and payment transactions" (a classic SoD conflict) must apply to a finance user in on-premise ECC the same as to a user in S/4HANA Cloud Public Edition or a BTP application that accesses financial data through APIs. The monitoring solution must be able to correlate user identities across systems (using PFCG role assignments, Identity Provisioning, or SAP Cloud Identity) and detect cross-system SoD violations that a single-system view would miss.

CyberSilo SAP Guardian supports hybrid deployments by ingesting security logs from on-premise SAP systems via RFC-based extraction, from S/4HANA Cloud via the Audit Log service API, and from BTP via REST API integrations. The solution normalizes these events into a common schema and applies the same zero trust policy engine across all sources, ensuring consistent enforcement regardless of where the SAP system runs.

Measuring Zero Trust Maturity in SAP

Organizations implementing zero trust for SAP need a way to measure their progress and identify gaps. The following maturity framework, aligned with the Zero Trust Maturity Model from CISA and adapted for SAP-specific controls, provides a structured assessment approach.

This maturity framework provides a practical roadmap for SAP security teams. Each domain should be assessed annually, with clear targets for advancing from Basic to Advanced levels. The most common bottleneck organizations face is moving from "In Progress" to "Advanced" for the Identity domain, as MFA for SAP GUI requires integration with corporate identity providers and policy enforcement across diverse user groups including power users, developers, and external auditors.

Common Challenges in SAP Zero Trust Adoption

Implementing zero trust in SAP environments presents unique challenges that organizations must anticipate and address.

Legacy system constraints: Many organizations run SAP ECC 6.0 on older database versions (Oracle, DB2) that have limited native security audit logging capabilities. Enabling full audit logging in these systems can introduce performance overhead, especially in high-volume transactional environments. The monitoring solution must be architected to collect data without impacting system performance, typically through asynchronous log extraction or dedicated secondary connections.

Cultural resistance: SAP Basis teams and SAP power users accustomed to full system access often resist the restrictions that zero trust imposes. Developers who need SAP_ALL authorizations for transport management or system debugging may see continuous monitoring as an obstacle to productivity. Overcoming this cultural resistance requires executive sponsorship, clear security policies, and a phased implementation that demonstrates the business value of reducing security incidents without crippling daily operations.

Complex authorization landscape: The SAP authorization model is inherently complex, with derived authorizations, composite roles, organizational-level values, and authorization checks that span multiple objects. Applying zero trust principles — especially least-privilege enforcement — in this environment requires a deep understanding of how SAP's authorization system works. Monitoring solutions must be able to evaluate the effective authorization of a user at runtime, not just the roles they are assigned.

Third-party integrations: SAP systems connect to hundreds of third-party applications, from expense reporting tools to banking interfaces to warehouse management systems. Each of these integrations introduces a potential trust boundary that must be monitored. Organizations must ensure that zero trust policies extend to these third-party connections, even when the external system is outside their direct control.

CyberSilo SAP Guardian addresses these challenges by providing a deployment architecture that scales from simple log collection to full zero trust enforcement, with configurable monitoring depth that allows organizations to start with high-risk areas and expand coverage over time. The solution's built-in authorization analysis maps user roles to effective transaction access, reducing the complexity of defining granular zero trust policies and monitoring them at runtime.