Foundation Services: Overview and Capability Map

JinJin48

SAP Consultant | BTP · S/4HANA · US Global Rollout

May 12, 2026 · 17 min read

Where This Article Sits#

References#

1) The Foundation Services Landscape#

According to SAP Learning, Foundation Services are “a collection of essential, cross-cutting services that provide the fundamental capabilities required to run, manage, secure, and extend all applications and services on the platform.” They are not a separate product tier — they are bundled with SAP BTP accounts and exist as a prerequisite layer beneath every application domain.

They are not substitutes — a project needs all four groups operational before any business application goes live.

2) How It Connects to S/4HANA#

Foundation Services sit between the SAP BTP platform layer and the business applications (whether SAP S/4HANA Cloud, on-premise S/4HANA, or BTP extensions). The diagram below shows a typical SAP S/4HANA extension scenario and where each Foundation Service operates.

┌─────────────────────────────────────────────────────────────┐
│                    SAP BTP (Cloud)                          │
│                                                             │
│  ┌──────────────┐   ┌────────────────────────────────────┐  │
│  │ BTP Extension│   │       Foundation Services          │  │
│  │ Application  │◄──│  IAS (AuthN) → XSUAA/AMS (AuthZ)  │  │
│  │ (CF / Kyma)  │   │  Destination Svc → Cloud Connector │  │
│  └──────┬───────┘   │  Cloud ALM (Monitoring)            │  │
│         │           │  cTMS (Artifact Transport)         │  │
│         │           └────────────────────────────────────┘  │
│         │                                                   │
└─────────┼───────────────────────────────────────────────────┘
          │ Cloud Connector (outbound tunnel, no inbound ports)
          │
┌─────────▼───────────────────────────────────────────────────┐
│            On-Premise Network                               │
│                                                             │
│  ┌─────────────────┐    ┌──────────────────────────────┐   │
│  │  SAP S/4HANA    │    │  Corporate Identity Provider │   │
│  │  (on-premise)   │    │  (Azure AD, Okta, LDAP)      │   │
│  └─────────────────┘    └──────────────────────────────┘   │
└─────────────────────────────────────────────────────────────┘

As documented on the SAP BTP Connectivity Help page, Cloud Connector uses a reverse-invoke proxy pattern: the connection is always initiated from the on-premise side outward toward SAP BTP, so no inbound firewall rules are required on the corporate network. IAS can act as an identity proxy, federating the corporate IdP identity into BTP so that end-users get SSO without duplicate accounts. Cloud ALM receives telemetry from both BTP runtimes and on-premise SAP systems, giving operations teams a single monitoring console across the hybrid landscape.

Key point: Foundation Services are the integration glue between the customer’s existing on-premise SAP landscape and BTP — without them configured correctly, BTP extensions cannot authenticate users, call backend APIs, or be promoted to production safely.

3) Maturity Map#

4) Requirements Checklist#

Identity Authentication (IAS)#

Identity Provisioning (IPS)#

XSUAA and AMS (Authorization)#

Cloud Connector and Destination Service#

Cloud ALM#

Cloud Transport Management (cTMS)#

5) Decision Criteria#

The three questions to ask first#

Q1. What is the specific operational pain point that Foundation Services configuration will solve?

The answer must be measurable. “We need security” is not a pain point — “end-users cannot log into the BTP extension using their corporate credentials” or “on-premise BAPI calls from the BTP app are failing because there is no secure tunnel” are pain points. Each Foundation Service maps to a specific operational need; projects that cannot articulate the need tend to over-configure or configure nothing until the last sprint.

Q2. What are the data residency and identity governance requirements for this deployment?

IAS tenants, Identity Directory, and XSUAA/AMS configurations store and process user identity data. Some customers have data residency requirements (EU data in EU regions only) or HR data classification rules that affect which IPS source systems can be used and where Cloud ALM telemetry is stored. These constraints must be identified before any Foundation Service is provisioned.

Q3. Who has budget authority and organizational responsibility for operating Foundation Services post go-live?

Foundation Services require ongoing administration — role collection reviews, IPS provisioning job monitoring, Cloud Connector version upgrades, Cloud ALM alert routing. If there is no named owner with budget authority, the services degrade silently. Confirm the internal sponsor and operating team before foundation design is finalized.

Domain selection by project context#

Licensing and cost#

6) Common Failures#

Failure 1: IAM design deferred to implementation phase

The most common Foundation Services failure is treating identity and access management as a configuration task rather than an architectural decision. Teams defer IAS/XSUAA/AMS design until after the application is built and then discover that the IdP federation topology, role model, or token issuer URL cannot be changed without redeployment. IAM design must be completed — and approved by the customer’s security team — before the first sprint of application development begins.

Failure 2: Cloud Connector scope over-exposure

