SAP Sovereign Cloud enables organisations to run SAP cloud workloads, including SAP BTP, SAP S/4HANA Cloud, and selected AI services, while meeting data residency, operational, and regulatory requirements specific to a particular country or region.
SAP continues to expand its SAP Sovereign Cloud offering and currently delivers services in the UK, US, Australia, New Zealand, Canada, and Germany.
This article explains the SAP Sovereign Cloud deployment models, its architecture, how it connects to SAP S/4HANA, and the strengths and limitations of its security model.
The problem SAP Sovereign Cloud solves
Standard hyperscaler tenants can place data in any region the provider decides. That is fine for most workloads. It is a non-starter for:
- Government and defence
- Banking and financial services
- Healthcare
- Critical infrastructure operators
These sectors face GDPR, the EU AI Act, and country-specific security mandates that require data to stay in-country and to be operated by cleared local staff. SAP Sovereign Cloud was built to close that gap.
The four pillars
SAP organises its sovereign offering around four dimensions. The four pillars come directly from SAP’s own framing on the product page.
- Data sovereignty: Data stays in local or approved-country data centres. No unauthorised cross-border transfer.
- Operational sovereignty: Security-cleared local staff run the platform. Admin actions are auditable and bounded by jurisdiction.
- Technical sovereignty: Choice of deployment stack so workloads can be matched to regulatory needs.
- Legal sovereignty: Service contracts and governance aligned with local law and accountability frameworks.
SAP Sovereign Cloud Architecture
Deployment options
There are three models to choose from, based on how strict the sovereignty requirement is and the price one is willing to pay. Cost generally rises with the level of control.
| Option | What it is | Where it runs |
| Hyperscaler-based | SAP services on AWS or Azure in sovereign-approved regions (including SAP NS2 in the US). | Hyperscaler infrastructure in specific markets. |
| SAP Cloud Infrastructure | SAP-operated IaaS built on an open-source stack (OpenStack, Kubernetes). For European customers, all data stays in the EU. | SAP-owned data centres (e.g. St. Leon-Rot, Walldorf, Frankfurt). |
| Sovereign Cloud On-Site | SAP-managed infrastructure inside a customer-selected data centre. Highest physical control. | Customer or customer-approved facility. |
Sovereign Cloud On-Site became globally available in September 2025 and is currently the strictest of the three in terms of physical control. SAP has committed €20 billion of investment in sovereign cloud through 2035.
High-Level Architecture
BTP security layers
The BTP platform within Sovereign Cloud uses several controls layered on top of one another.
- Identity and access. SAP Identity Authentication Service (IAS) with multi-factor authentication, role-based access, and OAuth 2.0 tokens.
- Encryption in transit. All traffic runs over TLS. The Cloud Connector establishes a persistent TLS tunnel with mutual X.509 certificate authentication, so no inbound firewall ports are needed.
- Subaccount isolation. Workloads are separated at the subaccount level. A misconfiguration or compromise in one subaccount has a limited blast radius.
- Cloud Connector. Acts as a reverse-invoke proxy. On-premises systems are not exposed to the public internet. Only allow-listed services are reachable.
How the Cloud Connector secures BTP-to-on-premises traffic
This is the bridge most hybrid customers care about. The mechanics:
- The Cloud Connector initiates the connection outbound (reverse invoke). The on-premises firewall stays closed to inbound traffic.
- The TLS tunnel uses mutual authentication with X.509 certificates issued by SAP BTP.
- Only services on the allowlist can be reached. Everything else is blocked.
- The technical user in BTP destinations should follow the principle of least privilege.
Certifications and compliance
Scope and availability vary by service and region. Confirm the exact scope for your tenant in the SAP Trust Center and your contract.
| Standard | Scope |
| ISO/IEC 27001:2022 | Information security management system (ISMS) |
| ISO/IEC 27017:2015 | Cloud-specific security controls. Assessed under the ISO 27001 audit, not a separate certificate |
| ISO/IEC 27018:2019 | Personal data (PII) protection in the public cloud |
| SOC 1 / SOC 2 / SOC 3 | Independent third-party audit reports on operational controls |
| PCI DSS | Cardholder data handling |
| IRAP (Australia) | Operated from Zone 3 and Zone 4 facilities |
| C5 Type 2 (BSI Germany) | German federal cloud security catalogue |
The current Sovereign Cloud ISO/IEC 27001:2022 certificate covers Sovereign Cloud Delivery Operations for government and public sector customers in Canada, Australia, New Zealand, and the UK. Other markets are under separate SAP Trust Center certificates.
Sovereign BTP versus standard BTP
| Feature | Standard BTP | Sovereign BTP |
| Data residency | Hyperscaler region; may span countries. | In-country or in an approved sovereign jurisdiction. |
| Operations staff | Global SAP teams. | Local, security-cleared personnel. |
| Infrastructure | Shared multi-tenant. | Single-tenant or on-site possible. |
| Legal jurisdiction | SAP standard terms. | Structured for local law; details vary by country and contract. |
| Hardening | Standard. | Country-specific, additional controls. |
| Cost | Lower. | Higher. You pay for isolation and clearance. |
Scenario 1: Sovereign BTP to on-premises S/4HANA
Topology
Cloud Connector sits in the customer’s DMZ or private subnet. It opens an outbound TLS tunnel to BTP’s Connectivity Service. No inbound firewall ports. Mutual auth with X.509. High availability is achieved by using a primary and shadow pair. The Cloud Connector also acts as the allowlist, defining which on-premises services are reachable from BTP.
The flow when an end user opens a BTP-hosted Fiori app that calls S/4HANA:
- End user authenticates to BTP through IAS. IAS may delegate to a corporate IdP such as Entra ID or Okta.
- The BTP application calls the Destination service. The destination is configured with ProxyType=OnPremise and Authentication=PrincipalPropagation.
- The request is wrapped with the user’s JWT and pushed through the existing tunnel to Cloud Connector.
- Cloud Connector validates the JWT and mints a short-lived X.509 certificate signed by an internal CA that the Cloud Connector itself holds.
- The request goes to S/4HANA over HTTPS, with the short-lived cert presented as SSL_CLIENT_CERT.
- SAP Web Dispatcher and ICM validate the chain, confirm the request came via a trusted reverse proxy (icm/trusted_reverse_proxy_n), and map the certificate subject to an SU01 user via CERTRULE.
Three certificates exist conceptually inside Cloud Connector; they do different jobs:
- The system certificate handles the TLS handshake to S/4HANA. Its subject and issuer must be reflected verbatim in the ICM trusted-reverse-proxy parameter.
- The CA certificate signs the short-lived user certificates. It must be imported into S/4HANA’s STRUST.
- The principal-propagation sample certificate shows the subject pattern that S/4HANA’s rule-based mapping expects.
For sovereign deployments, the default self-signed Cloud Connector CA is workable but weak. Lift the CA into your enterprise PKI, so cert lifecycle and revocation follow the same regime as the rest of your certs. SAP Note 3221674 documents the most common failure mode (the SCC system certificate not being forwarded), which surfaces as no-suitable-certificate warnings in ICM logs.
Authentication options
| Auth type | Use case |
| BasicAuthentication | Technical user, no end-user context. Common for batch and system-to-system. Avoid where an audit-of-actor is required |
| PrincipalPropagation | End-user identity is carried from BTP to S/4HANA via short-lived X.509. Required for any UI scenario |
| OAuth2SAMLBearerAssertion | Cloud-to-cloud, and cloud-to-on-prem on S/4HANA 2021+. Avoids long-lived secrets in the destination |
| OAuth2ClientCredentials with mTLS | Service-to-service, no user context. SAP recommends the mTLS-bound variant over client-secret for sovereign workloads |
| ClientCertificateAuthentication | Service-to-service with a customer or SCC-issued client cert |
Older S/4HANA releases (pre-2021) do not support OAuth, which restricts options on legacy estates.
Scenario 2: Sovereign BTP to S/4HANA Cloud, Private Edition
PCE is a single-tenant S/4HANA inside an SAP-managed VPC on a hyperscaler or on SAP Cloud Infrastructure. From BTP’s perspective, PCE behaves like on-premises behind a private network.
Connectivity options:
- Cloud Connector, deployed either in a customer-managed VM or in a managed VM inside the SAP-managed environment. Required for any BTP-originated call into PCE.
- VPC/VNet peering, ExpressRoute, Direct Connect, Cloud Interconnect, or IPSec VPN. Used for end-user and on-prem-to-PCE traffic. Not a substitute for Cloud Connector when BTP is the caller.
- SAP Private Link Service. Keeps BTP-to-PCE traffic on the hyperscaler backbone instead of the public internet. BTP-originated traffic only.
Outbound from PCE to BTP does not use Cloud Connector. PCE egresses through SAP-managed networking to BTP’s public endpoint, optionally over Private Link.
For sovereign deployments, PCE in a sovereign region (SAP Cloud Infrastructure EU, or an SAP-attested in-country region) is the most common pattern. Public Edition rarely meets sovereignty mandates today because the multi-tenant control plane and support model are global.
Scenario 3: Sovereign BTP to S/4HANA Cloud, Public Edition
Cloud Connector is not used. Public Edition is a multi-tenant SaaS reachable only via its public OData and SOAP endpoints. The integration discipline is API-led and tightly constrained:
- Only whitelisted released APIs catalogued in SAP Business Accelerator Hub are integratable. Anything not released is unavailable. There is no fallback to RFC, BAPI, or direct table read.
- Each integration is set up via a Communication Arrangement that activates a delivered Communication Scenario (for example, SAP_COM_0008 for Business Partner, SAP_COM_0092 for Enterprise Eventing) and binds it to a Communication System and a Communication User.
- Inbound auth: Basic, OAuth 2.0 SAML Bearer Assertion, certificate-based, OAuth 2.0 Client Credentials with mTLS.
- Outbound auth: Basic, OAuth 2.0 Client Credentials, OAuth 2.0 SAML Bearer.
The whitelisted-only constraint is an architectural ceiling. If a Public Edition customer needs an integration that is not included in the released API set, the only option is custom side-by-side logic on BTP that calls released APIs only. Alternatively, they can submit a feature request to SAP.
Verify the API exists in Business Accelerator Hub before committing to a design.
Comparison: the three scenarios side by side
| Dimension | On-premises S/4HANA | S/4HANA PCE (RISE) | S/4HANA Public Edition |
| Cloud Connector | Required | Required | Not used |
| Network path | Public internet via SCC tunnel | Private peering plus SCC tunnel | Public internet to multi-tenant endpoint |
| Identity propagation | SAML to short-lived X.509 via SCC CA | Same as on-prem | OAuth 2.0 SAML Bearer; signing cert from BTP, trust at S/4HC |
| Where keys live | Customer (HSM optional) | Customer for SCC; SAP for PCE encryption (HYOK via Data Custodian where supported) | SAP-managed; HYOK via Data Custodian where supported |
| Latency | One internet hop plus tunnel | Dedicated link, predictable | Variable; multi-tenant capacity dependent |
| Resilience | Customer manages SCC HA and on-prem | SAP manages PCE HA in the region; customer manages connectivity HA | SAP manages end-to-end |
| Operational ownership | Split: customer owns OS/DB/Basis, SAP owns BTP | Mostly SAP for PCE and BTP; customer for connectivity | SAP end-to-end, except customer custom code |
| Extension model | Classic plus side-by-side; full ABAP latitude | ABAP Cloud preferred plus side-by-side; classic ABAP allowed under clean-core levels | In-app key user, ABAP Cloud (restricted), side-by-side. No classic ABAP |
| Upgrade impact | Customer-controlled | SAP-scheduled within RISE windows | SAP-controlled, quarterly forced |
Planning your SAP Sovereign Cloud strategy?
At On Device Solutions, we have proven experience delivering SAP Sovereign Cloud solutions and access to a security-cleared team. We are well positioned to help our customers accelerate this architecture with confidence. We can support the journey from design and assurance through to implementation, while aligning with sovereignty, compliance, and security requirements.
Whether you’re evaluating SAP Sovereign Cloud, designing a secure BTP landscape, or integrating with SAP S/4HANA, On Device Solutions can help you navigate the technical, security, and compliance challenges.
Contact our team to discuss your requirements and build a solution that meets your organisation’s sovereignty objectives.
