Security Logging for SAP BTP

As adoption of SAP BTP grows, so does the need to maintain trust in the business processes that depend on the platform. As organizations increasingly rely on BTP to extend SAP functionality and support analytics, automation, integration, and AI-enabled innovation, it becomes essential to monitor security-relevant events across global accounts, subaccounts, connections, integrations, and application runtimes.

This can be achieved by analysing two important log sources for BTP. The first is the Cloud Foundry Controller (CAPI) which governs application deployment and management in BTP. CAPI is the central API service that receives requests and translates them into actions within Cloud Foundry (CF). Cloud Foundry is the platform within BTP that is used to build, deploy and run applications.

CAPI v3 is an API that can be used to retrieve events from the /audit_events endpoint in Cloud Foundry. This includes actions such as service instance and service key lifecycle events, space and organization role assignments, and application lifecycle changes. To retrieve Cloud Foundry audit events from the CF CAPI v3 /v3/audit_events endpoint, you need to authenticate with a Cloud Foundry platform user and assign that user the right level of visibility across the relevant organizations and spaces. A dedicated technical user should be created in SAP Identity Authentication Service and assigned the appropriate Cloud Foundry visibility — typically the Org Auditor role at the organization level and the Space Auditor role in each monitored space — for each organization that needs to be monitored.

After the technical user is created, the IAS origin key should be identified from the SAP BTP trust configuration and used during Cloud Foundry CLI login or token requests. Access should be validated using the CF CLI by confirming the active target, checking the user’s assigned roles, and testing the endpoint with cf curl against /v3/audit_events.

For automated monitoring, integrations should retrieve UAA bearer tokens programmatically using the technical user credentials and securely store those credentials in a secret store or protected environment variable. Once configured, the integration can continuously poll the CAPI v3 audit events endpoint to collect Cloud Foundry runtime events, including service instance changes, service key activity, role assignments, and other audit-relevant events. Because CAPI v3 retains events for 14 days only, polling intervals must be short enough to ensure no events are missed before expiry.

The second important source for security related events in BTP is the Audit Log Management Service. This is a centralized logging and compliance service that collects, stores, and provides access to audit-relevant events across SAP BTP services and environments. This includes user logons and failures, role and permission changes, subaccount configuration changes, API calls, and administrative actions. The CF v2 Audit Log API is used to retrieve events from the service.

To use the CF v2 Audit Log API in SAP BTP, start by creating or locating an Audit Log Management Service instance for the scope of audit events you need to collect. The central plan, which must be deployed in the EU10 region, is used for global account-level audit events, while the standard plan is used for audit events from individual subaccounts. For each required service instance, navigate to the target subaccount in the SAP BTP Cockpit, open Services > Instances and Subscriptions, and select the relevant Audit Log Management Service instance.

Next, create a service key for the instance. The service key contains the API endpoint and OAuth credentials needed to authenticate against the service. After the key is generated, copy the full JSON credential block and identify the key fields: the root-level url, which is the Audit Log Management API endpoint; uaa.url, which is used only for token generation; and the uaa.clientid and uaa.clientsecret, which are used as OAuth client credentials.

Authentication is performed using the OAuth 2.0 client credentials grant type. Send a POST request to uaa.url with /oauth/token appended, using Basic Authentication with the client ID and client secret from the service key. Include grant_type=client_credentials in the request body. A successful response returns an access token, which is then passed as a Bearer token in subsequent API calls.

Once authenticated, retrieve audit log records by sending a GET request to the CF v2 audit log endpoint using the root-level API url, not the uaa.url. The request follows the pattern url/auditlog/v2/auditlogrecords?time_from=<ISO8601_datetime>, with the access token included in the Authorization header. The time_from parameter limits the results to records created at or after the specified timestamp, and additional filters such as time_to can be used to narrow the query further.

This process must be repeated for each Audit Log Management Service instance. Each central or standard instance has its own service key, credentials, API endpoint, and OAuth token, so credentials should not be reused across subaccounts or service plans.

