A 2026 Perspective
How today’s enterprises must evolve their hybrid connectivity, avoid technical user risks, and embrace next-gen operations
In an era of hybrid cloud adoption, enterprises rely on robust connectivity bridges between cloud platforms and on-prem systems. The SAP Cloud Connector (SCC) remains a cornerstone of this architecture, enabling secure, controlled access from the SAP Business Technology Platform (BTP) to backend landscapes such as SAP S/4HANA, BW/4HANA, or other internal services.
However, many organizations operate with older architectures, under-configured instances, or outdated practices that expose them to avoidable risks. Drawing on recent audit findings, upgrade requirements, and security best practices, this article delivers a current (2026) perspective of SCC operations – what’s new, what remains critical, and how to establish a sustainable foundation for the years ahead.
→ The SAP Cloud Connector (SCC) securely links your on‑premise systems with the SAP Business Technology Platform (BTP) in the cloud.
→ Principal Propagation replaces technical users with real end‑user identities, ensuring end‑to‑end traceability and preventing over‑privileged system accounts.
→ Enforce strict access control: expose only the resources that are truly required, and rely on targeted allowlists instead of broad, unrestricted access.
→ Use separate signed certificates for UI and system communication, choose strong algorithms (RSA 4096 / ECDSA), and proactively monitor certificate expiration dates.
The SAP Cloud Connectivity service and the SAP Cloud Connector (SCC) are essential components when implementing hybrid architectures. If an application or service running on SAP BTP needs to access data from an on-prem backend system (e.g., S/4HANA, BW, or HANA), the Cloud Connector is the go-to tool.
Technically, the SCC is a small on-prem software agent that acts as a reverse-invoke proxy. Once paired with a BTP subaccount, it opens a secure tunnel to the cloud – without requiring inbound firewall rules and without exposing backend systems to the internet. A single SCC instance can even be linked to multiple subaccounts.
It provides fine-grained access control, role-based access via LDAP, and comprehensive audit logging. Furthermore, it enables integration of internal endpoints such as BAPIs, RFCs, and OData services by using BTP Destinations.
Note!
Finally, SCC also supports Single Sign-On (SSO) by generating short-lived X.509 certificates to propagate user identities from the cloud to the on-prem system – a mechanism known as Principal Propagation.
In hybrid SAP landscapes, the Cloud Connector occupies a unique position:
Based on our security reviews at Xiting, more than 80% of customers operate SCC with outdated patches, incorrect TLS configurations, or inactive monitoring. Treating SCC as a “set-and-forget” component is no longer sustainable.
It must be maintained as an operational service: continuously patched, monitored, and governed like any critical part of the hybrid infrastructure.
Quick Self-Check:
If three or more are “No”, it’s time for an SCC health check.
Before we dive into the security‑related aspects, we’ll first give you an overview of the SAP Cloud Connector’s core architecture.
In a standard hybrid setup, the SCC is installed on-prem (or in a private cloud) and registered as a connector to one or multiple BTP subaccounts. It creates a secure outbound tunnel, enabling authorized cloud services to communicate with internal systems without inbound firewall openings.
Key elements include:
In productive environments, high availability (HA) is essential to avoid single points of failure.
A Master Node actively manages subaccount connections, tunnels, and configurations.
A Shadow Node runs in standby mode, continuously synchronizing configuration data and user context from the Master. If the Master becomes unavailable, the Shadow takes over automatically.
→ This architecture ensures fault tolerance, seamless failover, and operational continuity – critical for productive SAP BTP scenarios.
Over the past year, we have conducted multiple SCC security reviews across industries. Each environment tells its own story, but the recurring patterns are clear.
The following checklist summarizes the most relevant controls.
LDAP integration replaces local admin accounts with centralized user governance, enforcing password complexity and policies.
Note!
Principal Propagation allows an authenticated user in the cloud to be represented by the same identity in the on-prem system. It replaces technical users with true end-user context.
Contrary to common assumption, the user certificate is not the critical credential.
The SCC system certificate, its private key, and the corresponding CA trust in STRUST form the real security foundation. If the system certificate is compromised, an attacker could impersonate the SCC itself. Therefore, OS hardening and file-system protection for keystores (JKS/P12) are essential.
While SCC includes its own internal CA, some organizations prefer to delegate certificate issuance to SAP Secure Login Server (SLS) for compliance or HSM integration.
However, Secure Login Server (SLS) runs on AS Java, introduces extra operational complexity, and will reach end of life in 2027. If HSM integration is mandatory, SLS may still be justified; otherwise, the built-in SCC CA offers an excellent balance between simplicity and security.
Our field experience across multiple hybrid SAP landscapes revealed common findings:
Technical Hygiene
Identity & Access Weaknesses
Certificate & Trust Issues
BTP Neo Allowlist Misconfiguration
Subaccount Certificate Renewal
TLS Cipher Suites
Logging & Alerting
RFC-SNC Encryption
Missing
→ While version 2.18 introduced major functional improvements (e.g. certificate automation), version 2.19.x (released April 2026) focuses on operational stability.
→ SCC v2.18 (March 2025): Adds Windows Server 2025 support, automated subaccount certificate renewal, and central trust-store for LDAP/email.
→ Root CA Migration (July 2025): Let’s Encrypt Root X1 → X2. Update JVM trust stores.
→ SAP Security Patch Day (June 2025): 14 new notes affecting proxy/connectivity components.
→ DigiCert G5/G3 readiness (2026 migration): Prepare backend trust stores early.
→ Growing Focus on Principal Propagation: Supported for HTTP and RFC scenarios.
→ Integration Trends: Microsoft Fabric and other multi-cloud platforms increasingly reference SAP connectivity best practices.
Moving from a “functional” SCC to a “strategically managed” one requires a clear governance framework:
The SAP Cloud Connector remains the unsung hero of hybrid SAP landscapes. It’s the silent enabler that secures your cloud-to-ground communication – until it fails or goes unpatched.
In 2026 and beyond, SCC must be treated as an active, monitored component. Version updates, evolving CAs, and stronger identity enforcement make continuous attention essential.
By transforming SCC from a passive connector into a governed, documented, and monitored component, organizations gain not only stability and compliance but also a strategic edge in hybrid operations.
Version 2.18 or higher. Anything below 2.16 should be upgraded due to security note dependencies.
Yes, it can expose non-SAP backends securely using virtual host/port mappings and destinations.
The short-lived user certificate identifies the end-user; the system certificate authenticates the SCC itself to the backend and is the actual trust anchor.
Enable auto-renewal, monitor expiry alerts, maintain redundant SCC nodes, and keep JVM trust stores updated.
Only if required by PKI or HSM policy. For most use cases, SCC’s internal CA is sufficient and easier to maintain.
Absolutely – SCC continues to be the backbone for hybrid connectivity, even as SAP expands into zero-trust and cloud-to-cloud integrations.