Security teams reviewing Cloud Connector configurations routinely find that entire host paths have been exposed rather than specific API endpoints or RFC function modules. This violates the principle of least privilege and creates audit findings that delay go-live. The exposure list must be reviewed and approved by the customer’s security architect before the Cloud Connector is connected to any non-development system.

Failure 3: XSUAA role collections undocumented and unowned

Projects that go live without a documented role collection matrix and an assigned administrative owner per subaccount accumulate unreviewed access over time. The requirements phase must produce a role collection design document with named owners, and the handover to operations must include a formal review step.

Failure 4: No transport pipeline until the week before go-live

cTMS transport route design is consistently underestimated. Teams build the DEV → QA → PROD promotion path in the final sprint, discover that cross-global-account transport requires additional authorization involving the customer’s SAP contract administrator, and delay go-live. cTMS transport landscape design must be done in the first quarter of the project, not the last.

Failure 5: Cloud ALM not onboarded until post go-live

Cloud ALM onboarding is treated as an “operations task” that can be done after the application is live. The result is that the first weeks of production operation are blind — no health monitoring, no integration exception alerts, no business process visibility. Cloud ALM onboarding for all in-scope runtimes should be a go-live gate criterion.

Failure 6: Principal Propagation misconfigured for on-premise ABAP

Principal Propagation — forwarding the BTP end-user’s identity to the on-premise ABAP backend via X.509 certificates — is frequently scoped during requirements but never implemented correctly because the ABAP side configuration (STRUSTSSO2, SM59, certificate trust) requires Basis involvement that is not scheduled. Basis resource availability for this configuration must be confirmed as a project dependency during requirements.

Failure 7: IPS deletion policy not agreed before provisioning goes live

IPS can hard-delete user records in target systems when a source-side deletion event occurs. If the deletion management policy is not explicitly agreed with the customer’s data governance team before production provisioning jobs run, IPS may cascade a hard-delete to SAP S/4HANA Cloud or SuccessFactors — removing transaction history and audit trail. Deletion policy approval must be a formal sign-off item during requirements.

FAQ#

Q: Are Foundation Services relevant for customers using SAP BTP for cloud-native applications with no on-premise connectivity?

Yes. Even a purely cloud-native BTP deployment requires IAS for user authentication, XSUAA or AMS for application authorization, and Cloud Transport Management for promoting application artifacts through environments. Cloud Connector is the only Foundation Service that is genuinely optional when there are no on-premise backends.

Q: What is the licensing position for Foundation Services — do they require a separate purchase?

Most Foundation Services are bundled with SAP BTP accounts or qualifying SAP cloud subscriptions and Enterprise Support agreements. Cloud ALM is included at no additional cost with qualifying subscriptions. XSUAA and CF environment entitlements are included with the CF environment quota. Cloud Transport Management requires a subscription (standard or free tier). Cloud Connector is a free download that runs on customer-owned infrastructure. IAS tenant entitlements are included with qualifying BTP global accounts; verify the specific terms with your SAP contract administrator.

Q: When should we descope Foundation Services from a project?

Descope Cloud Connector when there are no on-premise backend systems in scope. Descope Cloud ALM when the customer’s contract does not include the qualifying subscription and there is no budget to add it — but document this as an operations risk. Do not descope IAS, XSUAA/AMS, or cTMS from any BTP project that will go to production; these are non-negotiable for a production-grade deployment.

Q: Is XSUAA being deprecated? Should we still use it for new projects?

XSUAA is not deprecated and there is no publicly confirmed end-of-life date as of 2026-05-12. SAP’s stated strategic direction is to migrate authorization from XSUAA to IAS + AMS, and SAP recommends that new applications adopt IAS + AMS from the start. For new BTP projects, the recommended starting point for authorization is IAS + AMS; XSUAA is acceptable if the customer’s BTP team has existing expertise and the authorization model does not require instance-level policies.

Q: How should requirements for Foundation Services be documented?

Foundation Services requirements should be captured in the project’s architecture decision record (ADR) or equivalent documentation, covering: (1) IAM topology — IdP federation diagram, role model, token issuers; (2) Connectivity map — all on-premise systems, exposed resources, Destination definitions; (3) Transport landscape — node topology, approval workflow, CI/CD integration; (4) Operations scope — which Cloud ALM use cases are in scope and who owns them. These four documents should be produced during the requirements phase and approved before detailed design begins.

Summary#

Foundation Services are not a single product — they are the operational backbone of every SAP BTP deployment. The capability map groups them into four areas: Security & Identity (IAS, IPS, XSUAA, AMS), Connectivity (Cloud Connector, Destination Service), Operations (Cloud ALM, Alert Notification), and DevOps (Cloud Transport Management). Each group has distinct requirements that must be addressed during the project’s requirements phase. The most expensive mistakes in BTP projects — delayed go-lives, security audit findings, untraceable user access — trace back to Foundation Services decisions that were deferred until implementation. The articles that follow in this series drill into each capability in depth.

What to Read Next#