SAP BTP Security Best Practices: Expert Tips to Protect Your Platform

Heard about those big cyber-attacks recently? No names needed, but chances are, your weekly shop has been hit. The interesting thing is that they followed a familiar pattern. Security analysts found that over 52,000 new vulnerabilities were disclosed in 2024, indicating that outdated or misconfigured systems are a growing invitation to attackers (sentinelone.com). Hackers often slip in via a ‘side door’: an unpatched server, an ill-configured cloud service, or a tricked user giving up a password. Another analysis of supply-chain incidents found that about half were driven by stolen or weak credentials (securityinfowatch.com). In plain terms, cybercrooks lean on low-hanging fruit — phishing, reused passwords, forgotten updates — more than any sci-fi-style hack.

Naturally, this has SAP customers asking: “Are our own SAP BTP environments secure? Is our user management tight? Are we following cloud security best practices?” These are great questions, and we’ve been hearing them a lot. So we asked two of our internal SAP BTP experts (Aditi & Vik)  to answer these burning questions.

How secure is SAP BTP out of the box, and what are the most common gaps you see in customer configurations?

SAP BTP puts a lot of security capability in the platform by default, but default is not the same as configured correctly. Most of the risk in a BTP landscape comes from gaps in how identity, authorisation, and integration are set up, not from the platform itself. Out of the box, BTP offers:

• Built‑in IAM & Network Security: Native support for SSO/MFA, RBAC, and the SAP Authorisation Management service. Only authorised users and roles can access each subaccount or app.
• Encryption & Transport Security: All user traffic is TLS-encrypted , and SAP exclusively establishes encrypted communication channels by default.
• Monitoring & Audit: BTP automatically logs admin and user activities. The Cloud Foundry Audit Log Viewer service lets you review all operations (applications created, users added, etc.), and connect these logs as desired.
• Secure Development Tools: SAP’s Cloud Application Programming Model (CAP) and other frameworks include built-in security guards (XSRF tokens, JWT checks, etc.), plus tools like the SAP Code Vulnerability Analyser (CVA) that statically scan ABAP code on BTP before deployment.

However, despite this strong foundation, we often see gaps in how customers configure their environments. The most common issues include:

• Bypassing SAP BTP Connectivity Guidelines
  Customers sometimes integrate third-party APIs or services directly, without using the secure connectivity mechanisms provided by SAP BTP. This can create vulnerabilities and reduce visibility over traffic flows.
• Improper Credential Management
  Instead of using SAP BTP’s built-in credential stores, credentials are sometimes hardcoded or stored in less secure ways—leaving applications open to compromise.
• Neglecting Secure App Design Principles
  Applications are not always developed using the security best practices. This can lead to poor access controls, exposure to common vulnerabilities, or lack of proper authorisation checks.

While SAP BTP provides a secure foundation, maintaining a strong security posture requires careful configuration and adherence to recommended best practices, particularly with identity management, the SAP Authorisation and Trust Management Service, the Audit Log Service, and integration security.

Identity management on SAP BTP

Identity is the foundation everything else sits on. Get it wrong and every other control built on top of it inherits the weakness.

SAP Cloud Identity Services is the umbrella term for two connected services. The Identity Authentication Service (IAS) handles authentication itself, single sign-on and multi-factor authentication, and acts as the trust broker between BTP and your identity providers. The Identity Provisioning Service (IPS) handles keeping user identities in sync, provisioning and deprovisioning accounts across connected systems as people join, move, or leave.

Trust configuration is where a lot of BTP landscapes go wrong. Each BTP subaccount needs a trust relationship with an identity provider, either the default IAS tenant or a corporate IdP federated in over SAML2 or OpenID Connect. Leaving subaccounts on default trust settings, or configuring trust once and never revisiting it as your IdP setup changes, is a common source of access that should have been revoked but was not.

Role collections are how BTP groups the individual roles an application defines into something assignable to a real person. The best practice that matters most here is assigning role collections to groups defined in your identity provider, not to individual users one at a time. Group-based assignment means access changes when someone’s group membership changes, rather than relying on someone remembering to update an individual assignment manually.

SAP Authorisation and Trust Management Service (XSUAA)

XSUAA is the OAuth-based authorisation service behind applications running in the Cloud Foundry environment on BTP. It issues and validates the tokens that control what a user, or another application, is allowed to do once they are authenticated.

Configured correctly, XSUAA scopes should be defined narrowly, matched to what an application genuinely needs, and role templates should map cleanly to real job functions rather than being granted broadly “to be safe”. The most common misconfiguration risks are scopes defined too broadly, client secrets that are never rotated, and admin-level role collections handed out more widely than the small number of people who actually need them. Each of these turns a single compromised credential into a much bigger problem than it needs to be.

