SAP’s Updated API Policy: A Security Perspective

In April 2026, SAP released an updated version of the SAP API Policy. The document itself is short, but its implications are broad, and the discussion it sparked has been intense it quickly became a major topic in the SAP community. Time for a security perspective.

What happened: SAP drew a sharper line around API access

The SAP API Policy document aims to standardize “the use of application programming interfaces, extensions, and related data transmission interfaces made available as part of SAP solutions (‘APIs’).” Historically, the policy did not draw much attention or spark intense discussion. So why now?

In the most recent update, SAP has made a much stricter distinction between Published APIs on the one hand and everything else on the other.

The main message of this update is that customers and third-party applications are expected to use only APIs published in SAP Business Accelerator Hub or in product documentation, unless SAP explicitly authorizes otherwise. The policy also adds stronger controls around rate limits, quotas, data ingress and egress, bulk extraction, and replication. In addition, it restricts the ungoverned use of SAP APIs by agentic or generative AI systems that can plan and execute sequences of API calls, except through SAP-endorsed architectures or pathways.

The response

Previous versions of the policy did not state such restrictions as explicitly, especially not in the context of AI agents. The update was therefore perceived as significant, and it did not take long for the SAP community to respond.

The strongest customer-side critique came from DSAG, the German-speaking SAP user group. DSAG acknowledged SAP’s legitimate interest in protecting security, performance, and stability. However, it also warned that the policy could create uncertainty for customers and partners.

The concern was not only technical. It was also contractual and operational. Customers need to know which APIs are safe to use, which existing integrations are at risk, which alternatives are available, and how much time they have to adapt. They also need clarity on whether future “fair use” models, API limits, or data access models could create additional cost or architectural dependency.

Analysts added a strategic and commercial perspective. Their concern was that SAP’s policy could increase lock-in, affect third-party AI strategies, create unforeseen costs, or force re-engineering of existing integration and data architectures. Gartner and Forrester raised these concerns, as did integration partners and data vendors as the following example shows.

Concrete example: ODP-RFC
ODP-RFC has been used by some third-party data extraction and replication tools to move SAP data into non-SAP environments such as data lakes, analytics platforms, or cloud data warehouses. At the beginning of June, SAP released SAP Security Note 3748819, which actively restricts usage of the ODP-RFC interface to “permitted SAP-internal applications” only.

SAP has now made clear that ODP-RFC is not an endorsed integration pattern for non-SAP tooling.

This is where the policy discussion becomes very real. Customers and integration partners using ODP-RFC are now faced with actual complications, such as:

• A reporting pipeline stops working
• A data lake feed must be redesigne
• A third-party connector needs replacing
• Existing integration patterns need to be reviewed or remediated

The nuance

Fueled by the uproar, SAP later added more explanation through its API Policy FAQ document. This came in a few stages, and the latest version at the time of writing is FAQ version 1.3.

In summary, SAP clarifies in the FAQ that the policy does not change contractual license grants, functional entitlements, or licenses by itself. SAP also states that existing integrations using documented APIs for documented purposes are not expected to break, and that enforcement is intended to prioritize monitoring and dialogue rather than immediate blocking.

SAP also clarified that the policy is not intended to ban third-party integration platforms, AI platforms, or data tools. Third-party solutions can still be used, provided they access SAP systems through published APIs and documented or endorsed pathways.

The FAQ clarification helped calm some of the initial reaction. But it did not remove the core issue. Instead, it shifts the discussion from:

“Is SAP banning third-party access?”

to a more precise — and more security-relevant — question:
“Which access patterns are documented, supportable, secure, monitored, and future-proof?”

That is where SAP security teams should focus.

SAP security takeaways

Let’s look at three security takeaways from the API policy update and discussion.

Takeaway 1: Know your SAP interfaces

The first requirement is visibility. Organizations need an inventory of SAP-related integrations. This should include OData services, RFCs, BAPIs, custom ABAP interfaces, middleware flows, third-party connectors, extraction jobs, data lake pipelines, and AI or automation scenarios.

For each interface, the organization should know:

• Which system or tool is involved
• Which API or interface is being used
• Whether the API is published or non-publishe
• Which integration pattern is used
• Which technical user or identity is involved
• What data is accessed
• Whether the usage is business-critical

Without this inventory, organizations are guessing. And guessing is not a security strategy. Such an inventory is a best practice in general, and it is essential for understanding the possible consequences of the updated policy in the near future.

Takeaway 2: Design integrations based on supported patterns

This may seem obvious, but the updated API policy reinforces an important design principle: SAP integrations should be built on access patterns that are documented and supported.

That does not mean every integration must automatically move to one SAP platform or one prescribed tool. It does mean that architects and security teams should challenge designs that depend on non-published APIs, unsupported replication techniques, custom wrappers around SAP-internal interfaces, or AI agents calling SAP APIs without proper governance.

This challenge should happen during the design phase, not only after go-live. This is where SAP security needs to be involved. API governance should become part of architecture review, custom-code review, authorization design, integration approval, and cloud or AI transformation planning.

Takeaway 3: Treat API consumers as privileged actors

API and interface consumers should be treated with the same discipline as powerful SAP users. Too often, APIs and interfaces are overlooked or disregarded from a security point of view. That is a misconception. A middleware platform, data replication tool, technical account, and especially an AI agent can have far more reach than individual business users.

That means they require:

• Strong authentication
• Least-privilege authorization
•  Segregation-of-duties checks
• Credential protectio
• Usage monitorin
• Anomaly detection
• Clear ownership

Integrations are a clear part of the attack surface. Do not underestimate their risk potential.

How SecurityBridge can assist

The discussion around SAP’s updated API policy should not lead to panic, but to professionalization. Many customers have existing integrations using several third-party platforms, frameworks, and technologies. SecurityBridge provides SAP-native security visibility and control across users, roles, custom code, vulnerabilities, system behavior, logs, and interfaces. In the context of SAP’s API policy, this helps organizations move from uncertainty to evidence.

SAP API governance is no longer only an integration topic. It is an SAP security topic.
Organizations that understand this early will be better prepared for clean core, cloud transformation, AI adoption, partner integration, and future SAP policy changes.

SecurityBridge helps customers build that readiness with the visibility, monitoring, and control required for a modern SAP security program.

References
• SAP API policy document: https://help.sap.com/doc/sap-api-policy/latest/en-US/API_Policy_latest.pdf
• SAP API Policy FAQ v1.3, June 2026: https://www.sap.com/docs/download/2026/04/e2a0665e-4c7f-0010-bca6-c68f7e60039b.pdf
• DSAG commentary: https://impulsant.dsag.de/formate/pressemeldung/new-sap-api-policy-dsag-sees-a-need-for-clarification/
• The Register: https://www.theregister.com/software/2026/04/29/ai-clause-in-new-sap-api-policy-provokes-lock-in-concern/5225767
• SAP note 3255746 – Unpermitted usage of ODP Data Replication APIs: https://me.sap.com/notes/3255746 (login required)