SAP BTP Security Review

Many companies now run part of their SAP landscape on SAP Business Technology Platform: Fiori launchpads, custom UI5 and CAP applications, workflows, integrations to S/4HANA and to third-party cloud services. These applications are often built by integrators under time pressure, and the configuration keeps growing after go-live.

Classic SAP security reviews focus on the S/4HANA back end: roles, profiles, segregation of duties. They rarely cover BTP. Cloud security posture tools usually cannot connect to it either. The result is a subaccount that few people fully understand, with little documentation and no clear picture of who can do what, or what calls what.

The BTP security review answers two questions:

How does a user authenticate, and which identity actually reaches each system behind the application?
What does the application really call, and with which credentials?

The answers are based on evidence collected from the platform and from real application traffic, not only on what the configuration says.

What we review

Identity and authentication

Trust configuration: which identity providers are enabled for application logon, and whether a non-federated path (such as the default SAP ID service) remains available next to the corporate identity provider
Federation chain from BTP through SAP Cloud Identity Services (IAS, IPS) to the corporate identity provider and its conditional access rules
Users who exist more than once, under different identity providers, with different rights
Shadow user creation and how business users are actually provisioned

Authorizations on the platform

Role collections, the roles they contain and how they are assigned: through groups or directly to users
Holders of administrative collections (Subaccount Administrator, Destination Administrator, Cloud Connector Administrator and similar), including external accounts, shared mailboxes and accounts that have not logged on for a long time
Workflow and process automation roles: whether participants in an approval process can also change the workflow or its data
A user and role matrix across every identity provider

Destinations and outbound calls

Every destination: target, authentication type, and whether the named user or a technical user reaches the target
Stored passwords and personal credentials kept in destinations
Calls to external cloud services outside the corporate identity and change management
Weak settings such as disabled TLS validation, dynamic destinations exposed to the launchpad, and leftover or orphaned destinations
A cross-check between configured destinations and observed traffic: a destination that is never called, and a call with no matching destination, are both findings

Cloud Connector exposure

Back-end systems and resources exposed to the subaccount, and over which protocols
Exposures that do not match the purpose of the subaccount, for example a production system reachable from a development subaccount
Availability setup and hygiene

Application data exposure

Inspection of the data the application receives compared with what the screen displays
Detection of the pattern where full datasets are loaded into the browser and filtered on the client side, so that a user receives data they are not authorized to see
Link between this pattern and the identity used towards the back end

Platform and operations

Cloud Foundry spaces, service instances and application units
HANA Cloud: database users, privileges of the runtime users, IP allowlist, audit policies
Audit logging: whether BTP audit logs are retrieved and forwarded to a SIEM
Transport and deployment path to production, and who can influence it

Development practice

Where the source code lives, whether it is under central version control, and whether static code analysis and secret scanning run on it
Hardcoded credentials in the code

Endpoint exposure

Inventory of published routes and service endpoints
Unauthenticated reachability check from inside and outside the corporate network
Review of the settings that govern exposure

This is an exposure and configuration review. It sends no attack traffic. Penetration testing and vulnerability scanning on SAP BTP and RISE require SAP's prior written approval under its rules of engagement. If a scan is needed, we help you request it from SAP and support it within the approved window.

How we work

Read-only. We do not change configuration, run "check connection" on destinations or act in business applications.
Evidence first. Browser traffic captures, platform exports and command-line extractions are cross-checked against each other. Configuration alone is not taken as proof of how the system behaves.
Starts without privileged access. The identity chain and the application calls can be analyzed from a browser and a normal user account. Platform access is added as it becomes available.
Development first, production confirmed. Observations made on a development subaccount are stated as design observations and confirmed on production before being reported as findings.
Secrets stay out of the report. Captures are sanitized and stored passwords or client secrets are never reproduced.

What you receive

An identity model of the application, hop by hop, showing which identity reaches each target system
A map of external and system-to-system calls, with protocol, authentication and identity for each
A destination register with a clean-up list
A user and role matrix covering every identity provider
A Cloud Connector exposure overview
An endpoint exposure table
A list of observations with risk rating and remediation steps, written for both the application team and the security team

Typical observations

Patterns found in BTP subaccounts, stated generally:

The default SAP identity provider is still enabled for application logon next to the corporate identity provider, which offers a path around federation, MFA and conditional access
The back end is reached with a technical user and a stored password, so back-end authorizations apply to the technical user and not to the person using the application
Applications load complete datasets into the browser and filter them there
Administrative role collections are assigned directly to many users, often external and often dormant
Personal credentials of current or former consultants remain stored in destinations
Outbound integrations rely on accounts outside the corporate identity
A legacy workflow engine and its administrator roles remain after migration to a newer service
No retrieval of BTP audit logs

Who it is for

Companies running custom applications or workflows on SAP BTP that need a clear picture of how they work
Security teams with no visibility into BTP, before or alongside a continuous monitoring tool
Companies that moved S/4HANA to RISE and want to check that the BTP side follows the intended architecture

The review complements our SAP S/4HANA security and GRC services, which cover the back-end authorization model. For background on the controls involved, see our SAP BTP security guide.