Audit Log Service

The Audit Log Service captures security-relevant events across your BTP subaccounts: configuration changes, authentication events, and access to sensitive data where an application has been instrumented to log it. For any organisation with compliance obligations, this is not optional, it is usually the primary evidence you would need to produce if you ever had to demonstrate who did what and when.

Retention is limited by default, so audit logs need a plan for being retrieved and stored somewhere with longer retention if your compliance requirements demand it, rather than assuming they will simply be there whenever you need to look back. In practice this means someone needs to own pulling logs out on a schedule, whether that is into a SIEM tool or another long-term store, and someone needs to actually review them periodically rather than just archiving them unread.

Integration security

Most BTP landscapes are not self-contained, they connect out to other systems, and that surface needs its own security thinking.

• API key management. API keys are the simplest authentication method for API access, but they are also the easiest to leak and the hardest to scope tightly. Treat them as a fallback option rather than a default, and rotate them on a schedule.
• OAuth 2.0 flows in Integration Suite. Client credentials flow is the standard pattern for API-to-API authentication where there is no end user involved. Where an end user’s identity does need to carry through an integration flow, principal propagation is the mechanism designed for that, rather than sharing a single service account across every call.
• Certificate-based authentication. For higher-assurance API-to-API calls, mutual TLS with client certificates is generally the stronger option over a shared secret or API key, since a certificate is harder to leak accidentally and easier to revoke cleanly if it needs to be.

How can organisations balance innovation on BTP with the need for robust security and compliance?

Innovation and security are not opposing forces, they must evolve together. As applications built on SAP BTP grow in complexity, the security measures surrounding them must also mature. The more advanced and interconnected your solutions become, the greater the need for enhanced controls, monitoring, and governance.

Organisations that fail to innovate risk becoming obsolete. But equally, those that innovate without embedding strong security and compliance practices expose themselves to serious vulnerabilities. Every new capability, integration, or user touchpoint introduces potential risks that must be addressed as part of the innovation lifecycle.

Training is also key. Ensure developers and admins know BTP best practices. Ignorance may be bliss, but it also breeds vulnerabilities, since human error is often the weakest link. If all personnel interacting with the platform are aware of the threats, they can help mitigate them but also spot them. Make security part of your culture and process – every innovation needs to come with corresponding security guardrails.

Sustainable innovation on SAP BTP requires a security-first mindset—where governance, compliance, and threat prevention are integrated into every phase of development and deployment.

FAQs

How do I secure SAP BTP?

Start with identity: configure trust with your identity provider properly and assign role collections to groups rather than individuals. From there, configure XSUAA scopes narrowly, turn on and actually review the Audit Log Service, and secure any integrations with OAuth 2.0 or certificate-based authentication rather than long-lived API keys.

What is XSUAA in SAP BTP?

XSUAA, the SAP Authorisation and Trust Management Service, is the OAuth-based service that issues and validates authorisation tokens for applications running in the Cloud Foundry environment on BTP. It controls what a user or application is allowed to do once authenticated.

What are SAP BTP security best practices?

The core practices are: configure identity provider trust deliberately rather than leaving defaults in place, assign access through group-based role collections, keep XSUAA scopes narrow, enable and regularly review the Audit Log Service, and use OAuth 2.0 or certificate-based authentication for integrations rather than static API keys.

How does SAP Cloud Identity Services work?

SAP Cloud Identity Services covers two connected services. The Identity Authentication Service (IAS) handles authentication, single sign-on, and multi-factor authentication, acting as the trust broker between BTP and your identity provider. The Identity Provisioning Service (IPS) keeps user accounts in sync across connected systems as people join, move, or leave.

Securing your innovation on SAP BTP

The recent cyber-attacks serve as a stark reminder that even the most well-defended systems are not immune to evolving and opportunistic threats. For organisations leveraging SAP BTP to drive innovation, the message is clear: security must be treated as a continuous discipline, not a one-time checklist.

While SAP BTP provides a strong out-of-the-box security framework, real resilience comes from how that framework is implemented, monitored, and adapted. From enforcing secure connectivity and managing access intelligently, to following coding best practices and monitoring audit logs—every detail matters.

Ultimately, the balance between innovation and security is not a compromise; it’s a partnership. With the right governance, identity management, and adherence to best practices, organisations can confidently build and scale on SAP BTP—without sacrificing trust, compliance, or control.

For support on protecting your BTP environment, check out our BTP Support Factory, which has a plethora of services all designed to help you get the best out of BTP.