RAP changes how SAP apps expose business logic and services

At a glance

What this is: This is an analysis of SAP RAP and its implications for how business logic is modelled, exposed, and governed across cloud-ready SAP applications.

Why it matters: It matters because application design choices now shape service exposure, transactional authority, and extension boundaries that IAM, PAM, and application security teams need to govern.

Context

RAP, the ABAP RESTful Application Programming Model, is SAP’s modern approach for building cloud-ready transactional applications and exposing business objects through OData services. In practice, it moves key decisions about data modelling, behaviour, and service exposure into the application architecture itself, which means access scope is no longer just an authorization problem.

That matters for identity governance because the same business object can be exposed as a UI service, a Web API, or an extension point depending on service definitions and bindings. When developers control exposure at the model layer, IAM teams have to understand where lifecycle, privilege, and consumption boundaries are created, not only where they are enforced.

RAP is therefore as much a governance pattern as a development model. Its mix of extensibility, service binding, and managed or unmanaged behaviour changes how organisations should think about who can act on business data and how much of the underlying logic is reachable.

Key questions

Q: How should teams govern access in RAP-based SAP applications?

A: Teams should govern RAP access at the service definition and binding layer, not only in the underlying business object. The right approach is to expose the minimum CDS entities and operations required, then review projections, extensions, and consumer bindings whenever the business process changes.

Q: Why does RAP change IAM and application security planning?

A: RAP changes planning because service exposure is created by development artefacts such as CDS models, behavior definitions, and service bindings. IAM teams need to understand those artefacts to know what can be reached, what can change data, and where the control boundary actually sits.

Q: What risks increase when RAP uses unmanaged behavior?

A: Unmanaged behavior increases the risk that critical transactional logic is dispersed across custom code with fewer framework controls. That makes authorisation, persistence handling, and lifecycle consistency more dependent on implementation quality and review discipline.

Q: How do business object boundaries affect SAP service governance?

A: Business object boundaries determine how data, behaviour, and relationships are grouped before exposure. If those boundaries are broad or inconsistent, downstream services inherit unnecessary reach, and governance becomes harder because ownership and control are no longer mapped cleanly to the model.

Technical breakdown

RAP service definitions control what becomes reachable

In RAP, a business service is not just an endpoint. It is the layer that selects which CDS projection views and behaviours are exposed, and the service binding determines whether consumers reach the service through OData v2, OData v4, UI metadata, or a Web API. That means exposure is shaped before a request ever hits runtime authorization. The key architectural point is that developers decide the service surface by selecting entities and operations, so the reachable attack or misuse surface is bounded by the model, not only by the transport layer.

Practical implication: review RAP service definitions as part of access governance, because the exposed surface is created at design time.

Behavior definitions separate allowed actions from implementation

RAP separates behavior definition from behavior implementation. The definition states what can happen, such as create, update, or delete, while ABAP classes implement the actual business logic. This is important because governance can be expressed declaratively at the behavior layer, but the effective control still depends on whether the implementation preserves transaction integrity, authorisation checks, and data consistency. Managed RAP supplies framework support for standard transactional processing, while unmanaged RAP shifts more responsibility to custom code, especially where existing business logic must be reused.

Practical implication: treat unmanaged RAP flows as higher governance risk because more transactional authority sits in custom implementation.

CDS-based data modelling determines business object boundaries

RAP uses Core Data Services to define entities, associations, projections, and annotations, and those definitions become the structural basis for a business object. A business object is the controlled unit of data, behaviour, and lifecycle in the model. Because CDS also drives UI metadata and analytics, the same model can feed Fiori elements, APIs, and downstream consumption. That makes CDS more than a data layer. It becomes a policy boundary that influences what data is grouped together, which relationships are visible, and how much of the underlying business process is exposed to consumers.

Practical implication: map CDS entities to business ownership and authorization boundaries before exposing them through services.

Breaches seen in the wild

• SAP Kubernetes secrets exposure 2023: Kubernetes secrets committed to GitHub exposed 203 valid registry credentials, including SAP artifact repository access. SAP closed it after Aqua's report.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

RAP turns application design into an access-governance decision. The important shift is not simply that SAP modernised its programming model. It is that service scope, behavioural authority, and lifecycle exposure are now encoded in the development artefacts that define the application. That means identity and access teams can no longer treat runtime authorization as the only control plane. Practitioners should treat RAP architecture as part of the governance model, not just the build model.

Business object boundaries are now the real security boundary. In RAP, the business object aggregates data, behaviour, and relationships into a single controlled unit. If that boundary is too broad, downstream services inherit more authority than they need. If it is too narrow, teams fragment governance across too many service surfaces. The useful design question is not whether the code is modern, but whether the object model creates enforceable ownership and least-privilege consumption paths.

Extension freedom can widen governance drift if it is not tied to service scope. RAP is built for in-app and side-by-side extensibility, which is operationally useful but also creates more places where logic and exposure can diverge. The risk is not extension itself. The risk is extending business capability while leaving service bindings, authorization assumptions, and transactional ownership implicit. IAM and application security teams should treat extension design as part of access lifecycle control.

Cloud-ready SAP development is increasingly a service governance problem. RAP’s value lies in making applications easier to expose through standard interfaces and easier to evolve across SAP BTP and S/4HANA. That same flexibility means the organisation must know which services are read-only, which can mutate business state, and which are intended for internal UI versus external consumption. The governance gap appears when exposure is driven by development convenience rather than a clear control model.

RAP standardises technical delivery, but not governance discipline. The model gives developers consistent ways to build transactional apps, yet it still depends on the organisation to classify business services, review behaviour implementations, and define ownership for extension points. That makes RAP a governance accelerator only when architecture, IAM, and application teams share the same boundary language. Practitioners should align service design with access governance early, or the platform will simply reproduce old control gaps in a modern form.

From our research library:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.

What this signals

Service scope is now a design-time governance decision. RAP makes it harder for IAM teams to separate application design from access control because the service definition decides what is reachable before a consumer ever connects. That means review processes need to move upstream into build and release governance, not sit only in production access reviews.

Model-driven exposure changes how least privilege should be interpreted in SAP environments. If the business object is the real control unit, then least privilege must be assessed against exposed CDS projections and service bindings, not only against backend tables or transport roles. Organisations that miss this will overestimate how much control the runtime layer actually provides.

Developer behaviour still matters because exposure is only as tight as the model behind it. Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec. The broader lesson is that modern service modelling increases the value of secure development habits, because weak discipline upstream quickly becomes broad exposure downstream.

For practitioners

• Map business object boundaries Inventory which RAP business objects carry sensitive or high-impact transactions, then align those objects to explicit ownership and access boundaries before exposing them as services.
• Review service definitions before binding Check which CDS projections and behaviours a service definition exposes, because that choice determines the effective service surface for UI and API consumers.
• Differentiate managed and unmanaged flows Treat unmanaged RAP implementations as requiring deeper control review because transactional logic, CRUD handling, and persistence are implemented manually.
• Classify extension points by governance impact Separate harmless UI adaptation from extensions that change transactional behaviour, because those changes alter the reach of the business service and its lifecycle controls.

Key takeaways

• RAP shifts SAP governance from code-centric review to model-centric control because the service surface is defined by CDS, behavior, and binding decisions.
• The important security question is not only whether the application is modern, but whether its business object boundaries and extension points are narrow enough to enforce ownership.
• IAM and application security teams need to review exposure earlier in the SAP delivery lifecycle, or service convenience will outrun governance.

Key terms

• Business Object: A business object is the governed unit of data, behavior, and relationships in RAP. It groups the business meaning of an entity with the actions that can be taken on it, which makes it the practical boundary for transactional control and service exposure.
• Service Binding: Service binding is the step that connects a RAP service definition to a concrete consumption protocol such as OData v2 or OData v4. It determines how the exposed business service is made available to UI clients or external systems, and therefore shapes the operational reach of the service.
• Behavior definition: Behavior definition specifies which operations are allowed on a RAP business object, such as create, update, delete, and custom actions. It separates intent from implementation, which makes the application easier to govern, review, and test across cloud and hybrid SAP environments.
• CDS Projection: A CDS projection is a filtered or tailored view of underlying CDS data that controls what is exposed to consumers. In RAP, it helps separate the internal data model from the externally consumable service surface, which is central to governance and least-privilege design.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.