There is a line that comes up in nearly every SAP security review we sit through: “SAP secures BTP for us.” It is said with confidence. It is also, quietly, where most BTP risk programs stop being accurate.
As SAP Business Technology Platform becomes the connective layer between S/4HANA, third-party SaaS, and custom extensions, identity-related risk is migrating into a part of the stack most security teams have not properly mapped. Zero Trust is the right framework. The work begins when teams understand which parts of it sit on their side of the shared responsibility model.
What SAP Secures, and What it doesn’t
SAP secures the platform. You secure what runs on it.
The official BTP shared responsibility model spells this out clearly. SAP manages infrastructure, runtime services, platform patching, and the relationship with the hyperscaler. The customer owns account structure, user authorizations, custom code, application configuration, and the lifecycle of every identity that touches the platform.
That last category is where most teams underestimate the workload. SAPinsider benchmark research published in early 2026 found that only 62% of organizations live on RISE with SAP rigorously follow the shared responsibility model. The remaining 38% are running on documentation, not on execution.
Industry researchers call this the “assurance gap.” The gap is governance, and it sits squarely in your scope.
Most BTP Identities are Not People
Walk into any BTP environment that has been in production for eighteen months. Count the identities. Separate the humans from the rest.
The rest will dwarf the humans.
Veza’s 2026 State of Identity & Access Report puts the enterprise machine-to-human ratio at 17 to 1. CyberArk’s 2025 Identity Security Landscape, surveying 2,600 cybersecurity decision makers, found that machine identities now vastly outnumber humans, with nearly half carrying sensitive or privileged access. Sysdig has measured ratios as extreme as 40,000 to 1 in cloud-native footprints.
BTP fits this profile. Every service binding and every service key produces OAuth client credentials for an application or an external consumer. Every integration flow in Integration Suite, every destination configuration, every backend call through Cloud Connector relies on a non-human identity. Add the technical users that hold scopes inside XSUAA, the SAP Authorization and Trust Management Service, and the count grows fast.
These identities are easy to create and hard to retire. Entro Labs’ H1 2025 research found that nearly half of all NHIs in enterprise environments are over a year old, and 7.5% are between five and ten years old. They routinely outlive the developer who created them and the project they were created for.
In BTP, that becomes dormant service keys, OAuth clients whose owners have left the company, and technical users mapped to role collections nobody can explain.
The Three governance gaps in BTP Zero Trust
NIST SP 800-207 defines Zero Trust around three non-negotiables: continuous verification, dynamic least privilege, and per-request access decisions informed by identity, posture, and context. The tenets explicitly require that machine and human identities be governed with consistent policies.
Three structural realities of BTP shape how this plays out in practice.
Authorizations live in three planes: Entitlements are assigned at the global account and directory level. Role collections live in subaccounts and bundle the application-level roles registered in XSUAA. Application-level scopes are defined inside the xs-security.json of every microservice. A user can pass an entitlement check, hold the right role collection, and still fail a scope check. More importantly, a user can accumulate broad cross-service privileges that nobody approved holistically.
Human governance and NHI lifecycle live in different tools: Joiner-mover-leaver for employees usually runs through SAP Access Control or SAP Cloud Identity Access Governance, fed by HR systems like SuccessFactors, Workday, BambooHR, or Dayforce. Service keys and OAuth clients get created in the BTP cockpit or via the btp CLI, frequently by developers, frequently without a ticket. The joint between the two is rarely owned by anyone.
Risk reconciliation has to extend beyond the SAP boundary: SAP Access Control and SAP Cloud Identity Access Governance are built to govern the SAP estate with depth. Bringing the non-SAP applications that BTP connects to, Salesforce, ServiceNow, Coupa, NetSuite, Snowflake, Workday, into the same risk picture is the customer’s job, and it needs a layer designed for that span.
Without this cross-system view, Zero Trust quietly becomes Zero Visibility.
From policy to enforcement: BTP Zero Trust in practice
Three things turn a Zero Trust policy into a Zero Trust posture in BTP.
One control plane for human and non-human identity: Every user, every service key, every OAuth client, every technical account treated as a first-class identity with an owner, a justification, an expiry, and a defined scope.
Cross-system risk analysis driven by a ruleset, not spreadsheets: Segregation of duties does not stop at SAP. A user who can create a vendor in S/4HANA and approve the payment in Coupa is a risk regardless of which system holds which half of the conflict. The ruleset has to cover SAP and non-SAP.
Continuous lifecycle governance, not annual reviews: Provisioning, de-provisioning, recertification, and dormant account cleanup running on triggers, not on calendar quarters. When an employee leaves, every NHI they owned should be flagged for re-attestation the same day. When a service is decommissioned, its keys should be revoked the same day.
AccessHub.AI is built for this control plane problem. It extends SAP Access Control and SAP Cloud Identity Access Governance outward across the enterprise application landscape and inward into BTP itself.
For BTP, AccessHub.AI delivers:
– Identity lifecycle automation for BTP users, role collections, and entitlements, tied to HR events from Workday, SuccessFactors, BambooHR, Dayforce, and PeopleSoft.
– Hierarchy-based data restrictions that contain role proliferation as business units, regions, and legal entities multiply.
– System ID and dormant account management for service keys, OAuth clients, and technical users, eliminating the orphaned NHIs that quietly accumulate privilege.
– A pre-built cross-application ruleset for risk analysis across BTP, S/4HANA, and non-SAP systems in a single pane.
– Continuous policy enforcement with auditable evidence for SOX, GDPR, and internal compliance reviews.
The Bottom Line
Zero Trust in BTP is not about buying more tools. It is about owning the governance half of the shared responsibility model with the same rigor SAP brings to the platform half, and treating every identity, human and otherwise, as something that has to earn access continuously.
If your BTP governance still relies on memory, spreadsheets, or the developer who created the service key three years ago, the myth is running through your security posture.
The Zero Trust principle that machine and human identities deserve the same governance discipline is not marketing language inside AccessHub.AI ,it is the architecture.