The Cybersecurity Extension for SAP delivers comprehensive security logging and monitoring for SAP BTP by integrating with key telemetry sources, including the BTP Audit Log Management Service and Cloud Foundry APIs. Through this integration, the extension provides real-time detection and alerting across the following classes of events in BTP.

  • Identity and Access Management – including the creation, modification, and deletion of identity providers, users, user groups, roles, and role collections; assignment of role collections to users; and high-risk privilege grants such as Global Account, Subaccount, Security Administrator, and emergency administrator access.
  • Authentication – covering successful and failed logons, SAML authentication errors, IAS token handling issues, OAuth token issuance, authorization codes, JWT token creation, and service client authentication activity.
  • Configuration and Governance – including configuration changes at the global account and subaccount level, password policy updates, API access and OAuth client configuration changes, and token signing key updates.
  • Federation and Trust Configuration – such as creation, modification, and deletion of SAML attribute-to-role collection mappings, which can dynamically grant access through identity federation.
  • Service and Credential Management – including creation, modification, and deletion of service instances and service keys, as well as access to service key credentials, representing a critical control point for sensitive data exposure.
  • Cloud Foundry Platform – covering application lifecycle actions (stop, restart, restage, environment changes, and task execution), space and organization lifecycle events, role assignments and removals, and updates to space security configurations.
  • Platform Extensibility and Supply Chain – including registration, update, and deletion of service brokers and buildpacks, which influence the software supply chain and runtime behavior of applications.

By correlating these classes of events into contextual alerts—such as privilege escalation, unauthorized configuration changes, identity misuse, or potential data exposure risks—the Cybersecurity Extension enables organizations to transition from fragmented logging to a centralized, policy-driven detection and response capability across the SAP BTP landscape.

Frequently Asked Questions

Why is security logging important for SAP BTP?

Security logging is important for SAP BTP because the platform supports business-critical applications, integrations, automation, analytics, and AI-enabled services. Monitoring security-relevant events helps organizations detect unauthorized access, privilege escalation, configuration changes, service credential misuse, and other activities that could impact the integrity and security of SAP cloud environments.

What are the main log sources for SAP BTP security monitoring?

The two main log sources are Cloud Foundry CAPI v3 audit events and the SAP BTP Audit Log Management Service. CAPI v3 provides visibility into Cloud Foundry runtime activity, while the Audit Log Management Service captures audit-relevant events from SAP BTP services and environments, including authentication, authorization, configuration, and administrative activity.

What does the Cloud Foundry CAPI v3 audit events endpoint capture?

The CAPI v3 audit events endpoint captures Cloud Foundry platform activity such as application lifecycle changes, service instance creation or deletion, service key activity, space and organization role assignments, and other runtime events. These events are useful for monitoring changes that may affect application security, service access, or platform governance.

How is access to CAPI v3 audit events configured?

Access to CAPI v3 audit events requires authentication with a Cloud Foundry platform user. A dedicated technical user should be created and assigned appropriate visibility across the organizations and spaces being monitored, typically using the Org Auditor and Space Auditor roles. Access should then be validated using the Cloud Foundry CLI and tested against the /v3/audit_events endpoint.

How long are CAPI v3 audit events retained?

CAPI v3 audit events are retained for 14 days. For this reason, automated monitoring integrations should poll the endpoint regularly to ensure that events are collected before they expire.

What does the SAP BTP Audit Log Management Service capture?

The SAP BTP Audit Log Management Service captures audit-relevant events such as successful and failed logons, role and permission changes, subaccount configuration updates, API calls, service activity, and administrative actions. It provides a centralized source of security and compliance evidence across SAP BTP services and environments.

How are Audit Log Management Service events retrieved?

Audit Log Management Service events are retrieved using the CF v2 Audit Log API. Access requires a service instance, a service key, and OAuth client credentials. The integration first requests an OAuth access token using the client credentials grant type, then uses the token to retrieve audit log records from the audit log API endpoint.

What is the difference between the central and standard Audit Log Management Service plans?

The central plan is used for global account-level audit events and must be deployed in the EU10 region. The standard plan is used to collect audit events from individual subaccounts. Organizations may need both plans depending on the scope of monitoring required.

Why should service keys and credentials be managed separately?

Each Audit Log Management Service instance has its own service key, OAuth credentials, API endpoint, and token flow. Credentials should not be reused across subaccounts or service plans because each instance represents a separate logging scope and security boundary.

How does the Cybersecurity Extension for SAP support SAP BTP monitoring?

The Cybersecurity Extension for SAP integrates with the SAP BTP Audit Log Management Service and Cloud Foundry APIs to centralize security monitoring and alerting. It detects high-value events across identity and access management, authentication, configuration governance, federation and trust settings, service and credential management, Cloud Foundry activity, and platform extensibility.

What types of risks can be detected through SAP BTP security logging?

SAP BTP security logging can help detect privilege escalation, unauthorized configuration changes, identity provider misuse, suspicious authentication activity, service key exposure, changes to trust mappings, risky Cloud Foundry role assignments, and modifications to service brokers or buildpacks that may affect the application supply chain.

What is the main benefit of centralizing SAP BTP security monitoring?

Centralized SAP BTP security monitoring helps organizations move beyond fragmented log collection. By correlating events across accounts, subaccounts, services, and runtime environments, organizations can identify meaningful security incidents faster and support a more policy-driven approach to detection, response, and compliance.

Share the Post: