The question usually reaches us sideways. An S/4HANA program goes live, the auditors arrive, and somewhere in the scope there is a BTP global account that nobody in the security team has looked at. It was set up by the integration team or the implementation partner, the people who created it are global account administrators, the Cloud Connector was installed in a hurry during the build phase, and destinations hold the password of a technical user with broad rights in the back end.

None of that shows up in an SAP security review that stops at PFCG. BTP has its own accounts, its own authorization model, its own identity provider and its own logs, so it has to be designed and reviewed as a separate layer.

Why BTP needs its own security design

BTP sits between your users, the internet and your SAP back end. A Build Work Zone launchpad can expose S/4HANA apps to external users, an Integration Suite tenant moves data between SAP and third parties, and a CAP application can read and write in the ERP through the Cloud Connector. Each of these is a path into the core system.

The S/4HANA authorization concept still applies at the end of the path, but only if the identity that reaches the back end is the real user. When BTP calls the back end with a shared technical user, the S/4HANA roles of the actual user no longer matter, and BTP becomes the only place where access is controlled.

The account model

A BTP global account contains directories and subaccounts. The subaccount is where services, applications, trust and authorizations live, and it is the real security boundary.

  • Separate environments: development, test and production in different subaccounts, with different administrators and, ideally, different identity provider configurations. A shared subaccount for "all non-production" quickly becomes a place where production data ends up.
  • Few global account administrators: global account administrators can create subaccounts, move entitlements and grant themselves anything. Keep this to a small number of named people, and do not leave the implementation partner's consultants in the role after go-live.
  • Inventory subaccounts: trial, proof-of-concept and project subaccounts are often forgotten with services and trust still active. Review them like dormant users.
  • Platform roles versus business roles: administering the subaccount (platform) and using the applications in it (business) are different access. Keep them in different role collections and assign them to different groups.

Authorizations: role collections

Applications on BTP declare role templates, built from scopes and attributes. Roles are created from those templates, and role collections group the roles. The role collection is what you assign.

The good practices are familiar from SAP role design, applied to a new model:

  • Map role collections to identity provider groups through the trust configuration, instead of assigning them to users one by one. Access then follows the joiner-mover-leaver process of your directory, and leavers lose BTP access when they lose their corporate account.
  • Design role collections around job functions, not around applications, and document them as you would a composite role.
  • Use attributes to restrict data where the application supports it (company code, sales organization, plant), rather than giving everyone the full scope.
  • Include BTP in segregation of duties analysis. If a BTP application can create a vendor and another path in S/4HANA can pay it, the conflict exists even though the two accesses live in different systems.
  • Recertify BTP role collections in the same access review campaigns as the ERP.

Identity: SAP Cloud Identity Services

By default, a subaccount trusts the SAP ID service, which authenticates users with SAP-managed accounts. For business users this is the wrong choice: the accounts are not controlled by your directory, and leavers keep them.

The standard design is to use an SAP Cloud Identity Services tenant:

  • Identity Authentication (IAS) as the identity provider of the subaccount, acting as a proxy to the corporate identity provider (Microsoft Entra ID or another SAML / OpenID Connect provider). Users log on with their corporate account, with single sign-on and the MFA policy you already enforce.
  • Conditional authentication and MFA for administrators and for access from outside the corporate network.
  • Identity Provisioning (IPS) to provision users and groups from the source directory to BTP and other SAP cloud applications, so that group membership, and therefore role collections, stays in sync.
  • SAP ID service restricted to a small number of named administrators as break-glass access, or removed from user logon entirely.

Connectivity: Cloud Connector and destinations

The Cloud Connector links a BTP subaccount to on-premise systems. The tunnel is opened outbound from your network, so nothing is published on the internet, but the Cloud Connector itself becomes a control point: whatever it exposes, every application in the connected subaccount can reach.

  • Expose the minimum: map virtual hosts to specific back-end systems, restrict HTTP resources to the URL paths the applications need, and for RFC, allow only the function modules that are actually called. Exposing / on an ABAP system or allowing all function modules with a prefix wildcard undoes most of the benefit.
  • Prefer principal propagation: the user's identity is passed to the back end through a short-lived X.509 certificate, so the S/4HANA authorizations of the real user apply. Shared technical users should be the exception and should have narrow roles.
  • Harden the host and the administration: dedicated host, initial administrator password changed, administration connected to your directory, current Cloud Connector version, audit logging enabled and forwarded.
  • Treat the Cloud Connector as part of the ITGC scope: changes to its access control lists are configuration changes and should go through change management.

