SAP API Management: how TLS ciphers are changing

The security of an integration often goes unnoticed until it breaks. That is exactly what can happen with the TLS ciphers that SAP API Management uses to accept incoming connections. If your environment still relies on one of the combinations that SAP is going to retire, the failure can occur before the system even executes your business logic: the TLS handshake fails before HTTP.

That is why it is worth reviewing in good time. In this installment we will look at what changes, which types of clients are affected and what you should review before the change reaches your datacenter.

What TLS is and why it changes

TLS (Transport Layer Security) is the protocol that encrypts communication between two systems. Before exchanging a request or a response, client and server agree on how they will protect that connection. That negotiation is called the handshake, and the algorithms used to protect it are grouped into what are known as cipher suites.

Over time, some combinations became obsolete for security reasons. TLS 1.3 left a more modern and reduced set, and both SAP and other platforms are phasing out the old suites that remain available for compatibility.

The key here is not just “TLS 1.2 or TLS 1.3”, but which suites remain within each version. In this case, what matters is that SAP API Management is retiring two TLS 1.2 cipher suites for inbound communications.

What changes in SAP API Management

The SAP KBA 3797056 technical note explains that these two TLS 1.2 cipher suites are removed for inbound communication to SAP API Management:

After the change, the client must support at least one of the suites that remain available. SAP states that clients that still offer only the two removed ciphers will not be able to complete the handshake and the connection will be interrupted before HTTP traffic.

The remaining compatibility includes:

• four TLS 1.3 cipher suites;
• two TLS 1.2 cipher suites based on ECDHE with AES GCM.

In other words, the problem is not “TLS 1.2 in general”, but a specific combination that is no longer on the allowed list.

In short, SAP is retiring two DHE suites from TLS 1.2 for inbound. The change does not affect “TLS 1.2” in general, but a specific combination that is no longer accepted.

Who is affected and who is not

The most important difference is that the change affects inbound communication: the connection that the client initiates toward API Management. It does not affect outbound communication from API Management to backends, nor scenarios that use Cloud Connector, nor SAP Cloud systems that already accept modern ciphers.

In practice, the main risk area is this:

• external clients or integrations that still only support TLS 1.2 with DHE;
• old or misconfigured Java systems;
• environments with a very restrictive TLS policy or with jdk.tls.disabledAlgorithms blocking recent cipher suites due to human error;
• very outdated browsers or clients that have an old TLS profile.

If the environment already uses TLS 1.3, or supports one of the ECDHE cipher suites that remain active, it should not be affected.

The compatibility that remains active centers on ECDHE and TLS 1.3. If a client only offers the retired cipher suites, the handshake fails before reaching the backend and the connection is blocked.

What to review before the change

The good news is that the impact can be anticipated. A practical approach is to classify the client according to the type of integration:

SAP Public Cloud systems

They usually do not require any action on the customer’s side. SAP manages the service side and the TLS profile of the runtime.

SAP Private Cloud

In this case, the recommendation is to open a service request with SAP GCO ECS and confirm that the customer’s solution uses compatible ciphers.

Java applications

If the sender is a Java application, it is advisable to review the JDK version, the environment configuration and the use of java.security.

In practice, there are two things to look at:

1. the JDK or runtime version;
2. whether jdk.tls.disabledAlgorithms is blocking modern suites due to manual configuration.

SAP’s recommendation is to review the customer’s compatibility and, if applicable, update the runtime to a recent version compatible with current standards.

Browsers and portals

In browser-based solutions, especially for Developer Portal or OAuth flows, the impact is very limited because current browsers have supported TLS 1.3 for years. The real risk appears in old or heavily restricted environments.

SAP Cloud Integration and other Integration Suite components

Here the recommendation is to confirm that the outbound component supports the cipher suites that remain active. If there are problems, you need to review the component’s outbound TLS profile and verify that there is no overly old configuration.

The good news is that the impact can be anticipated. The practical review is not complicated: identify the inbound clients, check which cipher suites they offer and validate which profiles are still compatible.

Dates and continuity plan

The KBA indicates a phased rollout by datacenter between October 26 and 29, 2026. The exact date depends on the region and the environment. Therefore, the key point is to have a clear list of clients that depend on the same TLS profile and to check each one before the corresponding date.

As an operational recommendation, the logical plan is:

1. identify the inbound integration clients;
2. check which cipher suites each sender offers;
3. validate compatibility with TLS 1.2 and TLS 1.3;
4. fix the dependency, update the runtime or change the client’s TLS policy;
5. retest the handshake right before the datacenter date.

How to test it without touching production data

Best practice is not to wait for the connection to fail in production. The sensible approach is to test the client’s behavior against a controlled, reproducible endpoint.

SAP already publishes a test endpoint that lets you validate the TLS profile after the change:

https://dhecipherremoved.apimanagement.hana.ondemand.com

A simple flow for any reader is to verify the handshake with OpenSSL and check whether the client offers an accepted cipher or a retired one. The idea is very clear:

openssl s_client -connect dhecipherremoved.apimanagement.hana.ondemand.com:443 -tls1_2 -cipher DHE-RSA-AES128-GCM-SHA256
openssl s_client -connect dhecipherremoved.apimanagement.hana.ondemand.com:443 -tls1_2 -cipher ECDHE-RSA-AES128-GCM-SHA256
openssl s_client -connect dhecipherremoved.apimanagement.hana.ondemand.com:443 -tls1_3

The expected results are not a data point in this article because that check must be done in the customer’s environment. What matters here is the logic: a connection that only offers the removed DHE sockets will fail the handshake; a connection with ECDHE or TLS 1.3 will pass it.

Practical recommendation

The change is not a day-to-day surprise: it is a reasonable and necessary security adjustment. The difference between “letting it run” and “reviewing it in time” is that an integration that looks small can become critical when the handshake fails before the backend itself does.

For any organization that uses API Management, the recommendation is simple:

• identify which systems make inbound calls;
• check whether they offer the cipher suites that SAP is retiring;
• validate Java clients, cloud integrations and external services;
• prepare a compatibility test before the date for each datacenter.

Modern services and clients are already heading in the right direction. The real risk lies in systems that are still running with an old “compatibility” TLS policy and have never reviewed which combinations are still being accepted.

Source: SAP KBA 3797056, “TLS Cipher Disablement for Inbound Communication to SAP API Management”.