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

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.

Why This Matters for Security Teams

RAP-based SAP applications shift access control away from monolithic transaction security and into service definitions, projections, and bindings, which means teams can no longer rely on a single backend object to tell the full story. If a consumer can reach a CDS projection or an exposed operation that was never intended for that process, the business object may still be “secure” while the application is not. That is why access governance must follow the published service surface, not just the data model.

This is the same pattern NHI Mgmt Group warns about in broader identity programmes: privilege often accumulates at the edges where integrations, automation, and service exposure are least reviewed. In its Ultimate Guide to NHIs, NHI Mgmt Group notes that 97% of NHIs carry excessive privileges, a useful reminder that overexposure is usually a design problem, not only an operational one. For SAP teams, the practical lesson is to minimise what is published, verify who can invoke it, and re-check the binding whenever the process changes. In practice, many security teams encounter access drift only after a new consumer or extension has already widened the reachable attack surface.

How It Works in Practice

Governance for RAP access starts with the principle of least exposure. Teams should treat the service definition as the policy boundary: only the CDS entities, operations, and actions needed by the business process should be published. The next control point is the binding, because that is where the exposed model becomes reachable to a real consumer. A secure design reviews both layers together, then validates whether the consumer actually needs read, create, update, delete, or custom action access.

In SAP practice, this means checking:

• which CDS projections are exposed versus only available internally
• whether unmanaged or managed behaviors introduce unintended write paths
• which service bindings are active in each environment
• how extensions change field visibility, action scope, or authorization checks
• which business roles map to the service consumer, not just to the underlying table or object

The security review should also include transport and lifecycle controls. A RAP service that was safe at launch can become over-permissive after a feature extension, a new OData consumer, or a role redesign. That is why current guidance suggests revalidating both the service surface and the consumer binding whenever a business process changes. This aligns with broader control guidance in the NIST Cybersecurity Framework 2.0, which emphasises ongoing governance rather than one-time approval.

For identity and secrets hygiene, the same discipline applies to service users, technical users, and automation credentials. NHI Mgmt Group’s research links access sprawl to downstream risk, especially when credentials outlive the process they support. The Top 10 NHI Issues page is relevant here because RAP consumers often behave like NHIs in practice: they are non-human, persistent, and easy to over-authorise if no one reviews the actual call path. These controls tend to break down when multiple RAP extensions and cross-system integrations share the same service account because ownership and effective privilege become opaque.

Common Variations and Edge Cases

Tighter RAP governance often increases delivery overhead, requiring organisations to balance release speed against the cost of more frequent service and binding reviews. That tradeoff is real, especially in landscapes with many extensions, partner integrations, or rapidly changing Fiori apps. Best practice is evolving, but there is no universal standard that says every RAP service must be governed the same way regardless of exposure, consumer type, or data sensitivity.

One common edge case is when a team assumes authorization in the underlying business object is sufficient. It is not, if the projection exposes fields or actions that were never intended for the consuming app. Another is when a technical service user is reused across multiple bindings, which makes incident containment and offboarding harder. A third is when custom checks are added in one layer but not re-implemented after an extension introduces a new operation path.

For regulated environments, a practical approach is to document the intended consumer, the minimal exposed CDS model, and the exact business role mapping for each service binding, then review those artifacts during change management. That makes the access decision auditable and helps prevent silent privilege growth. When RAP services are reused across development, test, and production with different bindings, governance weakens because the same object can carry different effective permissions in each environment.

Related resources from NHI Mgmt Group

• How should IAM teams govern access across SAP and business applications?
• How should security teams govern SAP Fiori Launchpad access in role-based environments?
• How should security teams govern SaaS applications that access Microsoft 365 on behalf of users?
• How should security teams govern non-human access across applications and data?