Destinations hold the target URL and the authentication method for each connection. When they use basic authentication or client credentials, they hold secrets.

  • Restrict who can create or change destinations: someone who can change a destination can redirect traffic or reuse stored credentials.
  • Prefer OAuth flows with user propagation over stored passwords.
  • Treat service keys and service bindings in the Cloud Foundry environment as long-lived credentials: inventory them, limit who can create them, and rotate them.

Monitoring and audit logs

BTP records security events (logons, authorization changes, configuration changes) in the audit log service. The retention is limited (90 days by default in the Cloud Foundry environment), which is shorter than most audit periods.

  • Retrieve the audit logs regularly through the Audit Log Retrieval API and send them to your SIEM or log archive.
  • Monitor administrator activity: new global account or subaccount administrators, trust configuration changes, new role collection assignments, new destinations.
  • Keep evidence for the auditor: who holds administrator roles, how role collections are assigned, how leavers are removed, and how changes to the Cloud Connector are approved.

SAP publishes a list of security recommendations for SAP BTP that is a useful baseline for a first review. It does not replace a design that fits your landscape, but it gives a structured checklist.

Where BTP security sits in an S/4HANA program

Most of the issues above are created during the build phase, when the priority is to make integrations work. They are cheap to avoid at that point and expensive to correct after go-live, once applications depend on a broad technical user or on an open Cloud Connector path.

If your program includes RISE with SAP, Integration Suite, Build Work Zone or BTP extensions, add BTP to the security workstream from the start, alongside the S/4HANA authorization redesign and Firefighter design. For external access to Fiori, BTP is often the safer design compared to publishing a front-end server; see why the Fiori front-end server should not be on the internet.

How MTC helps

We review and design SAP BTP security as part of our SAP security practice: the account and subaccount model, role collections and their mapping to your directory groups, SAP Cloud Identity Services configuration, Cloud Connector and destination hardening, and the audit log and evidence an auditor will ask for. We include BTP in segregation of duties analysis and access reviews alongside the ERP. On large programs we work alongside leading global audit, risk and technology consulting firms, with a senior Swiss-based team accountable for the security outcome.

Frequently Asked Questions

What is SAP BTP security?

SAP BTP security is the set of controls that protect the SAP Business Technology Platform and the applications and integrations running on it. It covers the account model (global account, directories, subaccounts), platform and business authorizations (role collections), identity and authentication through SAP Cloud Identity Services, connectivity back to on-premise systems through the Cloud Connector and destinations, and audit logging. It is a separate layer from S/4HANA authorizations and needs its own design and review.

What is a role collection in SAP BTP?

A role collection is the unit of authorization you assign in SAP BTP. Applications declare role templates (scopes and attributes); roles are created from those templates, and role collections group one or more roles. Role collections are assigned to users directly or, preferably, mapped to user groups delivered by the identity provider, so that access follows the joiner-mover-leaver process of the corporate directory.

Should SAP BTP use SAP ID service or SAP Cloud Identity Services?

For business users, use an SAP Cloud Identity Services tenant (Identity Authentication) as the identity provider of the subaccount, usually acting as a proxy to the corporate identity provider such as Microsoft Entra ID. This gives you corporate single sign-on, MFA, conditional authentication and group-based role assignment. The default SAP ID service should be limited to a small number of named administrators or removed from user logon.

How do you secure the SAP Cloud Connector?

Run it on a dedicated, hardened host; change the initial administrator password and connect administration to your directory; expose only the virtual hosts, URL paths and RFC function modules that the BTP applications actually need, never a whole system; prefer principal propagation over shared technical users; keep the Cloud Connector version current; and forward its audit log to your monitoring. The Cloud Connector is a control point between the cloud and your SAP systems and should be reviewed like one.

How long does SAP BTP keep audit logs?

The BTP audit log service keeps entries for a limited period only (90 days by default in the Cloud Foundry environment). If you need longer retention for audit or investigations, retrieve the logs regularly through the Audit Log Retrieval API and store them in your SIEM or log archive.