# The RISE with SAP Security Score - what a green result covers and what it misses

> The RISE with SAP Security Score: 28 metrics and three KPIs, per SAP documentation. What it leaves out, and how to cover roles, custom code and detection.

- Source: https://snok.ai/en/news/blog/rise-with-sap-security-score-what-it-measures/
- Author: Jarosław Zdanowski
- Published: 2026-11-03

---
In August 2026 SAP announced a new area in the RISE with SAP Methodology Dashboard: the Security Score. Security now accounts for 40% of a system's Operations Score, more than system health or operations setup. Of the 28 metrics behind the score, identity and access is covered by seven checks on standard SAP users. SAP's metric list contains no checks on user roles or authorisations.

The score is a sensible move by SAP. It pushes customers to switch on configuration analysis, it penalises missing checks, and it gives management a readable figure for each production SAP S/4HANA system connected to SAP Cloud ALM. The risk lies in the conclusion people draw from it: green, therefore secure. To see how far that conclusion holds, we read through the full metric list in SAP's documentation.

**In brief:**

**1/** the Security Score consists of 28 configuration checks on a production SAP S/4HANA system, evaluated once a day in SAP Cloud ALM,

**2/** it covers system hardening, how up to date components are, and standard users; roles, authorisations, custom code and non-production systems are out of scope,

**3/** it registers a missing update, but not someone exploiting the gap,

**4/** a five-step attack path can run from a test system to production data while the score stays green,

**5/** closing the gap takes attack-path analysis, custom code checks and continuous detection inside the system.

## What the RISE with SAP Security Score is

The Security Score is one of three areas in the Operations View of the RISE with SAP dashboard, alongside System Health and Operations Setup. SAP announced it in an SAP Community post on 11 August 2026. It applies to production SAP S/4HANA systems connected to SAP Cloud ALM with Configuration and Security Analysis (CSA) set up. SAP selected the checks from the SAP Security Baseline Template, described in SAP Note 2253549.

The weights in the Operations Score are fixed:

| Area | Weight |
|---|---|
| Security | 40% |
| System Health | 30% |
| Operations Setup | 30% |

The Security Score itself is built from three KPIs:

- System Hardening - 40%, 17 metrics
- Vulnerability & Lifecycle - 40%, 4 metrics
- Identity & Access Control - 20%, 7 metrics

Across the whole Operations Score that comes to 16% for hardening, 16% for component lifecycle and 8% for identity and access. Above 85% the score shows green, between 70% and 85% amber, below 70% red. The dashboard displays the previous day's value and a 30-day trend.

Two design choices work in the customer's favour. A check that has not been activated in CSA counts as non-compliant, so not measuring lowers the score. Checks that SAP is responsible for in RISE are shown too, which means the customer sees the whole picture, SAP's share included.

## What the RISE with SAP Security Score metrics check

System Hardening, with 17 metrics, covers global change options, client settings and changes to both, password length and expiry, downward-compatible passwords, encryption of internal server communication, access control lists for the RFC gateway and the message server, the message server ACL file path, gateway security and monitoring settings, gateway simulation mode, protection against unauthorised message server monitoring, and the security method used for trust relationships between systems.

Vulnerability & Lifecycle, with four metrics, looks at support package updates, support package age, SAP kernel age and SAP Cryptolib age. With only four metrics carrying 40% of the weight, a single outdated component pulls the whole score down noticeably. SAP describes this as intentional.

Identity & Access Control, with seven metrics, deals only with standard users: SAP* (default password, existence, lock status), SAPCPIC, TMSADM (default password and presence in the production client) and EARLYWATCH.

SAP is explicit on this point: "The Security Score is not intended to replace Configuration and Security Analysis." It is an entry point, and detailed analysis continues in CSA.

## What the Security Score leaves out

The areas below follow directly from the scope SAP describes.

- **Roles and authorisations.** The list of 28 metrics (SAP documentation as of 2 November 2026) contains no checks on roles, critical authorisations, SAP_ALL or segregation of duties. A technical user with a broad role does not move the score.
- **Exploitation.** The score picks up a missing update, but not a call to the vulnerable service. It assesses settings once a day; it does not detect events.
- **Custom ABAP code.** None of the metrics concerns Z code. SAP offers a separate tool for that: SAP Code Vulnerability Analyzer in the ABAP Test Cockpit.
- **Systems other than production SAP S/4HANA.** Development and test systems, SAP BW, SAP GRC and SAP BTP are outside the result.
- **Whether a connection should exist.** The score checks how a trust relationship and the RFC gateway are secured on one system. It does not ask whether that relationship ought to be there in the first place.

## An attack path with a green score

SAP risk rarely comes down to a single setting. Attackers chain several steps, none of which looks dangerous in isolation. In the example below, no step lowers the score. Some fall outside the 28 metrics, and where a metric does apply, it reports compliance:

1. Entry through a test system. Non-production systems are out of scope and are often less well protected than production.
2. A trusted RFC connection from the test system to production. The relationship uses the correct security method, so the metric reports compliance. The score never asks why the relationship exists.
3. A technical user with a broad role, without SAP_ALL and without a default password. Roles are out of scope.
4. A call to a custom Z module that performs no authorisation check. Custom code is out of scope.
5. Data leaves the system. The next morning the Security Score is still green, because none of the 28 settings has changed.

<figure class="blog-video">
  <video autoplay muted loop playsinline controls preload="metadata" poster="/images/blog/security-score-rise-with-sap-path-en.webp" width="1600" height="900" aria-label="Diagram: a five-step attack path from a test system through a trusted RFC connection and a technical user to custom Z code and data in production SAP S/4HANA, with the Security Score green at every step" style="width:100%;height:auto;border-radius:0.75rem;border:1px solid rgba(255,255,255,0.1);">
    <source src="https://snok.ai/images/blog/security-score-rise-with-sap-path-en.mp4" type="video/mp4" />
    Your browser does not support video playback. <a href="/images/blog/security-score-rise-with-sap-path-en.mp4">Download the animation (MP4)</a>.
  </video>
  <figcaption>Five steps of an attack path and the Security Score status at each one</figcaption>
</figure>

We described the same logic when writing about [SAPMAP, a tool for mapping attack paths in SAP](https://snok.ai/en/news/blog/sapmap-bloodhound-for-sap/). A control asks which settings are non-compliant. An attacker asks for the shortest route to the data. The two questions seldom have the same answer.

## Closing the gap on the customer side

SAP's roles and responsibilities matrix for RISE with SAP S/4HANA Cloud, private edition, tailored option (July 2026 version) draws the lines clearly. SAP configures the technical RFC connections to the central systems it manages. User and role administration is a packaged service: the customer either does it or buys it from SAP. Reviewing customer code is excluded from SAP's tasks. We covered that split in our article on [secure SAP S/4HANA conversion with RISE with SAP](https://snok.ai/en/news/blog/secure-sap-s4hana-conversion-rise-with-sap/). Covering what the score leaves out takes three layers of control.

**Attack-path review.** An analysis of trust relationships, RFC connections, technical users and roles across the whole landscape, non-production systems included. The output is a set of paths ranked by how close they lead to critical data.

**Custom code checks.** Security analysis of Z code in the same ATC run that checks clean core readiness, as described in our post on [central ATC on SAP BTP](https://snok.ai/en/news/blog/central-atc-sap-btp-abap-code-security/).

**Continuous detection inside the system.** Monitoring events in the SAP system and forwarding alerts to the SIEM, so that exploitation is visible as it happens. SAP's own option here is SAP Enterprise Threat Detection. The SecurityBridge platform is SAP-certified for add-on deployment in RISE with SAP (certificate no. 24982, SAP S/4HANA Cloud Private Edition 2023, valid until 5 May 2028). The certificate confirms technical integration. According to the vendor, in RISE the platform covers threat detection, vulnerability and patch management with virtual patching, ABAP code analysis, privileged access management, identity protection and SIEM integration. SNOK is a SecurityBridge partner and implements the platform for clients.

## How we review the application layer in RISE

We start from the Security Score and the CSA report, because they show what SAP has already assessed. From there we work through the areas outside the score in four steps:

1. Connection inventory - trust relationships, RFC destinations and technical users in every system of the landscape, test systems included.
2. Roles and critical authorisations - who can reach the transactions and authorisation objects that open a route to financial and personal data.
3. Custom code - a security check run over Z code, with findings rated by severity.
4. Attack paths - combining the results of the first three steps into paths that lead to data.

That scope comes from the SAP penetration tests and audits we carry out across development, test and production systems. In our [Safe Tuesday post on SAP penetration testing](https://snok.ai/en/news/blog/sap-penetration-testing/) we listed the weaknesses we find most often: misconfigured roles and authorisations, poorly secured RFC interfaces, flaws in custom ABAP code and missing security event monitoring. Roles, code and monitoring sit outside the 28 Security Score metrics; RFC interfaces are covered only in part, through the RFC gateway settings and the security method for trust relationships.

Management receives a list of attack paths with a severity rating and an action plan; the SAP team receives a list of fixes to implement. The scope is described on our pages for [SecurityBridge implementation](https://snok.ai/en/offer/sap-security/securitybridge/) and [SAP penetration testing](https://snok.ai/en/offer/sap-security/sap-penetration-testing/).

A green score is good news about 28 settings. Before it goes into a board report as a security rating, it is worth asking what could compromise your systems while that score stays green.

## Frequently asked questions

### Does the RISE with SAP Security Score cover roles and authorisations?

No. The Identity & Access Control KPI consists of seven checks on standard users: SAP*, SAPCPIC, TMSADM and EARLYWATCH. According to the metric list in SAP's documentation (as of 2 November 2026), the score does not assess roles, critical authorisations or segregation of duties.

### Where does the Security Score get its data?

From Configuration and Security Analysis in SAP Cloud ALM. The system has to be a production SAP S/4HANA system connected to SAP Cloud ALM, with the CSA checks activated. A check that has not been activated counts as non-compliant.

### Does the Security Score replace Configuration and Security Analysis?

No. SAP describes the score as an entry point. Detailed check results, including checks outside the Security Score, remain in Configuration and Security Analysis.

### How often is the Security Score updated?

Once a day. The dashboard shows the previous day's value (in UTC) and a 30-day trend.

### Does a green Security Score mean the SAP system is secure?

It means that selected configuration settings meet the SAP Security Baseline Template. It does not cover roles, custom code, non-production systems or events in the running system, so on its own it is not a security assessment.

## Sources

- SAP Community, "Introducing Security in Operations View: A New Score for RISE with SAP", 11.08.2026 - [SAP post](https://community.sap.com/t5/enterprise-resource-planning-blog-posts-by-sap/introducing-security-in-operations-view-a-new-score-for-rise-with-sap/ba-p/14460341) (accessed 02.11.2026)
- SAP Help Portal, "At a Glance: Available Scores, KPIs, and Metrics" - [SAP Cloud ALM documentation](https://help.sap.com/docs/cloud-alm/applicationhelp/scores-kpis-metrics) (accessed 02.11.2026)
- SAP Help Portal, Operation Details - Security - [SAP Cloud ALM documentation](https://help.sap.com/docs/cloud-alm/applicationhelp/security-b142fe2fffd34167b2e8384363a11c5c) (accessed 02.11.2026)
- SAP, integration certificate no. 24982, SecurityBridge Platform 7, 05.05.2025 - [certificate in the SAP directory](https://sapblobs.blob.core.windows.net/csd-live/securitybridge-platform-7-certificate-4ab0e030-2b27-11f0-a62c-6d8a53f9b906) (accessed 02.11.2026)
- SAP, "Roles and Responsibilities - SAP S/4HANA Cloud, private edition and SAP ERP, tailored option", July 2026 - [SAP responsibility matrix](https://www.sap.com/belgique/docs/download/agreements/product-policy/hec/roles-responsibilities/sap-s4hana-cloud-private-edition-and-sap-erp-tailored-option-roles-and-responsibilities-english-v7-2026.pdf) (accessed 02.11.2026)
- SecurityBridge, "Securing RISE with SAP" - [vendor page](https://securitybridge.com/solutions/securing-rise-with-sap/) (accessed 02.11.2026)
