Every SAP BTP audit follows a familiar script, and the findings rarely surprise the security team preparing for it. A weak SAP BTP security architecture tends to produce the same handful of gaps regardless of industry or landscape size: privileged accounts without multi-factor authentication, role collections that accumulated scope over years without review, and trust configurations nobody has revisited since the original subaccount setup.
Architects, platform engineers, and IT security leads running multi-tenant BTP landscapes across Cloud Foundry, Kyma, or ABAP environments face this pattern repeatedly because BTP’s identity and connectivity model is fundamentally different from on-premise NetWeaver security, and legacy habits do not transfer cleanly. This article walks through the five mistakes auditors consistently flag, why each one occurs, and how to close the gap before the next review cycle.
Why This Problem Happens
SAP BTP security architecture spans multiple independent services rather than one central authorization system, which is the core reason gaps accumulate unnoticed. Identity and access decisions sit across the Identity Authentication Service (IAS), the Authorization and Trust Management service commonly known as XSUAA, Cloud Connector for on-premise connectivity, and the Audit Log service for compliance evidence. A team accustomed to maintaining a single authorization concept in an S/4HANA system often assumes similar centralized visibility exists on BTP, when in reality each subaccount, each environment, and each connected identity provider carries its own configuration surface that must be reviewed independently.
Subaccount sprawl compounds this problem in mature landscapes. Organizations that started with a handful of subaccounts for a pilot project frequently end up with dozens spread across directories, each created by a different team during a different project phase, and each inheriting whatever security defaults were standard at the time it was provisioned. SAP has changed default behavior over time, including the move to subaccount-specific JSON Web Token signing keys for Cloud Foundry landscapes, and subaccounts created before such changes do not automatically pick up the newer, more secure defaults unless someone deliberately migrates them.
A third structural reason is that BTP security configuration is largely self-service by design, which accelerates development velocity but removes the natural checkpoint that existed when a central Basis team provisioned every authorization object in an on-premise system. Developers and project teams routinely have the technical ability to create destinations, assign broad role collections, or configure trust relationships without a security architect reviewing the change, and unless governance processes are deliberately built around this self-service model, configuration drift becomes the default outcome rather than the exception.
The 5 SAP BTP Security Mistakes That Keep Surfacing
5 SAP BTP Security Mistakes That Show Up During Every Audit
Every SAP BTP audit follows a familiar script, and the findings rarely surprise the security team preparing for it. A weak SAP BTP security architecture tends to produce the same handful of gaps regardless of industry or landscape size: privileged accounts without multi-factor authentication, role collections that accumulated scope over years without review, and trust configurations nobody has revisited since the original subaccount setup.
Architects, platform engineers, and IT security leads running multi-tenant BTP landscapes across Cloud Foundry, Kyma, or ABAP environments face this pattern repeatedly because BTP’s identity and connectivity model is fundamentally different from on-premise NetWeaver security, and legacy habits do not transfer cleanly.
This article walks through the five mistakes auditors consistently flag, why each one occurs, how to close the gap, and — for teams who want to move past reactive fixes — how to sequence remediation so the same findings don’t reappear in the next cycle.
Why This Problem Happens
SAP BTP security architecture spans multiple independent services rather than one central authorization system, which is the core reason gaps accumulate unnoticed. Identity and access decisions sit across the Identity Authentication Service (IAS), the Authorization and Trust Management service commonly known as XSUAA, Cloud Connector for on-premise connectivity, and the Audit Log service for compliance evidence. A team accustomed to maintaining a single authorization concept in an S/4HANA system often assumes similar centralized visibility exists on BTP, when in reality each subaccount, each environment, and each connected identity provider carries its own configuration surface that must be reviewed independently.
Three structural forces drive this pattern:
- Distributed control planes. There is no single screen that shows “everything wrong with this landscape.” Findings are scattered across IAS, XSUAA, Cloud Connector, and Audit Log, each with its own configuration surface.
- Subaccount sprawl. Organizations that started with a handful of subaccounts for a pilot project frequently end up with dozens spread across directories, each created by a different team during a different project phase, and each inheriting whatever security defaults were standard at the time it was provisioned. SAP has changed default behavior over time — including the move to subaccount-specific JSON Web Token signing keys for Cloud Foundry landscapes — and subaccounts created before such changes do not automatically pick up the newer, more secure defaults unless someone deliberately migrates them.
- Self-service by design. BTP security configuration is largely self-service, which accelerates development velocity but removes the natural checkpoint that existed when a central Basis team provisioned every authorization object in an on-premise system. Developers and project teams routinely have the technical ability to create destinations, assign broad role collections, or configure trust relationships without a security architect reviewing the change. Unless governance processes are deliberately built around this self-service model, configuration drift becomes the default outcome rather than the exception.
The 5 SAP BTP Security Mistakes That Keep Surfacing
Each mistake is framed around three questions an architect actually needs answered: what breaks, why it gets missed, and how to verify the fix holds not just how to apply it once. That last question is the one most remediation efforts skip, and it’s the reason findings reappear.
Mistake 1: Privileged Accounts Without Multi-Factor Authentication
What breaks. Global account administrators and subaccount security administrators carry the ability to reassign role collections, modify trust configuration, and provision new subaccounts, which makes them the highest-value target in any BTP landscape.
Why it gets missed. Auditors consistently find that multi-factor authentication is enforced for end users accessing business applications but left optional or unconfigured for the administrative accounts that control the platform itself — precisely the opposite priority from what the risk profile demands. Teams often assume a corporate single sign-on policy automatically extends its MFA enforcement into every BTP-connected identity provider trust relationship. It doesn’t.
How to fix it and verify it holds. Enforce MFA at the Identity Authentication Service level for every user assigned to a global account or subaccount administrator role collection, using a time-based authentication application rather than SMS-based verification, which carries known interception risks. Validate this directly in IAS conditional authentication policies — not by assumption from a general corporate MFA rollout. On a recurring basis, pull the list of accounts holding admin-tier role collections and cross-check it against IAS enforcement policy; new admin grants are the most common way this control silently lapses.
Mistake 2: Role Collections That Accumulated Scope Without Review
What breaks. XSUAA role collections in Cloud Foundry environments are built from scopes defined in an application’s security descriptor. Over the life of a project, it’s common for a role collection to carry broader scopes than the current business process requires — often because a scope was added temporarily to unblock testing and never removed.
Why it gets missed. Role collections are frequently duplicated as a starting point for a new project rather than built from scratch, so an original over-permissioned template can propagate across multiple applications and subaccounts without anyone realizing the pattern originated from a single early shortcut. This is a lineage problem as much as a configuration problem.
How to fix it and verify it holds. Treat role collection review as a recurring exercise, not a one-time setup task: compare assigned scopes against the security descriptor’s documented purpose for each scope, and remove assignments that no longer map to an active business justification. Teams maintaining infrastructure as code for their BTP landscape have a structural advantage here, since role collection definitions checked into version control are far easier to review for drift than configurations managed only through the cockpit UI — and the diff itself becomes the review artifact.
Mistake 3: Identity Provider Trust Configured Once and Never Revisited
What breaks. Trust relationships between a BTP subaccount and an external identity provider — or between a subaccount and the IAS tenant — are typically configured once during initial setup and rarely revisited unless something breaks.
Why it gets missed. Nobody owns the relationship after go-live. Problems surface when the underlying SAML or OpenID Connect configuration changes on the identity provider side, when certificates approach expiration, or when the original trust configuration was set up broader than the current use case requires — for example, still accepting assertions from an identity provider that should have been removed from the trust chain after an organizational change.
How to fix it and verify it holds. Assign explicit, named ownership to every trust relationship — not “the security team” as an abstraction, but a person or role accountable for it. Monitor certificate expiration actively rather than reactively, since an expired signing certificate on a production trust configuration creates a security gap and an availability incident simultaneously. Re-review trust scope whenever the connected identity provider’s own configuration changes, not just when BTP-side settings change.
Mistake 4: Cloud Connector Access Control Lists Broader Than Required
What breaks. Cloud Connector bridges BTP applications to on-premise systems, and its access control list defines which back-end resources a cloud application is permitted to reach through the secure tunnel. Granting access to an entire system alias or a broad range of paths — rather than scoping the list to the specific services a given cloud application actually calls — means a compromised cloud application credential could reach far more of the on-premise landscape than the application legitimately needs.
Why it gets missed. This mistake often pairs with principal propagation being enabled more broadly than necessary, where a cloud application forwards the end user’s identity to the back-end system for authorization decisions, but the underlying access control list still permits reaching resources outside the scope of that specific integration. Broad grants are the path of least resistance during implementation, and nobody revisits them once the integration works.
How to fix it and verify it holds. Audit every Cloud Connector access control list against the specific resource paths each connected application actually requires. Remove wildcard-style broad grants, and treat each new integration as an opportunity to scope access narrowly rather than reusing an existing broad entry out of convenience. The verification step matters as much as the fix: re-test the application’s actual functionality after narrowing, so the scoped list reflects real usage rather than a guess.
Mistake 5: Audit Log Service Enabled but Never Reviewed
What breaks. Many BTP subaccounts have the Audit Log service correctly provisioned and generating events for authentication attempts, role collection changes, and configuration modifications — yet nobody has a defined process for reviewing that data or retaining it for the period required by the organization’s compliance obligations.
Why it gets missed. The control looks complete on paper because the service is technically active. That’s exactly why it’s an audit finding: an active-but-unreviewed log produces no evidence that anyone would notice a suspicious pattern of role assignment changes or repeated failed authentication attempts against a privileged account.
How to fix it and verify it holds. Export audit log data to a retention target outside the service’s own default window, since BTP’s built-in audit log retention periods do not by themselves satisfy multi-year compliance retention requirements common in regulated industries. Beyond retention, assign explicit ownership for periodically reviewing audit log events for anomalies — ideally integrated into an existing SIEM process rather than treated as a standalone activity nobody has time to perform.
| Mistake | Primary Audit Risk | Typical Root Cause |
| Missing MFA on admin accounts | Account takeover of platform-level control | MFA policy scoped to end users only |
| Over-scoped role collections | Excessive access beyond business need | Duplicated templates from earlier projects |
| Stale identity provider trust | Expired certificates, unauthorized assertions | No assigned ownership after initial setup |
| Broad Cloud Connector access control lists | Lateral access into on-premise systems | Convenience-driven wildcard grants |
| Unreviewed audit log data | No detection of suspicious activity | Retention and review process never defined |
Best Practices for a Defensible SAP BTP Security Architecture
A defensible security architecture treats identity, authorization, connectivity, and audit logging as connected disciplines rather than four separate checklists completed independently. Establishing a recurring quarterly review that covers role collection scope, trust relationship certificate status, and Cloud Connector access control lists together gives a security team a single rhythm to maintain instead of four disconnected review calendars that are easy to let slip individually.
Infrastructure as code adoption for BTP security configuration, including role collections, trust settings, and destination definitions, provides a version-controlled record of every change and makes drift visible through standard code review practices rather than requiring someone to manually compare current cockpit settings against a remembered baseline. Pairing this with automated policy checks that flag role collections exceeding a defined scope threshold, or trust configurations approaching certificate expiration, shifts detection from a manual audit-time discovery to a continuous monitoring practice.
Common Mistakes Teams Make While Remediating
A frequent remediation mistake is fixing the specific finding an auditor flagged without addressing the underlying process gap that allowed it to occur, which means the same category of finding reappears in the next audit cycle under a different subaccount or application. Enforcing MFA on the one flagged administrator account without extending the same policy to every account holding an equivalent role collection is a typical example of this narrow-scope remediation pattern.
Another common mistake is over-correcting on Cloud Connector or role collection scope to the point where legitimate application functionality breaks, which then drives teams to grant broader access again under delivery pressure, effectively recreating the original problem within a few project cycles. Effective remediation requires involving the application owner in scoping decisions rather than having the security team narrow access unilaterally, since the application owner understands which specific resources or scopes the integration genuinely depends on.
Teams also sometimes treat remediation as complete once a configuration change is deployed, without updating the documentation or ownership assignment that would prevent the same gap from reopening silently. A role collection scoped correctly today with no assigned reviewer will likely accumulate scope creep again within a year, which is why sustainable remediation always pairs a technical fix with an ownership and review cadence.
Conclusion
The five mistakes covered here, missing MFA on privileged accounts, over-scoped role collections, unmanaged identity provider trust, broad Cloud Connector access control lists, and unreviewed audit log data, reflect a consistent pattern rather than isolated errors. A weak SAP BTP security architecture traces back to treating identity, authorization, connectivity, and logging as one-time setup tasks instead of ongoing disciplines that require assigned ownership and recurring review.
As BTP landscapes continue expanding across Cloud Foundry, Kyma, and ABAP environments with growing numbers of connected identity providers and on-premise integrations, the gap between a technically functional security configuration and a genuinely defensible one will keep widening for organizations that skip continuous review. Building quarterly governance rhythms around these five areas now is the most direct way to walk into the next audit cycle without repeating the same findings.
FAQs
1. What makes SAP BTP security architecture different from on-premise SAP security? SAP BTP security architecture distributes identity, authorization, connectivity, and audit responsibilities across separate services such as IAS, XSUAA, Cloud Connector, and Audit Log, rather than centralizing them in one authorization concept, which requires independent review of each component.
2. Why do role collections accumulate excessive scope over time? Role collections often start from duplicated templates created for earlier projects, and temporary scope additions made to unblock testing are rarely removed afterward, causing gradual scope creep that only becomes visible during a formal review.
3. Is multi-factor authentication mandatory for SAP BTP administrator accounts? SAP does not technically block administrator access without MFA by default, but any defensible SAP BTP security architecture should treat MFA enforcement for privileged accounts as a baseline requirement, since these accounts control platform-wide configuration.
4. How often should Cloud Connector access control lists be reviewed? Access control lists should be reviewed whenever a new integration is added and again on a recurring quarterly cycle, since scope tends to expand incrementally as teams reuse existing broad entries rather than defining narrowly scoped access for each new connection.
5. What compliance risk does an unreviewed Audit Log service create? An unreviewed Audit Log service creates a documentation gap where the control appears active but produces no evidence of ongoing monitoring, which auditors flag as a detective control that exists on paper without functioning in practice.
6. Can infrastructure as code improve SAP BTP security architecture governance? Yes, managing role collections, trust settings, and destinations through version-controlled infrastructure as code makes configuration drift visible through standard code review, which is far more reliable than manually comparing cockpit settings against a remembered baseline.
7. Do identity provider trust relationships expire automatically? The trust relationship itself does not expire, but the signing certificates underlying SAML or OpenID Connect trust do have expiration dates, and an expired certificate breaks authentication entirely while also representing an unmonitored security gap beforehand.
8. Who should own SAP BTP security architecture reviews within an organization? Ownership works best as a shared responsibility between a central platform security team that maintains policy standards and individual application owners who understand the specific access their integrations require, rather than assigning it entirely to one group.
References
Source: SAP Cloud Security Services Integration Library (SAP GitHub) — https://github.com/SAP/cloud-security-services-integration-library
Source: Get Hands-On Security Recommendations for Your SAP BTP Environment (SAP TechEd Samples) — https://github.com/SAP-samples/teched2023-XP185v
Source: SAP Community discussions on subaccount-specific JWT signing keys and role collections (SAP Blogs) — https://blogs.sap.com/t5/user/viewprofilepage/user-id/200280
