SAP Community - Security

Configuring custom GRC NWBC Launch Screens restricted via PFCG roles

2026-04-22T06:00:00.054000+02:00

Challenge: Standard SAP GRC roles for NetWeaver Business Client (NWBC) grant excessive access privileges that exceed users' actual job requirements. This over-provisioning creates security risks and poor user experience, as users encounter numerous irrelevant hyperlinks and folders they don't need for their daily tasks.

Implementation Approach: The solution leverages transaction LPD_CUST (Configure Launchpad for Menus) to design custom NWBC landing pages. This involves copying standard Webdynpro application configuration, component configuration and UIBB component in which LPD_CUST role is linked.

In this blog, the detailed steps for configuring LPD_CUST, Web Dynpro Configuration and PFCG mapping is highlighted.

Environment: GRC Access Control 12.0

Launchpad Flow chart:

Section 1: LPD_CUST launchpad customisation

In Tcode LPD_CUST, we need to define the customization that is required for the workset, here we have considered GRACHOME (GRC Access Control Home Workset). It is recommended to take a copy of this workset to custom naming convention to preserve standard configuration.

Select line item GRACHOME, Click on copy.

Enter your custom values and namespace.

In ZGRACHOME, You can make all the required customisations. Here, for simplicity, I have modified the folder name to ‘Work Inbox - CUSTOM’.

Potential Use case 1: For Approvers users, you can keep only ‘Work Inbox’, Delete ‘Work Inbox - Simplified’ to make it more clear to users as to which one to use.

Potential Use case 2: In Application help, You can place company’s intranet URL link that points to a guide on how to review and approve requests. For this, you can create ‘New Application’ , select application type ‘URL’ and add the required URL.

You can follow the same steps to customize Setup, Access Management, Reports and Analytics Webdynpro Application

Section 2: NWBC Webdynpro customisation

In tcode PFCG, copy standard role SAP_GRAC_NWBC to custom role Z_TEST_NWBC,

Tcode PFCG -> Z_TEST_NWBC

Here, we are customizing the ‘My Home’ Webdynpro application GRFN_SERVICE_MAP.

Right click on ‘My Home’ Webdynpro application -> Details

We see the standard Configuration: GRAC_FPM_AC_LPD_HOME. We want to customize this Application Configuration to point our desired ‘My Home’ Layout in NWBC which we configured in LPD_CUST.

Click on ‘Application Configuration’ button.

This will launch a web URL which takes you to application configuration.

From here on, the logic is that we copy the Application Configuration, Component Configuration, UIBB Configuration and In UIBB configuration we point it to Role /instance of LPD_CUST. Refer to the flowchart.

Step 1: Create Copy of Application Configuration.

Click on Other Functions -> New Window -> Copy

Provide custom configuration ID and description

Select the relevant package, here I chose $TMP (Non-transportable), Click OK.

Click Change

We enter into the custom application configuration Z1GRAC_FPM_AC_LPD_HOME

Click on hyper link GRAC_FPM_CC_LPD_HOME

You will reach Component Configuration screen as below

Step 2: Create copy of component configuration

Click on Other Functions -> New Window -> Copy

Provide the custom configuration ID and description

Enter the desired package

Click Change

Click on Edit -> Cancel to get in Display mode, Click on hyperlink ‘GRAC_FPM_UIBB_LPD_HOME’

Step 3: Create copy of UIBB configuration

In this window, Click on Other Functions -> New Window

Click Copy

Provide the custom configuration ID and description

Click Change.

In this window, we need to map ZGRACHOME in Role field (earlier created in LPD_CUST).

Change it to ZGRACHOME. All the customizations done in ZGRACHOME can be previewed. Notice that we had changed folder ‘Work Inbox – CUSTOM’ in this scenario.

Click Save.

Select the TR and Click OK

Section 3: PFCG Role Configuration mapping

Step 1: In tcode PFCG, Role Z_TEST_NWBC

Right click on ‘My Home’ -> Details -> Change configuration to Z1GRAC_FPM_AC_LPD_HOME

Click Save

Step 2: Again, Right click on ‘My Home’ -> Details -> Click Application Configuration.

This will open up URL in web browser, we see that we are in custom application configuration Z1GRAC_FPM_AC_LPD_HOME, we see standard component configuration is mapped, we will need to change to custom component configuration Z1GRAC_FPM_CC_LPD_HOME

Click on Edit -> Assign Configuration Name

Assign the custom component configuration ID Z1GRAC_FPM_CC_LPD_HOME

Click Save.

Step 3: Click the hyperlink Z1GRAC_FPM_CC_LPD_HOME

This will open up Custom component configuration, we see that standard UIBB is mapped, but we need to change to custom UIBB Z1GRAC_FPM_UIBB_LPD_HOME

Click on F4 button on GRAC_FPM_UIBB_LPD_HOME, change it to Z1GRAC_FPM_UIBB_LPD_HOME

Click Save

Step 4: Click on Edit -> Cancel. We are in display mode. Click on hyperlink Z1GRAC_FPM_UIBB_LPD_HOME

You will find all the elements mapped as per the flowchart

Assign the PFCG role Z_TEST_NWBC to user and test the changes. Or you can Right click on ‘My Home’ -> Execute.

The customisation done in LPD_CUST reflects.

NOTE: If you assign standard role SAP_GRAC_NWBC and custom role Z_TEST_NWBC together to a user, this won’t work as intended since the system is confused whether to pick up the standard application configuration or the custom application configuration defined in the Webdynpro application GRFN_SERVICE_MAP. The intent of creating the custom role is to assign that specific custom role Z_TEST_NWBC to satisfy all NWBC access requirements for the user.

You can follow the same steps to customize Setup, Access Management, Reports and Analytics Webdynpro Application.

Conclusion:

You have now successfully created a custom PFCG role with Web Dynpro application configuration pointing to Custom NWBC screen.

Advancements in Cloud ALM and Configuration & Security Analysis application

2026-04-22T12:10:46.912000+02:00

As SAP landscapes grow and become more hybrid, maintaining a secure and compliant system configuration is no longer a one-time task - it’s an ongoing responsibility.

The Configuration & Security Analysis (CSA) application in SAP Cloud ALM Operations is designed to support exactly this. This blog walks you through the new advancements in the SAP Cloud ALM and Configuration Analysis application.

The goal is to make sure that all cloud services are operating and compliant to applicable audit standards and with an acceptable security posture.

🌟What’s New?

You can now:

✔️ Validate your systems and services against SAP security baseline - SAP Security Optimization Services

✔️Display the compliance status for your favourite systems in the CSA Home screen.

✔️Restrict access of users to specific services and systems.

✔️Create notifications, alerts and tickets.

For more information kindly visit : Configuration & Security Analysis

🔗Stay connected

Want to stay up to date on our services? Join our SAP Cloud ALM & Cross-Solution Topics community!

High-Availability Setup for SAP Secure Login Service with AWS Route 53

2026-04-23T00:01:25.054000+02:00

Introduction

Inspired by the initial blog by our Product team members

https://community.sap.com/t5/technology-blog-posts-by-sap/high-availability-setup-for-sap-secure-login-service-with-microsoft-azure/ba-p/14140475

SAP Secure Login Service for SAP GUI enables secure authentication and single sign-on (SSO) for SAP GUI using SAP BTP, leveraging its built-in platform capabilities for high availability

In most cases, this is sufficient, as the service is only used during the user’s initial login. Once authenticated, an X.509 certificate provides SSO for the rest of the session.

However, some organizations require higher resilience and opt for a multi-region failover setup. In this blog, I’ll walk through how to implement this using SAP Secure Login Service, SAP BTP Custom Domain Service, and AWS Route 53.

Architecture

Prerequisites

SAP BTP

Two subaccounts in different regions (e.g. US10, US21, EU10 etc). For this blog i have used US10 and EU10.
SLS subscribed in both subaccounts
Custom Domain Service entitlement assigned and activated in both subaccounts

AWS

Route 53 hosted zone for your domain

Identity

IAS tenants configured with SLS

Certificates

TLS certificate for sls.yourdomain.com (from a public CA)

Step 1: Configure Custom Domain Service — US10 (Primary)

In the US10 subaccount, open Custom Domain Manager and complete the following:

Reserve domain: yourdomain.com

Create custom domain: sls.yourdomain.com

Create a SaaS route: map sls.yourdomain.com to the SLS subscription

Perform TLS configurations

Create a Server Identity and generate a CSR (Certificate Signing Request)

Obtain a TLS certificate from a public CA using the CSR and Upload the full certificate chain and activate it

Activate it

Note the CNAME target shown under "DNS CNAME Recommendation" — you will need this exact value for Route 53

About the CNAME target
The CNAME target provided by Custom Domain Manager is SAP's ingress hostname for SaaS routes in the US10 region. Use exactly what Custom Domain Manager shows. Do not substitute or guess any hostname.

Step 2: Configure Custom Domain Service — EU10 (Secondary)

Repeat exactly the same steps in the EU10 subaccount. Use the same custom domain: sls.yourdomain.com.

Note the CNAME target for EU10 as well.

Why the same hostname in both subaccounts?
Each subaccount independently maps sls.yourdomain.com to its local SLS SaaS instance. This is fully supported by Custom Domain Service. Both instances respond to the same hostname, which is what makes Route 53 failover work transparently. Route 53 resolves sls.yourdomain.com to the CNAME target of whichever region is active — and that region's SLS instance is already configured to serve requests for that hostname.

Step 3: Configure IAS Redirect URI

In your IAS tenants, add the following as an allowed redirect URI for the SLS application:

https://sls.yourdomain.com/login/callback

Keep all existing redirect URIs — just add this one. Because both SLS instances share the same hostname, this single redirect URI covers both regions regardless of which instance handles the authentication request.

Each SLS instance uses a separate IAS tenant, add this redirect URI in both tenants ( US10 and EU10)

Step 4: Configure Route 53 Failover Routing

Health Checks

Create two Route 53 health checks — one per SLS instance — targeting each SLS instance hostname directly:

Health Check 1 (Primary — US10):

Protocol: HTTPS
Endpoint: <your-us10-sls-hostname> (the actual SLS instance hostname in US10, e.g. yourinstance.us10.sls.cloud.sap)
Path: /health
Port: 443
Purpose: Monitors US10 SLS instance directly

Health Check 2 (Secondary — EU10):

Protocol: HTTPS
Endpoint: <your-eu10-sls-hostname> (the actual SLS instance hostname in EU10, e.g. yourinstance.eu10.sls.cloud.sap)
Path: /health
Port: 443
Purpose: Monitors EU10 SLS instance directly

(like primary US10 setup)

Why target the SLS instance hostname directly?
The health checks must target each SLS instance hostname directly — not sls.yourdomain.com. At any point in time, sls.yourdomain.com only resolves to the currently active region. A health check on sls.yourdomain.com would only monitor whichever instance Route 53 is currently routing to, and would never detect that the primary is down (because Route 53 would have already switched). By monitoring each SLS instance hostname independently, Route 53 can detect failures in either region at any time.

CNAME records for failover

Primary Record

Name: sls.yourdomain.com

Type: CNAME

Value: api.cf.us10.hana.ondemand.com

Routing policy: Failover — PRIMARY

Health check: Yes (associate Health Check 1 — US10)

Secondary Record

Similarly for Secondary

TTL recommendation
Could set TTL to 60 seconds. A lower TTL means faster DNS propagation during failover events.

Step 5: Configure SAP Secure Login Client

Configure SAP Secure Login Client (SLC) with the SLS URL pointing to your custom domain:

https://sls.yourdomain.com/slc/v1/login

Distribute this configuration via:

GPO (Group Policy Object)
Intune
SCCM

Because the URL always points to sls.yourdomain.com, no SLC reconfiguration is needed when a failover occurs. Route 53 changes the DNS resolution transparently.

Failover Behavior

Scenario	Result
Primary healthy	Traffic → US10 SLS SaaS instance
Primary fails health check	Route 53 switches DNS to EU10 CNAME target
Primary recovers	Route 53 switches traffic back to US10

Failover Timing

Health check detection: ~30–90 seconds
DNS TTL propagation: ~60 seconds
Total worst-case failover time: approximately 2 minutes

Important Considerations

Failover Is NOT Session-Aware
Active login flows that are in progress during a failover event may fail. Users may need to retry authentication. Design user communications accordingly and set expectations with support teams.
SLS Instances Are Independent
Both SLS instances must be kept in sync manually. This includes IAS configuration, authentication policies, certificate trust configuration, and version levels. Drift between instances can cause inconsistent behavior depending on which region is active.
Certificate Strategy
You can use the same TLS certificate (same Subject Alternative Name) across both regions for simplicity, since both Custom Domain Manager instances are serving the same hostname. Alternatively, use separate certificates per region for better security isolation. Either approach is valid.
Health Checks on Both Records
It is recommended to add health checks on both primary and secondary records. Without a health check on the secondary, Route 53 may route traffic to a failed secondary during a primary failover, resulting in an outage even though the primary was available.

Testing

1. DNS Verification

nslookup sls.yourdomain.com

Confirm it resolves to the US10 CNAME target under normal conditions.

2. End-to-End Login

Open SAP GUI Secure Login Client and authenticate end-to-end. Confirm the full OIDC flow completes, including the redirect back to sls.yourdomain.com/login/callback.

3. Failover Simulation

Disable the primary health check in Route 53. Wait approximately 2 minutes, then run:

nslookup sls.yourdomain.com

Confirm it now resolves to the EU10 CNAME target.

4. Secondary Authentication

Verify that authentication still works end-to-end when Route 53 is routing to the EU10 instance.

5. Failback

Re-enable the primary health check. After the TTL expires, confirm DNS resolves back to the US10 CNAME target and authentication continues to work.

SAP Backend user mapping

There are two options to ensure that the SNC mapping remains intact:

Use parameters of the SAP Cryptographic Library to strip the region names from the certificate subject before the mapping takes place. That way, certificates from different regions will match the same SNC name. See note 2338952 for details.
Change the SAP Secure Login Service configuration to use a customer-managed certificate authority. This gives you the option to customize the subject name of the certificate so that it does not include the BTP region.

Conclusion

By combining SAP BTP Custom Domain Service and AWS Route 53 failover routing, you eliminate the single point of failure in SAP GUI authentication. The key enabler is the shared custom domain: both SLS SaaS instances respond to sls.yourdomain.com, making the OIDC redirect_uri consistent across regions regardless of which instance is currently active.

Route 53 health checks detect failures automatically and update DNS within approximately two minutes. End users and SAP Secure Login Client configurations require no changes when a failover or failback occurs.

Final Takeaway
This setup provides:

High availability for SAP GUI authentication via a managed SaaS architecture
Transparent DNS-level failover with no client reconfiguration
A consistent OIDC redirect URI across both regions

SAP Secure Login Service for SAP GUI @Christian_Cohrs1

Key figure / column based security in Datasphere

2026-04-23T09:52:00.093000+02:00

Intro

Datasphere do not directly support Key figure / column based security. SAP suggests creating separate models or separate tables for key figures and use DAC or separate spaces to protect the key figures which is a lot of extra work and a lot of extra maintenance. We will give an idea to how to solve the problem a bit more dynamic.

Challenge

We have in principle 3 levels of information about product cost. All can see level A, fewer can see level B and even fever level C. The method we will show use some of the ideas from the general Data Access Control (DAC) to hide secrets, but with our own implementation.

In short:

Create a Column DAC table in your permissions / DAC space that contains information about what a user is allowed to see.
The information from the Column DAC table is joined into relevant fact views.
Create calculated measures that will be blank (or zero) if the user is not allowed to see them.
Remove the original "secret" measures from the model.

The details:

Like for standard DAC create a table in a separate space where only trusted people can maintain the data.

Highest_Cost_Type_Permitted can have default value A. Fill the table with user IDs and their highest cost type permitted.

Create a helper table CostFactors.

Fill the table with values 1 for visible and 0 / null for not visible

The factor fields can be used to multiply like C_COST = C_Factor * <original cost field> which can give a null value. The priority factors can be used to create a measure like Authorized cost = “A_Priority_Factor” * < original A_cost_value> + “BA_Priority_Factor” * < original B_cost_value> + “C_Priority_Factor” * < original C_cost_value> which will give a not null value.

Now create a view VR_User_Cost_DAC something like

SELECT
  1 AS "join_column",
  "FilterUser_0"."UserID" AS "UserID",
  "TR_CostFactors_1"."Highest_Cost_Type_Permitted" AS "Highest_Cost_Type_Permitted",
  "TR_CostFactors_1"."A_Factor" AS "A_Factor",
  "TR_CostFactors_1"."B_Factor" AS "B_Factor",
  "TR_CostFactors_1"."C_Factor" AS "C_Factor",
  "TR_CostFactors_1"."A_Priority_Factor" AS "A_Priority_Factor",
  "TR_CostFactors_1"."B_Priority_Factor" AS "B_Priority_Factor",  
  "TR_CostFactors_1"."C_Priority_Factor" AS "C_Priority_Factor"
FROM ((SELECT "TR_CostPermission_2"."UserID",
              "TR_CostPermission_2"."Highest_Cost_Type_Permitted"
       FROM "TR_CostPermission" AS "TR_CostPermission_2"
       WHERE upper("TR_CostPermission_2"."UserID") = session_context('APPLICATIONUSER')) AS "FilterUser_0" 
	 INNER JOIN 
	 "TR_CostFactors_ZZ" AS "TR_CostFactors_1" ON "FilterUser_0"."Highest_Cost_Type_Permitted" = "TR_CostFactors_1"."Highest_Cost_Type_Permitted");

in words find the record for the current user and join to the factor table to get the relevant factors (the SQL was generated from a graphical view...). The only special feature here is the use of session_context('APPLICATIONUSER') to get the current user.

In use

A fact view containing B or C types of measures must be modified. The example here has a driving table "TR_Salesorder_items":

Step 1 (fx), create artificial “join_column” type integer value 1

Step 2 / 3, Left Join to VR_User_Cost_DAC shared from the permission space

Join on “join_column” which is just an artificial column with the value 1

Step 4) (fx) Create calculated measures like:

C_Cost = C_Factor * <original C_cost_value>

Authorized_cost = “A_Priority_Factor” * < original A_cost_value> + “BA_Priority_Factor” * < original B_cost_value> + “C_Priority_Factor” * < original C_cost_value>

Step 5) Hide original cost measures.

Step 6) Maintain Semantic type on the newly created measures.

Now B_Cost, C_cost and Authorized_cost will be safe to use.

Become an SAP Certified Security Administrator!

2026-04-27T18:16:38.460000+02:00

The new hands-on practical examination for becoming an SAP Certified Security Administrator was released earlier this month and has been well received! This certification verifies that the candidate has a general understanding of the core knowledge required of a Security Administrator in SAP system security. It proves that the candidate has a basic understanding about SAP authorization and security concepts in SAP S/4HANA Public and Private Edition and can put this knowledge into practice as a member of a project or security team.

We are pleased to announce today that we will be offering “Get Certified” Live Sessions to help prepare candidates for this examination starting May 27, 2026. In these live sessions, expert trainers will support you via a number of live sessions related to the C_SEC certification: SAP Certified - Security Administrator.

The series consists of the following:

Kick-off session - Outlining the live session series, introducing the certification, explaining the certification format and exam interface, providing tips for preparation, explaining the learning journey self-study content, practice systems, and corresponding content review sessions - 1 hour
8 content review sessions - Covering important certification-relevant topics from the courses that are part of the corresponding learning journey. These sessions complement your self-study, providing you with the opportunity to get explanations and demonstrations from an expert, who can answer questions you have about the content, helping you to be better prepared for the certification.

Sessions can be taken in any order, as your busy schedule permits.

Sessions are offered in multiple time zones, so if you are interested in becoming an SAP Certified Security Administrator, check out the link below to sign up for the sessions you’re interested in:

https://learning.sap.com/live-sessions/get-certified-sap-certified-security-administrator?searchId=51f47223-b967-47f6-85d9-f14d46cce51e&listPosition=1

The complete SAP Learning Journey for this certification is found at:

Managing User Access and Security of SAP S/4 Hana and SAP S/4HANA

CAP Developers - Call to Action to mitigate and Apply Solution provided in SAP Note 3747787

2026-05-01T21:27:54.994000+02:00

On April 29, 2026, four malicious open-source package versions were distributed into the NPM ecosystem. These malicious versions appear to exfiltrate information, such as credentials, and attempt to propagate into downstream software packages as well as adjacent software repositories when installed on a system.

If you are uncertain whether your systems have been affected, it is crucial to act promptly. Begin by following the mitigation steps outlined to maintain your environment’s security. Promptly taking these actions will help protect your systems and data from potential risks.

Other Terms

MBT
NPM
CAP
SAP Cloud Application Programming Model
MTA Build Tool

List of compromised NPM package versions:

· @cap-js/sqlite - v2.2.2
· @cap-js/postgres - v2.2.2
· @cap-js/db-service - v2.10.1
· mbt@1.2.48

Solution

If you have identified that you may be affected, perform the following measures via provided SAP Note below:

https://me.sap.com/notes/0003747787

SAP Support Ticket Component : BC-XS-CDX-NJS

Potential references:

https://www.aikido.dev/blog/mini-shai-hulud-has-appeared

https://www.stepsecurity.io/blog/a-mini-shai-hulud-has-appeared

https://www.mend.io/blog/shai-hulud-sap-cap-supply-chain-attack-claude-code/

https://onapsis.com/blog/sap-cap-mini-shai-hulud-supply-chain-attack/

https://snyk.io/de/blog/bun-based-stealer-hits-sap-cap-js-mbt-npm-packages/

Sapphire Orlando 2026: Responsible innovation - Joule architecture for security and governance

2026-05-07T12:05:19.098000+02:00

Hello everyone!

SAP Sapphire & ASUG Annual Conference Orlando 2026 is where SAP will showcase its latest AI advancements, including the next evolution of Joule. Today, I want to share insights about my session on Responsible AI —and why it matters now more than ever.

About Me
I’m part of the SAP Business AI team, where I lead work on Responsible AI. In simple terms, Responsible AI is about asking (and answering) the uncomfortable questions: What can go wrong with AI? How might it be misused? Where do we need stronger safeguards —across ethics, cybersecurity, and compliance? How to verify safety and security of AI applications? That includes topics like AI security, guidance on ethical usage, and navigating regulatory expectations—whether they’re country-specific or industry-specific. My role is to bring together experts across ethics, security, and compliance so we can build Business AI that earns trust by design.

My Session at SAP Sapphire Orlando 2026
Session title: Responsible innovation: Joule architecture for security and governance
Session link

AI is a core part of SAP’s strategy, and Sapphire is where you’ll see new innovations and experiences in Joule. Alongside that innovation, we will also talk about responsibility: how we design Joule and agentic applications so they can be used safely, governed appropriately, and protected against misuse.
Specifically, I’ll address:
- The architectural building blocks of Joule
- How they reduce common risk patterns
- How governance controls apply when AI agents are involved behind the scenes

Agent governance in business systems is not a nice-to-have feature—it is a mandatory requirement to ensure the safety of businesses and their users. We will discuss how we solve this challenge in Joule, and I look forward to learning from your experiences and ideas.

Thanks,
Sudhakar

Acing the SAP Roles and Authorization Design Review — What SAP Checks and How to Prepare

2026-05-10T20:09:03.699000+02:00

Treat your Non-Prod systems like production. Because, SAP certainly will.

We recently had a security design review done by SAP itself, and we came out with positive feedback on almost all parameters. To be honest, I was a little anxious before the report, but we had been doing everything right, so it went well. I tried to find what SAP checks before the review, but couldn't find much; hence writing this blog. This information will come in handy while prepping for a Design Review. Fair warning — if you follow all of this outside of review season too, your system will be embarrassingly clean. People will start asking what your secret is. Just smile and point them here.

Start taking care of all these things from the QA system onwards. Whatever system, SAP performs review on, they treat it as Prod system and test all parameters, and sometimes it becomes really hard to make the client understand that couple profile assignments to service users/systems users is fine 🙂 particularly the clients who are new to SAP and traditionally had one environment for their ERPs (trust me, I have seen those).

I'll go one by one, divided into 7 sections:

Governance
User Administration
Role Administration
Fiori Launchpad Administration
Custom Transactions
Authorization-based SAP S/4HANA Enterprise Management
Miscellaneous

1. Governance

Authorization Concept Documentation - No matter what phase you are in, always have the documentation updated. Like your user management policy, role design documents -> design and the role naming principles etc. It can be as simple as couple slides, but having that is a must. A good role design document should cover the full picture: what roles exist and what access they give, your naming convention, your list of critical accesses and controls. Make sure you maintain version history, segregated sections for Master, Derived and Composite Roles. My advice: don't create this document for the review. Create it as soon as you start the design, update it as your design evolves, and make sure it's accessible to key stakeholders. That's what SAP wants to see.
Naming Convention - I am not going to say that, you should use ZD or Z_D for derived roles. Use anything, but it has to be consistent. If you've been disciplined about this (e.g., prefixes that distinguish security roles, display roles, composite roles, etc.), you're fine. This one is easy to get right if you define the convention early and enforce it. Don't let people create ad-hoc role names mid-project.

2. User Administration

Master Roles Assigned to Users - Master roles are templates — they should never be directly assigned to users. Only derived roles go on users. SAP checks this explicitly. If your project has been following a proper derivation concept, you'll have no findings here.
Direct Profile Assignments — Especially SAP_ALL and SAP_NEW - SAP looks for users who have profiles assigned directly (outside of PFCG roles), and specifically calls out SAP_ALL and SAP_NEW. In QA environments, teams often give these to BASIS team members while roles are still being built. I would suggest a better one, until you have the matured roles for basis, create one role from SAP_ALL template, deactivate Sec related objects. May be call this Y*SAP_ALL*MINUS_SECURITY, but use it until you have enough inputs to create one support/FF role. A word of caution on interface users; these are often the ones that get forgotten. SAP_ALL on a system or service user is actually more dangerous than on a dialog user, because it opens the door for RFC-based attacks. Ideally you should have minimum privileged roles for them, but in the initial phases, when you don't have enough inputs, use the same role (SAP_ALL minus security). You can use STUSERTRACE for building interface user roles. Refer - STUSERTRACE users
Expired / Terminated Users with Role Assignments - SAP checks for user IDs that are expired or terminated but still have active role assignments. Locking a user is not enough, remove the role assignments too. It demonstrates that your offboarding process is complete, not just half-done. Have an admin process documented for this and make sure it's actually running even in non-prod systems.
Reference User Type - SAP checks if you are using Reference users assigned to anyone without proper reason and documentation. I am sure, noone uses it, but if you still have any use case, document it or rather use General roles assigned to all composites.

3. Role Administration - This section typically has the most findings in any review. Most are avoidable if you build good habits from the start.

Transaction Ranges in Roles
Never use transaction ranges (like MM* or FI*) in PFCG role menus. The reason is simple —> if a new transaction gets created within that range later, users automatically get access to it without any approval or awareness. Always add individual t-codes.
Transactions Not Maintained via Menu
Every t-code in a role should be added through the Menu tab in PFCG, not manually inserted into the authorization data. This maintains the relationship between the t-code and its authorization objects. If you remove a t-code from the menu later, the corresponding objects get cleaned up properly. If you bypass the menu, that cleanup doesn't happen — you're left with orphaned objects giving access nobody asked for.
Non-Existing Transactions in Roles
SAP checks for t-codes in roles that don't actually exist in the system. These are usually leftovers from ECC role copies where certain transactions don't exist in S/4HANA, or from template roles that were never cleaned up. Remove the ghost tcodes once and for all (even in the non production system roles).
Manual Objects in Roles
This is a big one. Every authorization object in a role should come from SU24 proposals; triggered by adding a t-code via the menu. If you manually add objects directly in the authorization data tab, SAP loses the ability to trace the relationship between that object and the transaction that needs it. Practical Consequence is if you ever remove that t-code, the manually added objects stay behind and keep giving access. And during upgrades or SU24 changes, those manual objects don't get updated automatically.
Org. Access Maintained at Node Level
Organizational field values (Company Code, Plant, Sales Org, etc.) should be maintained through the proper derivation mechanism, via the "Organizational Data" tab in PFCG. Not directly in the authorization data. If you edit them at the node level, the values get corrupted. Look for such values, fix it.
Incorrect / Non-Existing Org Values -
SAP also looks for org values in roles that don't exist in the system anymore. Old company codes, retired plants, restructured sales orgs. These don't break anything immediately. Run a periodic cleanup and remove obsolete org values. A quick comparison of values in AGR_1252 against the actual org data would give you the culprits.
Display Roles with Maintenance Access
If a role's name contains DISP or REPORT, SAP expects it to have only display/read access. If it also has write activities such as create, change, delete, post etc., that's a problem.
Not Generated Roles
After any change to a role, it needs to be regenerated in PFCG. An ingenerated role means users assigned to it get no access at all.
Roles with Open Authorizations
Open authorization nodes are objects in the role with no values maintained, means they don't grant access, but they create confusion and make roles hard to audit. Deactivate the nodes you don't need, fill in the values for the ones you do, and regenerate.
Inconsistent Master-Derived Roles
SAP checks if derived roles have diverged from their master. Different field values, or worse, the master role no longer exists. This breaks the whole point of the derivation concept and can lead to excess access being granted unintentionally.

4. Fiori Launchpad Administration - SAP gives a lot of attention to FIORI in S4HANA secuirty design reviews. This area surprised me as it felt more like UX administration than security. But from SAP's perspective - its both UX and Security.

Use of FIORI Groups
The FIORI groups concept is obsolete/deprecated as of SAP S/4HANA 2021. So, if you have older groups created, try to shift to Catalogs, but still you can justify the groups. But dont create any new group at all.
Unused Catalogs and Groups
Any catalog not assigned to a PFCG role is invisible to users. It's just dead weight in the system. Clean them up or assign them. SAP is firmly in the Spaces and Pages world now. If you're still using groups, plan your migration. Don't go live with a legacy Fiori structure.
Enterprise Search Authorizations
One of the most overlooked items :). People often end up maintaining S_ESH_CONN as * for all the fields. This is both a performance and Security issue. Try to maintain the proper template name and connection ID.
SAP Standard Business Catalogs and Roles
Never assign SAP standard Business Roles or catalogs directly to users or PFCG roles. Always copy them into your customer namespace, adjust to your org needs and then assign. This is both a security and a maintainability best practice.
Orphaned Catalogs and Groups
Catalogs or groups that exist but aren't assigned anywhere are just clutter. Clean them unless you have an active ongoing project reason to keep them. The same applies to orphaned tiles in Fiori Pages, where tiles pointing to catalog entries that no longer exist. These confuse users and clutter your Fiori setup.
System Alias Consistency
Fiori apps rely on system aliases to find the correct backend. If an alias is in error or has warnings, the associated OData service can't register, and the app simply won't work. Check this using SM59 or /UI2/GW_SYS_ALI and fix any discrepancies. Don't let alias issues go into production; they're hard to diagnose for end users.
Granularity of Catalogs
SAP doesn't want you to create one catalog per app. Even 2-3 is considered a bad design. Atleast 5 is a good number, if you don't want to get highlighted 🙂
Service Activation
Every Fiori app depends on an activated OData service. If the service isn't active or is in error, the app simply won't load, no error message that makes sense to the user, just a broken tile. Review all roles and catalogs and check service status. Implement a periodic control to catch regressions after transports.
OData Metadata Cache
Schedule report /UI5/UPD_ODATA_METADATA_CACHE. In test systems, hourly is fine. In production, once per night is the recommendation. This directly affects how fast Fiori apps load. It also needs to be run after importing transports, implementing SAP notes, or changing a service. Make it part of your go-live checklist.
SAP Menu Entry Cache
Similarly, run /UI2/EAM_BUILD_CACHE to cache SAP menu entries in the App Finder. Without it, the App Finder either loads very slowly or times out. If the report isn't available in your system, check whether you need to install the required SAP_UI patch level or SAP Note 2545066.

5. Custom Transactions

Unused Custom Transactions
SAP checks for Y* and Z* transactions that exist in the system but aren't in any role menu. These are typically leftovers from earlier development, retired features, or transactions that were built but never formally deployed. Lock or remove the ones you don't need. Unused custom t-codes sitting in the system are a quiet compliance risk, they can be executed by anyone with broad access, and nobody is tracking them.
Custom Transactions Not Maintained in SU24
Well, Well, Well, this is the item, which I keep iterating to ABAP teams and the client. Every custom program should have an AUTHORITY-CHECK statement, and not just for the namesake, it should check the most relevant Auth objects, for example, if a custom report is built to get the sales orders report, it should check the objects which are checked by VA03 tcode, if not all, at least few of those. Now, you can remediate this one by just adding a custom obj check in SU24 and roles, but it wont remediate the underlying vulnerability. Ideal flow should be Appropriate checks in Program --> maintained in SU24 --> Added in roles --> Added in GRC risk library (functions).

6. Authorization-Based SAP S/4HANA Enterprise Management (Licensing) -

This is the section most teams don't think about, while creating roles. But SAP does. Certain authorization objects automatically trigger Full User Equivalent (FUE) licensing, meaning any user with those objects in their roles gets charged at the highest license tier. The objects that typically come up are things like S_CALENDAR, S_PSE_ADM, S_TRANSPRT, S_USER_GRP, and S_SECPOL etc.

Refer note - 3113382 - Authorization-based SAP S/4HANA User Simulation / FUE Projection.

7. Miscellaneous — Security Profile Parameters - SAP checks quite a few security, rfc, password related parameters if you have an on-premise system. But if you are on RISE, most of these are taken care and SAP checks these parameters -

auth/check/calltransaction — Controls whether authority checks are enforced during CALL TRANSACTION statements. Recommended value is 3. If it's not set correctly, authorization checks can be silently bypassed in background and batch processes.

auth/object_disabling_active — Controls whether authorization checks can be globally switched off for selected objects. Recommended value is N. If this is active, someone with the right access can effectively turn off security for entire authorization objects system-wide. It should be N in any production system.

auth/rfc_authority_check — Controls how authentication is enforced for RFC function module calls. Recommended value is 6. Anything lower means remote function calls can be made without proper authorization checks — essentially leaving a door open for unauthenticated access via RFC. This one is often set to a lower value during development for convenience, and then forgotten. Get your Basis team to set it to 6 before go-live.

Final thought

The review itself is not the hard part. The hard part is the daily discipline during the project like maintaining SU24, following the menu-based role building approach, keeping org values clean, not letting SAP_ALL sit on users "temporarily". These are all habits, and they're much easier to build early than to fix under review pressure.

Treat your QA system like production. If you won't, SAP certainly will.

Securing SAP UI5 Applications with a Custom Node.js Backend using JWT

2026-05-22T08:33:34.794000+02:00

Hi everyone,

Introduction

When I pair SAP UI5 with a custom Node.js backend, there's no BTP or XSUAA to provide security. JWT (JSON Web Token) is the right tool for providing security. It is stateless, lightweight, and works naturally with both Express middleware and the UI5 fetch API.

This guide covers the complete end-to-end setup:

MySQL — user table with bcrypt-hashed passwords and roles
Node.js backend — JWT generation on login, protected routes via middleware
SAP UI5 frontend — token storage, role-based routing, authenticated API calls, session expiry handling
Local dev proxy—ui5.yaml config so the UI5 dev server forwards /api calls to Node.js

Why I Wrote This

A few months back, I was working on a project where we had to build a lightweight internal tool on top of an SAP landscape — a UI5 frontend talking to a custom Node.js backend. The moment security came up in the design discussion, I realized there wasn't one clear, end-to-end guide covering this specific combination: SAP UI5 + Node.js + JWT + Role-Based Access Control.

This post walks through the complete flow: setting up the database, generating the JWT on login, storing it in the UI5 frontend, protecting your Node.js APIs with middleware, proxying API calls during local development, and handling session expiry gracefully.

First, Let's Understand JWT—The Wristband at the Door

Before jumping into code, here's how I explain JWT to anyone who's new to it.

Picture a nightclub with a VIP section. The first time you arrive, the bouncer checks your ID (your email and password). Once verified, they hand you a wristband — a JWT. For the rest of the night, you don't show your ID again. You just flash the wristband. The staff trusts it because the club itself issued it and it's tamperproof.

That's exactly what happens here:

User submits their credentials to the Login API
The backend verifies them against the database
If valid, the server signs a JWT containing the user's ID, email, and role
The UI5 app stores that token and attaches it to every subsequent request
Each protected API checks the token before responding

Since the token is cryptographically signed with a secret key only the server knows, no one can fake or modify it.

Architecture Overview

The setup is a decoupled architecture—UI5 and Node.js live as completely separate projects and talk only through HTTP API calls. Here's the folder structure I used:

project-root/
│
├── backend/                        ← Node.js (Express) server
│   ├── .env                        ← Secret key and DB credentials (NEVER commit this)
│   ├── server.js                   ← Entry point — boots Express and registers routes
│   ├── repo/
│   │   └── dbconnection.js         ← MySQL connection setup
│   ├── middleware/
│   │   └── authMiddleware.js       ← JWT verification guard
│   ├── controller/
│   │   ├── userController.js       ← Login logic with bcrypt
│   │   └── adminController.js      ← Protected data APIs
│   └── routes/
│       ├── userRoutes.js           ← Public routes (login)
│       └── adminRoutes.js          ← Protected routes (require JWT)
│
└── frontend/                       ← SAP UI5 application
    ├── ui5.yaml                    ← Dev server config including API proxy
    ├── webapp/
    │   ├── controller/
    │   │   ├── View1.controller.js          ← Login page logic
    │   │   ├── AdminDashboard.controller.js
    │   │   └── UserDashboard.controller.js
    │   ├── view/
    │   │   ├── App.view.xml                 ← Root shell (contains App id="app")
    │   │   ├── View1.view.xml               ← Login screen
    │   │   ├── AdminDashboard.view.xml
    │   │   └── UserDashboard.view.xml
    │   └── manifest.json                    ← Router config lives here

Step 1: Setting Up MySQL

We need a database to store user credentials and roles. I'm using MySQL here. If you already have it installed, jump straight to the schema part.

Otherwise, install MySQL Community Server from the official MySQL site, along with MySQL Workbench for a visual interface.

Once you're logged into Workbench, open a new SQL tab and run this:

-- Create and select the database
CREATE DATABASE my_ui5_app;
USE my_ui5_app;

-- User table with role-based access
CREATE TABLE `user` (
  `user_id`        INT NOT NULL AUTO_INCREMENT,
  `user_name`      VARCHAR(100) NOT NULL,
  `email`          VARCHAR(100) NOT NULL,
  `contact_number` VARCHAR(15) DEFAULT NULL,
  `password`       VARCHAR(255) NOT NULL,        
  `role`           VARCHAR(20) DEFAULT 'User',  
  PRIMARY KEY (`user_id`),
  UNIQUE KEY `email_UNIQUE` (`email`)
);

INSERT INTO `user` (`user_name`, `email`, `password`, `role`)
VALUES ('System Admin', 'admin@company.com', '$2b$10$cUSzmudHOeDXCF6eToP3buHZULwxuuJ/J5WZYeFkStg7HBpy2uCcW', 'Admin');

INSERT INTO `user` (`user_name`, `email`, `password`, `role`)
VALUES ('Shubham', 'shubham@gmail.com', '$2b$10$xBn6cKLkEuIkSqoLSR3pw.r16EABwE7aHtIDU4KSq2czl3LW5PMpK', 'User');

Step 2: Backend — Installing Dependencies and Generating Password Hashes

Let's get the backend ready first by using commands.

mkdir backend
cd backend
npm init -y
npm install express mysql2 jsonwebtoken bcrypt dotenv

Create a .env file in the backend root:

DB_HOST=localhost
DB_USER=root
DB_PASSWORD=your_mysql_password
DB_NAME=my_ui5_app
SECRET_KEY=your_very_long_random_secret_key_here
PORT=3306

Generating Real Password Hashes
Before inserting test users into MySQL, generate proper bcrypt hashes. Create generateHash.js in your backend folder—this is a one-time utility script, not part of the running app:

const bcrypt = require('bcrypt');

async function generateHashes() {
    const adminHash = await bcrypt.hash('Admin@123', 10);
    const userHash  = await bcrypt.hash('User@123', 10);

    console.log('Admin hash:', adminHash);
    console.log('User hash: ', userHash);
}

generateHashes();

Database Connection —repo/dbconnection.js

const mysql = require('mysql2');
require('dotenv').config();

const connection = mysql.createConnection({
    host:     process.env.DB_HOST,
    user:     process.env.DB_USER,
    password: process.env.DB_PASSWORD,
    database: process.env.DB_NAME
});

connection.connect((err) => {
    if (err) {
        console.error('DB connection failed:', err.message);
        return;
    }
    console.log('Connected to MySQL');
});

module.exports = connection;

Entry Point - server.js
This boots the whole backend—wires together Express, registers the routes, and starts listening. I prefix all routes with /api to cleanly separate API traffic from any static file serving.

const express = require('express');
const dotenv  = require('dotenv');

dotenv.config();

const userRoutes  = require('./routes/userRoutes');
const adminRoutes = require('./routes/adminRoutes');

const app  = express();
const PORT = process.env.PORT || 3000;

// Parse incoming JSON request bodies
app.use(express.json());

// Register routes
app.use('/api/user',  userRoutes);  
app.use('/api/admin', adminRoutes);  

app.get('/api/health', (req, res) => {
    res.status(200).json({ status: 'Server is up and running' });
});

app.listen(PORT, () => {
    console.log(`Backend running at http://localhost:${PORT}`);
});

Start the server by giving commands to the terminal:
node server.js
npx nodemon server.js

Step 3: Backend — Login API with bcrypt and JWT

When the UI5 frontend submits credentials, the backend needs to:

Find the user in the DB by email
Compare the submitted password against the stored bcrypt hash using bcrypt.compare()
If it matches, sign a JWT containing the user's ID, email, and role.

controller/userController.js:

const jwt    = require('jsonwebtoken');
const bcrypt = require('bcrypt');
const db     = require('../repo/dbconnection');

async function loginUser(req, res) {
    const { email, password } = req.body;

    if (!email || !password) {
        return res.status(400).json({ message: "Email and password are required." });
    }

    // Fetch user by email 
    const query = 'SELECT * FROM user WHERE email = ?';

    db.query(query, [email], async (err, results) => {
        if (err) {
            console.error('DB error:', err);
            return res.status(500).json({ message: "Internal server error." });
        }

        if (results.length === 0) {
            return res.status(401).json({ message: "Invalid email or password." });
        }

        const user = results[0];

        // bcrypt.compare() checks the submitted password against the stored hash
        const passwordMatch = await bcrypt.compare(password, user.password);
        if (!passwordMatch) {
            return res.status(401).json({ message: "Invalid email or password." });
        }

        // Build the JWT payload
        const tokenPayload = {
            user_id: user.user_id,
            email:   user.email,
            role:    user.role
        };

        // Sign the token using the secret key from .env — expires in 24 hours
        const token = jwt.sign(
            tokenPayload,
            process.env.SECRET_KEY,
            { expiresIn: '24h' }
        );

        return res.status(200).json({
            message: "Login successful",
            token:   token,
            user:    { role: user.role, name: user.user_name }
        });
    });
}

module.exports = { loginUser };

routes/userRoutes:

const express       = require('express');
const router        = express.Router();
const { loginUser } = require('../controller/userController');

router.post('/login', loginUser);

module.exports = router;

Step 4: Backend — The Middleware Guard

This is the piece that protects every route requiring authentication. Every request to a secured endpoint passes through this function before reaching the controller.

middleware/authMiddleware.js:

const jwt = require('jsonwebtoken');

const verifyToken = (req, res, next) => {
    const authHeader = req.headers['authorization'];

    // Reject immediately if no Authorization header is present
    if (!authHeader || !authHeader.startsWith('Bearer ')) {
        return res.status(403).json({ message: "Access denied. No token provided." });
    }

    // Strip the "Bearer" prefix to get the raw token string
    const token = authHeader.split(' ')[1];

    jwt.verify(token, process.env.SECRET_KEY, (err, decoded) => {
        if (err) {
            // Token is expired or has been tampered with
            return res.status(401).json({ message: "Session expired or invalid token." });
        }

        req.user = decoded;
        next();
    });
};

module.exports = { verifyToken };

To protect a route, inject this middleware between the route path and the controller function:

routes/adminRoutes:

const express            = require('express');
const router             = express.Router();
const { verifyToken }    = require('../middleware/authMiddleware');
const { getItemDetails } = require('../controller/adminController');

// verifing Token 
router.get('/getItemDetails', verifyToken, getItemDetails);

module.exports = router;

controller/adminController.js:

const db = require('../repo/dbconnection');

function getItemDetails(req, res) {
    const query = 'SELECT * FROM user';

    db.query(query, (err, results) => {
        if (err) {
            console.error('DB error:', err);
            return res.status(500).json({ message: "Internal server error." });
        }

        return res.status(200).json(results);
    });
}

module.exports = { getItemDetails };

Step 5: Frontend—Configuring manifest.json

Open manifest. JSON. First, add sap.ui.layout to libraries inside manifest.json since I am using the SimpleForm control in the login view.

"libs": {
    "sap.m": {},
    "sap.ui.core": {},
    "sap.ui.layout": {}
}

Then replace the entire routing section with this:

"routing": {
    "config": {
        "routerClass": "sap.m.routing.Router",
        "controlAggregation": "pages",
        "controlId": "app",
        "transition": "slide",
        "type": "View",
        "viewType": "XML",
        "path": "ui5nodeapp.view",
        "async": true,
        "viewPath": "ui5nodeapp.view"
    },
    "routes": [
        {
            "name": "RouteLogin",
            "pattern": "",
            "target": ["TargetLogin"]
        },
        {
            "name": "RouteAdminDashboard",
            "pattern": "admin",
            "target": ["TargetAdminDashboard"]
        },
        {
            "name": "RouteUserDashboard",
            "pattern": "user",
            "target": ["TargetUserDashboard"]
        }
    ],
    "targets": {
        "TargetLogin": {
            "id": "View1",
            "name": "View1",
            "viewLevel": 1
        },
        "TargetAdminDashboard": {
            "id": "AdminDashboard",
            "name": "AdminDashboard",
            "viewLevel": 2
        },
        "TargetUserDashboard": {
            "id": "UserDashboard",
            "name": "UserDashboard",
            "viewLevel": 2
        }
    }
}

Step 6: Frontend — Proxying API Calls in Development

The UI5 dev server runs on port 8080 by default, while the Node.js backend runs on port 3000. So, I added the backend port to 3000 in the ui5.yaml file.

server:
  customMiddleware:
    - name: fiori-tools-proxy
      afterMiddleware: compression
      configuration:
        ignoreCertErrors: false
        backend:
          - path: /api
            url: http://localhost:3000   # Forward all /api calls to the Node.js backend
        ui5:
          path:
            - /resources
            - /test-resources
          url: https://ui5.sap.com
    - name: fiori-tools-appreload
      afterMiddleware: compression
      configuration:
        port: 35729
        path: webapp
        delay: 300
    - name: fiori-tools-preview
      afterMiddleware: fiori-tools-appreload
      configuration:
        flp:
          theme: sap_horizon

Step 7: Frontend — The Login View (XML)

view/View1.view.xml:

<mvc:View
    controllerName="ui5nodeapp.controller.View1"
    xmlns:mvc="sap.ui.core.mvc"
    xmlns="sap.m"
    xmlns:f="sap.ui.layout.form"
    displayBlock="true">

    <Page title="Login" showHeader="false">
        <content>

            <VBox
                justifyContent="Center"
                alignItems="Center"
                height="100%"
                class="sapUiMediumMarginTop">

                <Panel
                    width="380px"
                    class="sapUiResponsivePadding sapUiMediumPadding">

                    <VBox alignItems="Center" class="sapUiSmallMarginBottom">
                        <Title
                            text="Welcome Back"
                            level="H2"
                            class="sapUiSmallMarginBottom"/>
                        <Label text="Sign in to continue"/>
                    </VBox>

                    <f:SimpleForm
                        editable="true"
                        layout="ResponsiveGridLayout"
                        labelSpanL="12"
                        labelSpanM="12"
                        emptySpanL="0"
                        emptySpanM="0"
                        columnsL="1"
                        columnsM="1">

                        <f:content>

                            <Label text="Email Address" required="true"/>
                            <Input
                                id="loginUserId"
                                placeholder="Enter your email"
                                type="Email"
                                width="100%"
                                submit=".onLoggedIn"/>

                            <Label text="Password" required="true"/>
                            <Input
                                id="loginPassword"
                                placeholder="Enter your password"
                                type="Password"
                                width="100%"
                                submit=".onLoggedIn"/>

                        </f:content>
                    </f:SimpleForm>

                    <VBox alignItems="Center" class="sapUiSmallMarginTop">
                        <Button
                            text="Login"
                            type="Emphasized"
                            width="100%"
                            press=".onLoggedIn"/>
                    </VBox>

                </Panel>
            </VBox>

        </content>
    </Page>

</mvc:View>

Step 8: Frontend — The Login Controller

The login controller sends credentials to the backend, stores the token, and routes the user based on their role.

controller/View1.controller.js:

sap.ui.define([
    "sap/ui/core/mvc/Controller",
    "sap/m/MessageToast"
], function (Controller, MessageToast) {
    "use strict";

    return Controller.extend("ui5nodeapp.controller.View1", {

        onInit: function () {
        },

        onLoggedIn: async function () {
            const sEmail    = this.byId("loginUserId").getValue().trim();
            const sPassword = this.byId("loginPassword").getValue();

            if (!sEmail || !sPassword) {
                MessageToast.show("Please enter both email and password.");
                return;
            }

            try {
                const response = await fetch("/api/user/login", {
                    method:  "POST",
                    headers: { "Content-Type": "application/json" },
                    body:    JSON.stringify({ email: sEmail, password: sPassword })
                });

                const result = await response.json();

                if (!response.ok) {
                    throw new Error(result.message || "Login failed.");
                }

                // sessionStorage clears token automatically when the tab is closed
                sessionStorage.setItem("myAppToken", result.token);
                sessionStorage.setItem("myAppUser",  JSON.stringify(result.user));

                // Route to the correct dashboard based on role
                const oRouter = this.getOwnerComponent().getRouter();
                if (result.user.role === "Admin") {
                    oRouter.navTo("RouteAdminDashboard");
                } else {
                    oRouter.navTo("RouteUserDashboard");
                }

            } catch (error) {
                MessageToast.show(error.message || "Something went wrong. Please try again.");
            }
        }
    });
});

After logging in, we can check the token by clicking "inspect," then "application," then "session storage," and here we can see the generated token.

Step 9: Frontend — Making Secure API Calls from the Dashboard

Any time the dashboard needs protected data, it reads the token from sessionStorage and attaches it to the Authorization header. It also handles session expiry cleanly.

controller/Dashboard.controller.js:

sap.ui.define([
    "sap/ui/core/mvc/Controller",
    "sap/ui/model/json/JSONModel",
    "sap/m/MessageToast"
], function (Controller, JSONModel, MessageToast) {
    "use strict";

    return Controller.extend("ui5nodeapp.controller.Dashboard", {

        onInit: function () {
            this.loadSecureData();
        },

        loadSecureData: async function () {
            const token = sessionStorage.getItem("myAppToken");

            if (!token) {
                this._redirectToLogin("No active session. Please log in.");
                return;
            }

            try {
                const response = await fetch("/api/admin/getItemDetails", {
                    method:  "GET",
                    headers: {
                        "Accept":        "application/json",
                        "Authorization": "Bearer " + token
                    }
                });

                // 401 = token expired or tampered or missing token header
                if (response.status === 401 || response.status === 403) {
                    this._redirectToLogin("Your session has expired. Please log in again.");
                    return;
                }

                if (!response.ok) {
                    throw new Error("Failed to load data. Please try again.");
                }

                const data   = await response.json();
                const oModel = new JSONModel(data);
                this.getView().setModel(oModel, "secureData");

            } catch (error) {
                console.error("API error:", error);
                MessageToast.show(error.message);
            }
        },

        _redirectToLogin: function (message) {
            sessionStorage.removeItem("myAppToken");
            sessionStorage.removeItem("myAppUser");
            MessageToast.show(message);
            this.getOwnerComponent().getRouter().navTo("RouteLogin");
        },

        onLogout: function () {
            this._redirectToLogin("You have been logged out.");
        }
    });
});

A Few Things to Keep in Mind:

On sessionStorage vs localStorage: I chose sessionStorage because it clears automatically when the browser tab closes, reducing the exposure window on shared machines. Both are vulnerable to XSS attacks, so consider a content security policy header in production.

HTTPS is non-negotiable: JWTs in transit are meaningless without HTTPS. Local development over HTTP is fine, but before you deploy anywhere, put the app behind HTTPS.

Token expiry: The 24-hour expiry works for many internal tools. For anything more sensitive, tighten it to 1–2 hours and consider adding a refresh token mechanism.

Role checks on the backend too: The frontend role-based routing is purely a UX decision — it is not a security control. Always enforce role checks on the backend as well.

Conclusion:

That's the complete picture—from MySQL setup and real bcrypt password hashing through JWT generation and middleware protection on the backend to the UI5 frontend handling token storage, role-based routing, and secure API calls.

From Hype to Hands-On: Level Up Your AI Skills This May

2026-05-29T13:59:36.224000+02:00

In the age of AI, the skills we build today will define how we work tomorrow. That’s why we’ve launched a monthly blog series that spotlights the latest AI learning assets and upcoming learning opportunities.

Building on my first blog, where I introduced you to our AI live sessions Beyond Hype (which are all about getting productive with SAP Business AI), I wanted to address some of your most asked questions. But before I do that, I’m excited to share that the sessions are now ungated and no longer require a SAP Learning Hub subscription!

How does SAP ensure that frontier models can be trusted?
It’s a shared responsibility across SAP, the model vendor, and the customer, managed through a layered and continuous improvement approach:

SAP: Selects enterprise-grade vendors; conducts security and responsible AI reviews; integrates models behind SAP identity, authorization, logging, and data protection; applies guardrails; monitors behavior and coordinates fixes/updates.
Model vendor: Owns model quality and defects; contractually obligated to address safety issues and deliver improvements when identified by either party.
Customer: Configures authorizations and data access; defines permissible use cases and safety settings; participates in monitoring and feedback.

SAP cannot change a vendor’s model weights or eliminate all model-intrinsic limitations. Instead, SAP mitigates risk through configuration and guardrails, protects business data via SAP’s application security, monitors performance, and escalates issues to the vendor under defined contracts and SLAs. If needed, SAP can adjust configurations, deploy compensating controls, or replace/disable a model to protect customers.

Find more answers in the publicly available SAP Business AI - Responsible AI FAQ.

What are the most common security mistakes SAP customers make when implementing an AI?

For AI features embedded in existing business applications, the underlying system typically enforces data controls and authorization; the AI component itself doesn’t determine access, the host application does. When teams build custom AI applications, or add new components, they must implement the right authorization and access controls for those pieces. Overall, AI adoption is still experimental. While custom implementations vary widely by organization, one recurring theme is content moderation: Some teams keep it on, while others relax or disable it to support domain-specific use cases (for example, medical contexts). That configuration choice is worth highlighting. Beyond that, patterns are highly situational and we refrain from framing them as mistakes so much as considerations that differ by approach.

Watch AI Security – What is it about? And understand how SAP is developing, deploying, using, and selling AI systems with the highest ethical, security, and privacy standards.

Why should I use SAP AI Core for agent assisted coding?

AI Core uses a secure environment where the LLMs are hosted, and the data is not used for further training compared to public LLMs. To deliver consistent, secure, and compliant outcomes across your landscape, you can bring the AI coding environment of your choice (e.g. Claude Code or Cline).

You can learn more about agent assisted coding with Cline and AI Core in the SAP Architecture Center.

Agent‑assisted coding began as a developer aid to speed up prototyping, refactoring, test generation, and debugging. It has since evolved into a broader set of AI agents that translate natural language into software artifacts, connect design and code, scaffold data and infrastructure, and automate tedious workflows. This shift lowers the barrier to software creation and lets more roles contribute directly, effectively democratizing development by allowing anyone to create natural language prompts instead of traditional codes. These developments unlock a wide range of new use cases, enabling you to work more creatively and productively while creating higher-quality technical documentation.

One of these new use cases is spreadsheet automation, which is especially valuable for non-technical users. Imagine you are working with a set of marketing data spread across different channels. Instead of manually cleaning and analyzing it, you simply ask the system to help you create a structured spreadsheet with performance insights. What happens next is that the system automatically organizes your data and generates a clear Excel file. It can include multiple sheets such as campaign performance, channel performance, and daily trends. At the end, it also adds a short summary that highlights the key insights from your data. Behind the scenes, the system generates a custom Python script that processes your raw data and builds the Excel file automatically. The important part is that you don’t need to write any code or manually structure the spreadsheet, you can simply review the output and use it directly.

Another example comes from a product management use case, where you might want to build a new time tracking feature. You can start by asking the system to support you with competitive research. For example, you explore how existing tools like Asana and ClickUp handle time tracking and what features they offer. The system gathers and summarizes this information into a structured overview of competitors and their capabilities. From there, you can take the next step and ask it to generate a product requirements document (PRD). Instead of starting from a blank page, you receive a complete draft that includes goals, success metrics, and a clear breakdown of requirements such as “must-have”, “should-have”, and “nice-to-have” features, as well as non-functional requirements.

But it doesn’t stop there: As a product manager, you can go further and ask the system to break the PRD down into actionable work items. This means it can generate epics and tasks that you can directly use in your planning tools. As a result, you can review, adjust, and refine the output together with your team. Rather than manually compiling research, writing documents, and structuring tasks from scratch, you start from a strong, AI-generated foundation that accelerates your entire product development process.

Now it’s your turn! Try yourself with this sample scenario and use Cline to rapidly build enterprise-grade SAP CAP Application with Fiori UI.

Want to dive deeper into the content? Rewatch the session and access the session material:

All Things Business AI: Latest Insights, Updates & Live Demos (recording)
Build AI securely - Avoid Pitfalls in the Development and Operations Lifecycle (recording)
Agent Assisted Coding with AI Core (recording)

Hi Joule, where should I get started with the latest learning resources? *

Apart from live enablement sessions, explore our latest on-demand learning resources:

NEW! Driving SAP Joule for Consultants Adoption Learning Journey: Understand SAP Joule for Consultants value across the project lifecycle, enable consultant daily use, engage stakeholders, deploy SAP’s adoption asset library, and use usage data to optimize and demonstrate business impact.
NEW! Building Confidence in AI with SAP Learning Journey: Understand Responsible AI in SAP; how ethics, security, privacy, and compliance govern data, how SAP safeguards via policies and certifications, and how customers control usage and involve experts to drive trusted, confident adoption.
NEW! SAP's AI Golden Path: The SAP's AI Golden Path is the starting point for developing AI applications across the SAP ecosystem. It contains recommendations, best practices, and tutorials to help you understand the AI technology stack, identify suitable tools and services, and design, deliver, and extend enterprise-grade AI solutions on SAP technology.

* Powered by the machine learning technology of SAP AI Business Services, personalized recommendations are generated for employees, in one place on the Learning home page, based on employee data.

As we look ahead, we’re excited to share with you a new lineup of learning opportunities designed to help you expand your knowledge and make AI an advantage in your role:

June 18, 15:00 CET: All Things Business AI: Latest Insights, Updates & Live Demos. Discover current AI trends, recent updates across SAP’s AI portfolio, and see live demos showcasing how Business AI can drive efficiency and innovation in real-world business processes.
July 6-9: SAP AI Adoption & Learning Week. Get ready for a week of expert‑led sessions delivering fresh insights, practical strategies, and the latest innovations shaping the year ahead.

Stay tuned for more, and happy learning! 🚀

Further Resources:

SAP AI Core Security Artificial Intelligence Joule

Secure by Design: How SAP and NVIDIA Are Redefining Agent Execution

2026-06-01T07:50:00.019000+02:00

I am still reveling in the excitement of SAP Sapphire Orlando, May 11 to May 13, 2026. It started with the SAP keynote , highlighting our future direction. A personal moment of pride filled the screens around minute 42, when the CEO of NVIDIA Jensen Huang introduced how SAP and NVIDIA are making enterprise software more powerful and security.

On Wednesday, I hosted a strategy talk between Sebastian Mahr, Chief Development Architect, SAP SE and Shahriar Hooshmand, GenAI Technical Lead, NVIDIA. Today, I am sharing more details about their discussion for redefining agent execution. The AI first experience for building happens in Joule Studio and Joule Studio runtime with NVIDIA makes it easy to deploy and secure for enterprise scale.

AI agents are moving from conversation to action. They are beginning to execute tasks, invoke tools, cross system boundaries, and operate inside the business processes where decisions are made and value is created. For enterprises, this changes the trust equation. A chatbot can suggest; an agent can act. And once agents can engage with systems of record across finance, procurement, supply chain, manufacturing, and customer operations, the question becomes much sharper: how do we safely deploy autonomous AI? SAP and NVIDIA’s collaboration is designed to answer exactly that question. The SAP Business AI Platform uses the NVIDIA OpenShell secure runtime to make agents safe, governable, and auditable by design. Joule Studio acts as an "agent harness" that combines Large Language Model intelligence with business data and domain expertise.

Autonomy, Intelligence, and Security

Every enterprise agent sits in a tension between Autonomy, Intelligence, and Security. Highly autonomous agents can move fast, intelligent agents can reason through complex business contexts, and secure agents can operate within clear technical and business boundaries. In real-world enterprise environments, you cannot simply maximize all three at once. A loan-processing agent, a production-line response agent, and a strategic planning agent should not run with the same level of freedom, the same approval model, or the same risk posture. The more autonomous the agent, the more important it becomes to define what it can see, what it can do, who approves its actions, and how those actions are traced.

Responsibility and secure execution must become the layer around agentic enterprise AI. Security is about container isolation, credentials, networks, APIs and risk management for unauthorized spending, compliance violations, reputational damage, liability, and audit readiness. Enterprises need a way to choose the right balance for each workload:

Autonomous and secure for repeatable tasks,
Intelligent and secure for high-context work with human oversight, or
Autonomous and intelligent only in tightly controlled development and testing environments.

Responsibility defines who decides the operating mode, who bears the risk, and how the system adapts as the workload becomes more capable or more sensitive.

In Joule Studio runtime, NVIDIA OpenShell provides the secure runtime foundation for agent execution, including isolated environments, filesystem and network policy enforcement, and runtime-level containment to limit impact if agent logic fails. SAP brings the enterprise context: roles, skills, identity, lifecycle, policy semantics, observability, auditability, and governance across business landscapes. Put simply, OpenShell helps answer, “Can this agent action safely execute?” Joule Studio runtime helps answer, “Should this action happen at all?” Together, they close the gap between technical containment and business accountability.

The SAP and NVIDIA collaboration, which includes SAP as a key contributor to the NVIDIA OpenShell open source project, also reflects NVIDIA's broader full-stack view of AI. NVIDIA’s founder and CEO, Jensen Huang, has framed AI as a five-layer stack; energy, chips, infrastructure, models, and applications; the application layer is where AI creates value in real workflows. For SAP customers, that point matters. Enterprise AI becomes real when agents can operate inside the business applications, identities, policies, and audit models that companies already depend on. SAP and NVIDIA’s work on Joule Studio runtime is about making that next step practical: allowing agents to act, while staying within the boundaries enterprises require.

This week at Computex / GTC Taipei, NVIDIA is announcing new open source software and models to continue making it easier to build and deploy autonomous agents. And now, the next step is to put this into the hands of builders. SAP customers and partners building custom agents should engage with the new Joule Studio early access / Early Adopter Program to start shaping their own trusted agent execution model. Explore how SAP enterprise with OpenShell-based runtime security and governance powered by OpenShell can help you understand your security posture, define workload-specific risk profiles, and move from pilots to production with confidence. Autonomous enterprise is no longer only a vision. With SAP and NVIDIA working together on secure, responsible agent execution, it is beginning now.

Now is the time to get in line.

SAP SuccessFactors Cybersecurity Übersicht

2026-06-04T10:34:04.345000+02:00

SAP SuccessFactors Cybersecurity

SAP SuccessFactors gehört als Human Capital Management (HCM) Suite zu den sensibelsten Cloud-Anwendungen im SAP-Portfolio: SuccessFactors verarbeitet personenbezogene Mitarbeiterdaten, darunter Gehaltsabrechnungen, Leistungsbeurteilungen und Bewerbungsunterlagen. Datenkategorien, die unter den regulatorischen Schutz der Datenschutz-Grundverordnung (DSGVO) fallen.

Dieser Artikel möchte Ihnen einen Einblick in die Cybersecurity-Maßnahmen rund um SAP SuccessFactors geben. Folgende Themen greifen wir auf:

SAP SuccessFactors Cloud Security Konzept
Datensicherheit – Verschlüsselung, Trennung, Löschung von Daten
Anwendungssicherheit – Zugriffe, Protokolle, SuccessFactors Mobile App
Betriebssicherheit – Monitoring, Resilienz, Patch-Mgmnt, Business Continuity
Vertragliche Grundlage
Transparenz und Compliance – Zertifikate und Prüfberichte
Übergreifendes Cybersecurity Konzept für SAP Cloud Services

Cloud Security Konzept SAP SuccessFactors

SAP SuccessFactors ist eine Software as a Service (SaaS) Lösung. In diesem Cloud Modell liegt eine erhebliche Sicherheitsverantwortung beim Cloud Service Provider.

SAP verantwortet die Infrastruktur, einschließlich Bereitstellung der kundenspezifischen Instanzen. Dies umfasst auch die folgenden Leistungsmerkmale und Aufgaben:

Sichere Softwareentwicklung
Betriebsführung
Sicherung der Plattformarchitektur
24x7 Security Monitoring & Logging
Patch- und Bedrohungsmanagement
Pentests und Schwachstellentests
Resilienz und Hochverfügbarkeit
Business Continuity Management
Managed Backup and Restore
Incident and Change Management
24x7 Kunden Support
Prüfung und Einbindung von Unterauftragsverarbeitern
Security-Zertifikate und Prüfberichte
Dokumentierte Compliance der Cloud-Services

Bei SAP SuccessFactors verantwortet der Kunde die Konfiguration sowie die Benutzer- und Datenpflege in einer Instanz. Das umfasst auch die folgenden Aufgaben:

Einrichtung Benutzer
Einrichtung Identity Management
Definition und Zuweisung von Benutzerrollen und Benutzergruppen
Definition der Berechtigungen
Konfiguration der Geschäftsprozesse
Einrichtung und Aktivierung von Integrationen
Berücksichtigung von Compliance-Anforderungen
Security Audit Logging Verantwortung in der Instanz
Pflege der Daten
Fristgerechte Löschung von Daten

SAP klassifiziert alle Kundendaten in SAP SuccessFactors als vertraulich und wendet die im Datenverarbeitungsvertrag (SAP DPA) definierten Sicherheitsmaßnahmen (TOMs) an.

SAP SuccessFactors wird im Rahmen eines regionalen Bereitstellungsmodell angeboten. Die Rechenzentren für unsere europäischen Kunden befinden sich in der Europäischen Union, dem EWR oder der Schweiz. Dabei greift SAP auf eine Kombination aus eigenen Rechenzentren und Hyperscaler Infrastrukturen zurück.

Cloud Datensicherheit

Der Schutzbedarf der Daten in SAP SuccessFactors ist hoch. Personenbezogene Daten, darunter möglicherweise besondere Kategorien personenbezogener Daten gemäß Artikel 9, DSGVO, treten im Kontext mit unternehmensbezogenen Daten auf, die vertraulich und geschäftskritisch sein können, aber auch Konfigurationsdaten, die als sicherheitsrelevant eingestuft werden müssen, da Fehlkonfigurationen die Verarbeitung gefährden können.

Zum Schutz dieser Daten werden die folgenden Maßnahmen bereitgestellt.

Verschlüsslung gespeicherter Daten

SAP stellt Data-at-Rest-Verschlüsslung im Standard bereit. Wenn Daten abgelegt werden, dann werden sie auch verschlüsselt. Die Verschlüsselung erfolgt mittels AES 256 Standard. Für die Verwaltung der Schlüssel ist SAP verantwortlich.

Darüber hinaus bietet SAP für SAP SuccessFactors auch kundeneigene Verschlüsselung an d.h. Unternehmen und Organisationen, die Kontrolle über ihre kryptografischen Schlüssel benötigen, können den (aufpreispflichtigen) SAP Key Management Service (SAP KMS) nutzen. Dieser unterstützt drei Betriebsszenarien:

Customer Specific Encryption Keys (CSEK)
Bring Your Own Key (BYOK)
Hold Your Own Key (HYOK)

SAP KMS bietet FIPS-140-2-Konformität im Level 3, Funktionstrennung (Segregation of Duties), Master Key Management und die Protokollierung aller Schlüsselzugriffe.

Verschlüsslung übertragener Daten

Daten während der Übertragung (Data-in-Transit) werden mittels TLS 1.2 oder TLS 1.3. Protokoll und starken Chiffren verschlüsselt.

Beim Datenaustausch via OData API‘s wird zertifikatbasierte Authentifizierung unterstützt.

Dateiaustausche werden via SFTP geschützt. Der Schutz der Dateien kann durch eine Verschlüsselung auf Pretty Good Privacy (PGP) Basis noch ausgeweitet werden.

Datensicherung

SAP SuccessFactors stellt standardmäßig für alle Kundendatenbanksicherungen folgendes bereit:

Tägliche inkrementelle Sicherungen.
Wöchentliche vollständige Datenbanksicherungen.
Alle Sicherungen werden nach dem AES-256-Bit-Standard verschlüsselt.
Sicherungen werden sowohl im Produktivrechenzentrum als auch im Backuprechenzentrum des Kunden gespeichert.
Sicherungen werden 30 Tage lang gespeichert.
Produktionskunden können eine Wiederherstellung aus einer Sicherung über den Kundensupport anfordern.

SAP verfügt über einen formalen Systemsicherungsprozess und -zeitplan für die SAP-Cloud-Lösungen, der hardwareunabhängige Wiederherstellungs- und Wiederherstellungsfunktionen umfasst. Es sind geeignete Prozesse und automatisierte Tools vorhanden, um die Integrität der Sicherung zu validieren, und Sicherungsprotokolle werden täglich überprüft, um Sicherungsfehler zu erkennen und zu korrigieren.

Sichere Datentrennung

SuccessFactors läuft als Mehr-Mandanten-Anwendung mit logischer Datentrennung auf Datenbankebene. Die logische Trennung von kundenspezifischen Daten wird mittels HANA Datenbankschemen umgesetzt. Ein Kunde kann nur auf die Daten seines Unternehmens zugreifen.

Datenlöschung

Die Einhaltung von Löschfristen wird durch das Datenaufbewahrungsmanagement in SAP SuccessFactors gesteuert. Hier können maßgeschneiderte Löschkonzepte abgebildet werden, orientiert an relevanten Zeitpunkten und abgestimmt auf die relevante Datenkategorie z.B. Daten der Bewerbenden sowie auf das betroffene Land, in dem die Löschregel zum Einsatz kommt.

Basierend auf diesen Regeln, können wiederkehrende Löschläufe durch den Kunden eingeplant werden. Sobald die erfolgreiche Prüfung der Ergebnisse vorliegt, kann eine Freigabe erfolgen und die Löschung durchgeführt werden.

Nach Vertragsende werden SAP SuccessFactors Daten durch SAP gemäß den vereinbarten Prozessen und den geltenden Datenschutzvorgaben sicher gelöscht. Der Datenlöschungsprozess wird automatisch ausgelöst, sobald ein Vertrag endet oder gekündigt wird. Die vollständige Löschung der Daten erfolgt nach Validierung und Ablauf von Kulanzfristen. Die sichere Entfernung und Vernichtung von Datenträgern ist Bestandteil der SAP-Standards und wird durch Audits überprüft.

Cloud Anwendungssicherheit

Identitätsmanagement

SAP SuccessFactors wird mit dem SAP Identity Management Services bereitgestellt. Diese bieten Authentifizierung über Industriestandards wie SAML 2.0 und unterstützen Single Sign-On sowie die Delegation an unternehmenseigene Identity Provider wie Azure Active Directory.

Benutzeridentitäten zwischen Quell- und Zielsystemen können auf Basis des SCIM-Standards synchronisiert werden.

SAP SuccessFactors unterstützt zudem die zertifikatsbasierte Authentifizierung für die sichere API-Kommunikation.

Zugriffssteuerung

Die Zugriffssteuerung von SAP SuccessFactors basiert auf rollenbasierten Berechtigungen, einem granularen, rollenbasierten Zugriffssteuerungssystem. Zugriffsrechte sind granular, werden auf Feld-, Datensatz- und Funktionsebene definiert und werden Benutzern, Rollen oder Gruppen zugewiesen.

Sichere Softwareentwicklung

SAP entwickelt SAP SuccessFactors nach dem Secure Software Development and Operations Lifecycle, der risikobasierte Sicherheitsanforderungen in jede Entwicklungsphase integriert.

Security Gates, Threat Modeling sowie Statische (SAST) und dynamische (DAST) Sicherheitsanalysen sind nur einige Elemente dieses umfassenden Vorgehens bei der Entwicklung.

Audit Trails und Protokolle

SAP SuccessFactors bietet Kunden Zugang zu Application Security Audit Logs auf Anwendungsebene, darunter befinden sich u.a. der General Audit Bericht, die Änderungsverfolgung (Change Audit), Kontrollierte Einsicht (Read Access) für sensible Daten. Sicherheitsprotokolle auf Ebene der SAP SuccessFactors Instanz können in ein kundeneigenes SIEM-System überführt werden.

Darüber hinaus existieren spezialisierte Audit-Funktionen wie Audit Trails im Recruiting und in Performance & Goals, wesentlich für die Nachvollziehbarkeit von Personalentscheidungen.

SAP SuccessFactors Mobile App

Die SAP SuccessFactors Mobile App wird für iOS und Android Betriebssysteme bereitgestellt. Die Installation ist auf unternehmenseigenen und privaten Endgeräten möglich.

Die Authentifizierung bei Zugriffen durch die Mobile App erfolgt mittels OAuth Token. Die App kann mittels Passwortes oder gerätespezifischer Möglichkeiten (Fingerabdruck, Gesichtsscan) vor unberechtigtem Zugriff geschützt werden.

Unabhängig vom Endgerät sind die Berechtigungen der Nutzenden auf der SAP SuccessFactors Mobile App: Basis sind die im System hinterlegten Berechtigungen.

Alle Datenübertragungen sind verschlüsselt, wenn es zu einer Ablage von Daten auf der App kommt, so sind auch diese verschlüsselt.

Die SAP SuccessFactors Applikation für Mobilgeräte unterstützt die marktführenden Mobile Device Management (MDM) Systeme.

Cloud Betriebssicherheit

Netzwerksicherheit

SAP hat eine mehrstufige Netzwerk-Architektur implementiert, die Zero-Trust-Prinzipien folgt und eine Strategie der "Tiefenverteidigung“ nutzt. Der Netzwerkverkehr wird kontinuierlich durch ein Intrusion Prevention System (NIPS) überwacht und protokolliert.

SAP unterhält intern eine strikte Zugriffssteuerungsrichtlinie, die einen rollenbasierten Zugriff auf alle Ressourcen (Anwendungen, Betriebssysteme, Netzwerkgeräte usw.) fordert sowie eine eindeutige ID für alle Personen. Berechtigungen werden nach den Segregation-of-Duties und Need-to-Know Prinzipien vergeben.

Die Sicherheit des SAP-Netzwerks einschließlich der SAP-Endbenutzerausrüstung wird zusätzlich durch Lösungen wie Netzwerkzugangssteuerung, Netzwerkfilterung, starke Authentifizierung, Internet-Inhaltsfilterung und Antiviren-Scanner gewährleistet.

Monitoring

SAP betreibt ein 24/7 Security Monitoring für die SAP SuccessFactors-Plattform. Sicherheitsereignisse werden zentral in einem SIEM System korreliert; bei verdächtigen oder bösartigen Aktivitäten werden automatische Alerts und Security Incident Tickets erzeugt.

Die Nachverfolgung von Tickets durch die Mitarbeitenden im Operations-Team folgt dem SAP Security Incident Management Prozess, die Tätigkeiten werden dokumentiert und sind revisionsfähig.

Logging

Alle relevanten technischen Infrastruktur-Komponenten die den Betrieb des SAP SuccessFactors Service unterstützen, sind an ein SIEM System angeschlossen. Die dort protokollierten Daten umfassen auch alle Login-Versuche um ggf. forensische Untersuchungen zu unterstützen.

Resiliente Plattformarchitektur

SAP stellt für SAP SuccessFactors eine Multi-Availability-Zone-Architektur bereit. Diese wird jeweils ergänzt durch ein Sekundär-Rechenzentrum um eine zeitnahe Widerherstellung des Services bei einem Rechenzentrumsausfall zu gewährleisten.

Business Continuity Management

SAP SuccessFactors ist nach ISO 22301 zertifiziert (Business Continuity Management System).

SAP SuccessFactors sichert die Daten seiner Auftraggeber kontinuierlich und hält diese über einen Zeitraum von 30 Tagen zur Verfügung. Eine Kopie der Datensicherung befindet sich jederzeit in dem vorgesehenen BackUp Rechenzentrum.

Es werden jährliche Disaster Recovery Tests durchgeführt, der zu Grunde liegende Disaster Recovery Plan wird regelmäßig geprüft und aktualisiert.

Vulnerability Management und Penetration Testing

SAP führt regelmäßige Schwachstellenanalysen (Vulnerability Scans) und Penetrationstests durch und stellt diese seinen Kunden auf Nachfrage zur Verfügung. Kunden können, in Abstimmung mit SAP, eigene Penetrationstests durchführen.

Patch- und Change-Management

SAP verwaltet das Patching der SAP SuccessFactors-Plattform, einschließlich Sicherheits-Patches für Betriebssysteme, Datenbank, Middleware und Anwendungsschicht.

Bei der Priorisierung von Schwachstellen orientiert sich SAP am Common Vulnerability Scoring System (CVSS).

Vertragliche Grundlage

Die SAP SuccessFactors Vertragsgrundlage umfasst folgende Dokumente:

Vertragsbestandteil	Inhalt
Order Form	Kunde & SAP (Kontaktdaten, Leistungsumfang, Beginn & Ende…)
AGB’s	Nutzungsrechte, SAP Verantwortlichkeiten und Pflichten, Vergütung, Gewährleistung, Vertraulichkeit, Kündigung…
Ergänzende Bedingungen	Nutzungsmetriken, zusätzl. Bedingungen, Disaster Recovery…
Support Schedule	Kontaktkanäle, Sprachen, Prioritäten und Reaktionszeiten
Service Level Agreement	Systemverfügbarkeit, Wartungsfenster, Gutschriften
Auftragsverarbeitungs-vertrag	Sicherheit Verarbeitung, Leistungspflichten SAP, Zertifizierung und Audits, Unterauftragsverarbeiter…
Sicherheitsmaßnahmen (TOM´s)	Governance der Informationssicherheit, Sicherheits-zertifizierungen und -bescheinigungen, Organisatorische, physische und technische Sicherheitsmaßnahmen, Resilienz, Umgang mit Sicherheitsvorfällen…

Transparenz und Compliance

SAP SuccessFactors unterliegt regelmäßigen, unabhängigen Audits und hält eine Vielzahl von anerkannten Zertifikaten und Prüfberichte bereit. Darunter befinden sich:

Zertifikat, Prüfbericht	Inhalt
ISO 27001	Informationssicherheits-Managementsystem
ISO 27017	Schutz personenbezogener Daten in der Cloud
ISO 27018	Sicherheitsmaßnahmen für Cloud‑Dienste
ISO 22301	Business Continuity Managementsystem
BS 10012	Datenschutz-Managementsystem
EU Cloud Code of Conduct	Genehmigte Verhaltensregeln, Artikel 41/42 DSGVO
ISAE 3000 BSI C5 Type II	Prüfbericht Sicherheitsmaßnahmen gem. BSI
ISAE 3402 SOC 1 Type II	Prüfbericht interne Kontrollen
ISAE 3000 SOC 2 Type II	Prüfbericht Sicherheitsmaßnahmen

Aktuelle Zertifikate und Prüfberichte können im SAP Trust Center eingesehen oder beantragt werden: Alle Zertifikate Auditberichte SF

Übergreifendes Cybersecurity Konzept für SAP Cloud Services

Alle vorgestellten Sicherheitsmaßnahmen betten sich in die übergeordneten, konzernweiten Maßnahmen der SAP ein, beschrieben durch das SAP Security Policy Framework und durchgesetzt mit dem NIST Cyber Security Framework.

SAP Security Policy Framework

Die SAP Global Security Policy ist das übergeordnete Dokument, das die Management-Intention, Erwartungen und strategische Ausrichtung festlegt. Es definiert die strategischen Ziele und Vorgaben für ein höchstmögliches Sicherheitsniveau bei der Bereitstellung von SAP Cloud Services.

Konkret dient es als Leitfaden, der mit anerkannten Standards, klaren Sicherheitsregeln und Best Practices die Grundlage für Planung, Entwicklung, Konfiguration und Betrieb von SAP Cloud Lösungen darstellt.

Das Ziel: Einen einheitlichen, hohen Sicherheitsstandard über alle SAP Cloud Services zu gewährleisten!

Secure Data, Applications, and Data Centers | SAP Security

Einsatz des NIST Cyber Security Frameworks

SAP hat erfolgreich das NIST Cyber Security Framework (NIST CSF) implementiert und den Tier 3 Reifegrad erreicht.

In einer sich kontinuierlich wandelnden Bedrohungslandschaft bietet das NIST Cybersecurity Framework (CSF) eine effektive und strukturierte Grundlage, um Sicherheits-Maßnahmen flexibel anzupassen und kontinuierlich weiterzuentwickeln. Es unterstützt uns dabei, neue Risiken systematisch zu identifizieren, zu bewerten und geeignete Schutzmaßnahmen gezielt an sich verändernde Anforderungen und Bedrohungen auszurichten.

SAP Security Policy Framework und NIST Cyber Security Framework ergänzen sich, stellen in ihrer Verbindung sicher, das alle Sicherheits-Vorgaben im Rahmen eines aktiven Risiko-Managements kontinuierlich geprüft und gegebenenfalls angepasst werden.

Das Erreichen von NIST CSF Tier 3 soll nicht nur das Vertrauen in unsere Produkte und Dienstleistungen stärken, sondern auch unser Engagement, Kunden zu schützen sowie Prozesse und Daten dauerhaft wirksam abzusichern.

How SAP is safeguarding its customers: Implementing the NIST Cybersecurity Framework achieving Tier 3 alignment

Fazit

SAP SuccessFactors steht aufgrund der Sensitivität von HR-Daten im Brennpunkt regulatorischer und sicherheitstechnischer Anforderungen.

SAP verfolgt einen durchgängigen Sicherheitsansatz, vom Shared-Responsibility-Modell mit klarer Verantwortungstrennung zwischen SAP und Kunde, über Datenverschlüsselung, granulare rollenbasierte Berechtigungen, nativ integrierte SAP Identity Management Services, bis hin zu 24x7-Security-Monitoring, Cyber Threat Intelligence und umfassender Audit- und Compliance-Berichte.

Die Wirksamkeit dieses Sicherheitsmodells hängt jedoch auch von der aktiven Mitwirkung des Kunden ab -- insbesondere bei der Konfiguration von Berechtigungen, beim Identity Management, Datenschutzeinstellungen und der regelmäßigen Überprüfung von Security Audit Logs.

Erfahren Sie mehr zu Sicherheit mit SAP für Daten, Anwendungen und Rechenzentren

Understanding Security in SAP Joule’s Runtime

2026-06-09T12:32:18.641000+02:00

Every time you ask Joule a question, your request passes through multiple layers of security, each one independently verifying, isolating, and constraining what happens. Here's what that journey looks like from the inside

Every Joule request flow through two core runtime layers: the Orchestration Runtime, where scenarios are resolved and reasoning happens, and the Execution Runtime, where Joule Functions run. The sections below trace your request through these layers, and the security controls that travel with it.

1. At the Front Door - Proving Who You Are

The moment you interact with Joule; your identity is verified through OAuth2 via SAP Identity Authentication Service. A signed token is issued, and this isn't a one-time check. Every single service in Joule's pipeline independently re-validates that token.

Layer: Runtime Entry

2. Everywhere - Controls That Follow Your Request Across All Layers

Some security controls aren't tied to a single layer; they're enforced uniformly at every boundary your request crosses.

Your identity is re-verified at every hop. All inter-service communication uses mutual TLS (mTLS), both sides of every connection prove their identity. There is no "trusted internal zone." Whether your request is at the runtime entry, orchestration, or execution layer, the service handling it independently validates your authentication token and the calling service's certificate. This creates a zero-trust internal mesh.

Your data is isolated from every other customer's. Each tenant's data lives in its own isolated database schema, Joule cannot query across tenant boundaries. Conversation identifiers are cryptographically derived, making them impossible to guess or enumerate. Your conversations, context, and business data are unreachable by any other customer on the platform.

Applies to: All layers

3. Routing Your Request - Only What You're Allowed to Invoke

Once authenticated, your request reaches Joule's orchestration layer. Before any AI processing begins, your available scenarios are filtered.

Joule supports role-based access to AI scenarios, capability developers define visibility conditions that restrict which scenarios are available to which users. These conditions can be based on navigation authorizations or identity attributes from the user's authentication token. A finance analyst and a warehouse manager see different Joule scenarios, enforced server-side, not by hiding UI elements.

Layer: Orchestration Runtime

4. Safer Conversations - Filtering Harmful Content

Joule's reasoning runs through large language models accessed via SAP's centralised AI orchestration platform. That platform brings a content-safety layer with it, and Joule turns it on by default.

The filter screens AI inputs and outputs for harmful content and operates on both sides of the model:

- Before your message reaches the LLM, the input is checked.

- Before any model-generated text returns to you, the output is checked.

The platform attaches the filter automatically when an AI call is made. Capability developers don't have to remember to switch it on; safety is the default path.

By consolidating on a centrally managed safety service rather than per-team guardrails, Joule benefits from continuous improvements to the underlying classifiers without every capability needing to change its own code.

Layer: Orchestration Runtime

5. Taking Action - The AI Can't Run Wild

When Joule resolves your request into a backend action such as querying an SAP system, updating a record, running a calculation, etc. that action executes inside a hardened sandbox:

- Expression sandbox: only pre-approved operations can execute. Arbitrary code is structurally impossible; the sandbox uses a strict allowlist of permitted types and methods.

- Template engine: scripting is limited to template logic, not general-purpose computation. The engine evaluates structure, never executes code.

- Resource governors: execution timeouts, response size caps, and iteration limits prevent any single action from consuming unbounded resources.

Even in an adversarial scenario, the execution environment constrains what can physically happen, code execution and resource exhaustion are architecturally prevented.

Layer: Execution Runtime

6. Reaching Backend Systems - Only Where You've Approved, Only What You Can See

Joule doesn't have open network access. All outbound connectivity is routed through a fixed, admin-configured allowlist of approved hosts. Combined with IP-range blocking, this means:

- Joule can only communicate with systems your organisation has explicitly permitted

- No AI-generated URL or parameter can redirect connectivity to an unapproved host

When Joule does reach a backend system, it acts “as you”, not as a privileged service account.

Backend calls use principal propagation, meaning your existing authorization rules are enforced by the backend itself. If you can't access a purchase order in SAP directly, you can't access it through Joule either.

Your administrators control the network boundary. Your backend controls the data boundary. Joule inherits both.

Layer: Execution Runtime

7. The Response - Secure All the Way Back

The response travels back through the same authenticated, encrypted service mesh. Every hop is mTLS-protected, every service re-validates the request context, and tenant isolation ensures your response data never intermingles with another customer's pipeline.

Security by Architecture, Not by Afterthought

Joule wasn't secured after the fact - security is built into how requests flow through the system. Identity is verified at every boundary. Data is isolated at the infrastructure level. Code execution is sandboxed by design. Network access is bounded by admin policy.

The result: an enterprise AI assistant where security isn't a layer on top, it's the architecture itself.

Check and then Re-Check Your Cloud Foundry Org and Spaces for Correct User Assignments

2026-06-25T07:38:01.950000+02:00

Summary: A user can have zero access to SAP BTP Global and SubAccount and still be able to create, read, edit, or delete every service key in BTP! All you need is access at the Cloud Foundry level. Your landscape can be compromised leading to data privacy issues and business continuity can be disrupted significantly. Read more to find out how.

Most of the organizations use SAP BTP Integration Suite to connect systems across their landscape. A standard pattern is exposing HTTP endpoints (or other inbound endpoints) to third party systems so they can trigger integration flows.

To authenticate against those endpoints, you create service keys on the Process Integration Runtime service instance (integration-flow). These are basically API credentials in a way which we call Service keys (the other API credentials are available in the API Management - Developer Hub) and they live at the Cloud Foundry space tied to the service instance. Anyone with those credentials can call your integration endpoints directly and send or read data.

BTP admins generally manage user access carefully at SubAccount and Global Account level but generally find it too taxing to manage carefully at Cloud Foundry org and space level. When offboarding someone, most admins remove the user from the SubAccount and Global Account either manually or using IAS and then stop there. If that person still has any kind of CF access, they retain full access to every service key -- and they don't need the BTP cockpit to use it. In fact they won't have access to these using the BTP Cockpit. All they need is CF CLI or CF API to access these. The CF CLI and CF API are available to anyone on the internet for download, and a few commands is all it takes to create, read or delete any service key in the BTP environment.

I have found this security hole at many customers I am working with. The team has removed the user from the SubAccount but the user is still active in Cloud Foundry with no one having bothered to remove them from there thinking that removing them from SubAccount using IAS is enough. It is not! Even if you remove someone through IAS you must separately ensure they are fully removed from CF membership, not just their roles.

Concrete Example: say Target orders flow into S/4HANA via Integration Suite secured by service keys. A disgruntled ex-employee with no BTP cockpit access but still active in CF can delete every one of those keys. Integrations go down, orders stop getting received, and the business stops!

SAP does offer a connector to automate CF user and role management via SAP IPS (Identity Provisioning Service): https://community.sap.com/t5/technology-blog-posts-by-sap/streamlining-user-management-integrating-sap-integration-suite-with-sap/ba-p/14069705

If you have used, please comment and share you experience especially on how easy it is to use it.

A Big thanks to the SAP BTP xID tool because of which I was able to find this issue.

In the meanwhile I urge all SAP BTP Administrators to check their CF Orgs and Spaces for any assigned users who should not be there.

Update: Possibly, the following security standards get violated when you just rely on controlling S user lifetime to control access to the API and Service Keys.

1. ISO/IEC 27001:2022 (Information Security Management) - Control A.5.15 (Access Control): Requires access to assets to be restricted based on business and security requirements.

2. NIST SP 800-53 (Security and Privacy Controls) - AC-2 (Account Management)

3. PCI DSS 4.0 (Payment Card Industry Data Security Standard) - Requirement 8.6: Strictly regulates the use of application accounts

4. SOC 2 Type II (Trust Services Criteria) - Logical Access Controls (CC6.1/CC6.2): Internal controls must prevent unauthorized logical access to data.

5. Sarbanes-Oxley (SOX) Section 404 (Internal Controls) Compliance - Section 404 mandates that management and auditors establish, maintain, and regularly assess the effectiveness of internal controls over financial reporting to prevent fraud and data tampering. Financial data generally passes through these integrations on a regular basis. If the keys are freely accessible, it is possible, that a rogue internal or external actor can tamper with integrations, run them with incorrect data with no way to find out later who did it.

My recommendation: I would recommend that apart from one nominated administrator, nobody else should have access to the Production SAP BTP Cloud Foundry Environment in normal course of business. The access should be given to the CF environment only as temporary firefighter access same as is today done in SAP ERP or S/4HANA Production systems. Developers generally do not have unhindered access in these systems, most of the time not even read only access. The same concept needs to be applied to SAP BTP production environments also. This needs to be matured as part of SAP BTP Governance setup.

Enhancing the Support for RISE on AWS & GCP - LogServ with Sentinel for SAP Part 5

2026-06-26T16:23:26.302000+02:00

Find your way to our central blog series entry here.

Co-authored by Martin Pankraz (SAP Security PM, Microsoft) & @krishnarajapantula

Dear community,

The wait is over. Finally, RISE on AWS, RISE on GCP and customers on any platform can be protected with Microsoft Sentinel Solution for SAP with SAP LogServ. How is that different from RISE on Azure, you are asking?

Well, Azure customers have a native LogServ data pipeline with turn-on experience where SAP does the heavy lifting for you. Customers in other hyperscalers’ can still profit from Microsoft Sentinel for SAP integration using the python-based log forwarder provided by SAP ECS. It has a dedicated Microsoft Sentinel for SAP module.

Architecture Overview with RISE on AWS sample

Architecture Overview with RISE on GCP sample

How to integrate SAP LogServ with Microsoft Sentinel for SAP

SAP RISE customers who subscribed to LogServ, should install SAP LogServ (RISE), S/4 HANA Cloud Private Edition from Microsoft Sentinel Content Hub. Use the Data Connectors screen to deploy the connector – either from classic Azure Portal or the new view on the Defender Portal.
1. The connector deployment tries to create all resources in one go. Among them a Microsoft Entra ID app registration. In case the user doing the deployment has not enough rights, this process needs to be split up. Click the button anyways, which finalizes the creation of the Data Collection Endpoint and Data Collection Rule in the same resource group as your Log Analytics Workspace.
2. Take note of the fields generated. They will be required for the log forwarder config.
3. If needed, in a second step create your app registration, supply a secret, and assign that Entra ID app id to the Data Collection rule with the role "Monitoring Metrics Publisher".

2. Once installed the customer should reach out to their:

ECS CDM or ECS TSM to share log forwarder onboarding details. CDM and TSM's can find Sentinel onboarding steps in LogServ SAP internal wiki.
Put sap-logserv-sentinel-integration@service.microsoft.com in cc
Use the subject line: "SAP LogServ and Microsoft Sentinel - Activation" Please include your SAP RISE customer details in the email.

3. Request virtual network peering (AWS VPC, GCP VPC peering) if not yet deployed

4. Retrieve the LogServ connection details from the self-service section of the SAP ECS Security Portal.

5. Deploy the log forwarder provided by SAP:

Deploy a virtual machine with line of sight to the LogServ assets and access to the peered private network.
Install the python-based SAP ECS Logforwarder.
Configure the log forwarder with the config details collected from ECS Security Portal. Use the Sentinel configuration section together with the values noted down in step 1a.

6. Use the SAP LogServ Insights workbook to verify successful log data ingest.

What next?

See the blog series for an architecture overview, and log type details.
Understand the agentless data connector for the application layer from this Microsoft Learn article.

Get Started Today

Don't miss this opportunity to enhance your security posture with the powerful combination of SAP LogServ and Microsoft Sentinel Solution for SAP. Activate today and be among the first to experience the benefits.

We look forward to your participation and to helping you incorporate your SAP RISE environments into your overall IT estate.

Check blog part 2 to cherry pick the log types you need from LogServ for real-time threat protection and which ones should go into cost-efficient long-term storage on the Sentinel Data Lake, part 3 to craft your own detections, part 4 to understand the monitoring.

And finally, part 1 of the series to discover the analytic rules for the application layer powering Microsoft’s correlation engine.

Final Words

That’s a wrap🌯. You saw today how to onboard your SAP LogServ instance running RISE on AWS or GCP to Microsoft Sentinel for SAP. The approach is applicable to all other SAP ECS supported environments. You understand the difference to RISE on Azure deployments integrated with Microsoft Sentinel for SAP. Otherwise, go check again the intro paragraph.

Get started with your deployment today. See the art-of-the-possible for the agentic SOC on this video.

Which detections or analytic rules for RISE do you need most? Let me know in the comments or reach out directly.

Cheers Hemanth & Martin

How to Scan Custom ABAP for Security Issues in Eclipse (Step-by-Step)

2026-07-03T10:20:40.741000+02:00

Disclosure: I work on this tool at RedRays. This post is a straightforward setup guide, not a product pitch.

This post walks through connecting Eclipse to a static analysis backend that scans custom ABAP for common security issues (SQL injection, missing authorization checks, hard-coded credentials, weak crypto, and similar) and returns findings directly in the IDE.

Prerequisites

- Eclipse 2024-09 or newer
- SAP ABAP Development Tools (ADT) installed
- Java 17
- Network access to the backend you plan to scan against (in this walkthrough, a demo instance)

Step 1: Get an API key

The plugin needs an API key to authenticate against a scan backend. For testing, there's a self-service demo instance:

1. Open get.abap-security.com.
2. Enter a name and email address.
3. Click Create my Eclipse API key.
4. Copy the key immediately - it is displayed once.

Notes on the demo instance:
- Limited to one key per IP address per time window.
- It is a shared instance - do not submit confidential or production code to it. For real use, point the plugin at your own tenant or an on-premise instance instead (see "Beyond the demo" below).

Step 2: Install the plugin

In Eclipse:

1. Help → Install New Software…
2. Click Add… and enter the update site: plugin.abap-security.com
3. Select RedRays ABAP Scanner from the list.
4. Finish the wizard and restart Eclipse when prompted.

Step 3: Configure the connection

1. Window → Preferences → RedRays Scanner
2. Set Working mode to RedRays.
3. Set RedRays URL to https://demo.abap-security.com:8443/ (or your own instance's URL).
4. Paste the API key from Step 1 into RedRays API key.
5. Click Test connection and confirm it succeeds before continuing.

Step 4: Run a scan

1. Right-click any ABAP object in the Project Explorer.
2. Select Scan with RedRays.
3. Choose the Quick scan profile for a first run.
4. Findings appear in a dedicated Eclipse view as the scan completes.

Reading the results

- Findings are grouped by severity: Critical, High, Medium, Low.
- Double-clicking a finding opens the source at the exact line.
- Each finding includes a CVSS score and an automated exploitability check, intended to reduce false positives that would otherwise need manual triage.

Categories currently covered include: SQL/ADBC injection, OS command execution, dynamic WHERE/ORDER BY clauses, path traversal on OPEN DATASET, RFC trust issues, missing AUTHORITY-CHECK, hard-coded credentials, and weak cryptographic algorithms (MD5/SHA-1), among others.

Beyond the demo

The same plugin can point at a privately provisioned tenant or an on-premise instance instead of the shared demo, with isolated access per subaccount and no source retention (code is scanned in memory and discarded; only findings are stored). There is also a REST API for scanning from CI/CD, including an endpoint that returns an allow/block decision for a transport based on a severity threshold - useful as a pre-import gate.

Resources

- Plugin overview: redrays.io/abap-scanner-eclipse-plugin
- Demo / API key: get.abap-security.com

Q2 2026: Quarterly Release Highlights for SAP BTP Security and Identity & Access Management

2026-07-10T10:32:22.335000+02:00

The world of security never stands still, and neither do we. Here's a quick look at the latest SAP BTP Security and Identity & Access Management updates from this quarter, with the features and improvements worth adding to your radar.

For a complete overview of feature deliveries for SAP Cloud Identity Services, check out our list of all new feature announcements in the SAP Cloud Identity Services Release Notes on the SAP Help Portal.

SAP Cloud Identity Services: Technical users

SAP Cloud Identity Services now supports technical users—a new user type designed for non-human identities that enable secure, automated system-to-system communication and integrations. Technical users are managed separately from regular users through the new Technical Users tile under Users & Authorizations in the administration console, making it easier to create, organize, and maintain service identities. For step-by-step instructions, see Managing Technical Users.

SAP Cloud Identity Services: Block and delete users

Keeping your Identity Directory clean has just become easier. You can configure SAP Cloud Identity Services to automatically delete users who were created but never signed in to an application, helping reduce inactive accounts and simplify user lifecycle management. We’ve extended this functionality by adding a grace period. For configuration details, check Block or Delete Users Due to Inactivity.

SAP Cloud Identity Services: Automatic creation of Identity Provisioning tenants on SAP Cloud Identity for Neo tenants

Starting June 10, 2026, SAP automatically creates a new Identity Provisioning tenant on the SAP Cloud Identity infrastructure for every existing Identity Provisioning tenant running on the Neo environment that is linked to a shared IAM tenant with Identity Authentication.

This automatic provisioning gives you access to the latest Identity Provisioning capabilities and configuration options available on the SAP Cloud Identity infrastructure—features that are not supported on Neo. The newly created tenant is used for integrations related to bundled SAP cloud solutions, helping prepare your landscape for future enhancements. For migration details, see Migrate Identity Provisioning Bundle Tenant.

SAP Secure Login Service for SAP GUI: Now available in China

Organizations in China can now subscribe to the SAP Secure Login Service for SAP GUI and run the service on infrastructure located within China. This availability helps customers meet local deployment requirements while modernizing authentication for SAP GUI. They will be able to simplify integration by connecting more easily with enterprise identity providers, and strengthen security with enhanced support for multifactor authentication (MFA).

You can see the supported data centers here. For more information on the SAP Secure Login Service for SAP GUI, check the SAP Help Portal.

Application Vulnerability Report for SAP BTP

In December 2025, SAP introduced the Application Vulnerability Report (beta) for SAP BTP, providing an API-driven way to identify open-source vulnerabilities in your Cloud Foundry applications.

The service has now been enhanced with its first graphical user interface, available directly in the SAP BTP Cockpit. The new interface features an intuitive findings dashboard with a severity breakdown, along with a detailed findings view that provides actionable remediation guidance to help you address identified vulnerabilities.

The Application Vulnerability Report is currently available as a beta service in the EU10 region. While subscriptions are not yet available in other SAP BTP landscapes, the service's scanning scope has been expanded significantly. It now scans applications deployed across 42 Cloud Foundry landscapes worldwide, including regions in the United States, Asia Pacific, Japan, Brazil, and additional European landscapes beyond the original EU10 region.

Stay in the loop

Join the SAP BTP Security and SAP Cloud Identity Services communities to get updates, share feedback, and connect with others!

Bridging SAP Authorization Models & Databricks : An Architecture Pattern for Security Migration

2026-07-20T13:15:40.749000+02:00

Introduction

As organizations modernize their analytics platforms, migrating business data from SAP to modern Lakehouse architectures has become increasingly common. However, one critical aspect is often overlooked—security migration.

SAP's authorization model is built upon roles, authorization objects, organizational restrictions, and user-role assignments that collectively determine access to business data. Simply migrating the underlying data without preserving these access controls can lead to governance and compliance challenges.

Rather than directly exposing SAP security tables to downstream platforms, this article proposes a CDS View-based Security Semantic Layer that standardizes authorization metadata and provides a reusable foundation for enterprise security modernization initiatives.

In this article, we will explore the core SAP security tables involved in authorization management, design reusable CDS Views for metadata extraction, and architect a unified Security Semantic Layer for downstream consumers.

Figure 1: High-Level Security Metadata Extraction Architecture

High-Level Security Metadata Extraction Architecture

Understanding SAP Authorization Metadata

SAP's authorization framework is built upon multiple layers of security metadata that collectively determine a user's access to business data. Unlike traditional role-based access control models, SAP combines user-role assignments, authorization objects, authorization values, and organizational restrictions to enforce security policies.

At a high level, the authorization flow can be represented as follows:

Figure 2: SAP Authorization Metadata Flow

SAP Authorization Metadata Flow

The core SAP security tables involved in authorization management are:

SAP Table	Purpose
AGR_DEFINE	Stores role definitions and metadata
AGR_USERS	Stores user-to-role assignments
AGR_1251	Stores authorization objects, fields, and values
TOBJ	Stores authorization object metadata

Each table plays a specific role in defining who can access business data and under what conditions.

AGR_DEFINE acts as the role master table and contains information about SAP roles.
AGR_USERS maps SAP users to their assigned roles.
AGR_1251 contains the actual authorization rules, including authorization objects, field values, and organizational restrictions.
TOBJ provides semantic information about authorization objects used throughout the SAP authorization framework.

Together, these tables provide all the metadata required to design a reusable Security Semantic Layer for downstream analytics and governance platforms.

Why Only These Tables?

For most authorization migration and metadata extraction initiatives, these four tables provide the minimum and sufficient set of security metadata required to represent:

Role Definitions
User-to-Role Assignments
Authorization Rules
Organizational Restrictions
Authorization Object Metadata

By standardizing the information contained within these tables, organizations can create a business-friendly representation of SAP's authorization model without directly exposing low-level SAP security structures to downstream consumers.

Designing CDS Views for Security Extraction

Directly exposing SAP authorization tables to downstream platforms may appear to be the simplest approach for security migration. However, tightly coupling external consumers to SAP's underlying security tables introduces maintainability and extensibility challenges.

A better approach is to introduce a reusable Security Semantic Layer using CDS Views that abstracts SAP's authorization model into business-friendly entities.

Why CDS Views?

CDS Views provide several advantages when designing authorization extraction frameworks:

Semantic abstraction of SAP security metadata.
Centralized authorization metadata management.
Improved maintainability and extensibility.
Reduced dependency on underlying SAP table structures.
Reusability across multiple downstream consumers.

Instead of exposing raw SAP tables, CDS Views allow us to represent authorization metadata in a standardized and reusable format.

CDS View Architecture

The following architecture illustrates the proposed CDS View design.

Figure 3: CDS View Architecture

CDS View Architecture

Proposed CDS Views

CDS View	Source Table	Purpose
ZI_ROLE_MASTER	AGR_DEFINE	Role metadata
ZI_ROLE_USER_MAPPING	AGR_USERS	User-to-role mapping
ZI_ROLE_AUTHORIZATION	AGR_1251	Authorization rules and restrictions
ZI_AUTHORIZATION_METADATA	TOBJ	Authorization object metadata
ZI_SAP_SECURITY_MODEL	Composite CDS View	Unified security model

Recommended Development Sequence

The CDS Views should be developed in the following order:

ZI_ROLE_MASTER
ZI_ROLE_USER_MAPPING
ZI_ROLE_AUTHORIZATION
ZI_AUTHORIZATION_METADATA
ZI_SAP_SECURITY_MODEL

The Unified Security Model should consume all the previously created CDS Views and act as the canonical representation of SAP authorization metadata.

Unified Security Model

The final CDS View should expose a business-friendly representation of SAP's authorization framework.

Example:

By introducing a layered CDS View architecture, organizations can create a reusable and semantically rich Security Semantic Layer that simplifies authorization metadata extraction while remaining independent of any specific downstream technology.

Building the Security Semantic Layer

Once the CDS Views have been designed, the final step is to expose a Unified Security Model that can act as the single source of truth for SAP authorization metadata.

Rather than tightly coupling downstream systems to SAP's internal security tables, the Security Semantic Layer provides a standardized and reusable representation of roles, authorizations, and organizational restrictions.

Figure 4: Security Semantic Layer Architecture

Security Semantic Layer Architecture

The Security Semantic Layer enables organizations to:

Standardize authorization metadata.
Simplify downstream integrations.
Decouple analytics platforms from SAP's internal table structures.
Improve maintainability and extensibility of security metadata.

Since the Security Semantic Layer is technology agnostic, it can be leveraged by various analytics, governance, and modernization platforms without requiring changes to the underlying SAP authorization model.

5. Conclusion

Security migration should not be treated as an afterthought during enterprise analytics modernization initiatives. Authorization metadata is just as critical as business data and deserves the same level of architectural consideration.

By introducing a layered CDS View architecture and a reusable Security Semantic Layer, organizations can preserve SAP's mature authorization framework while simplifying future integrations with modern analytics and governance platforms.

Rather than exposing low-level SAP security tables directly, standardizing authorization metadata at the SAP layer provides a scalable, maintainable, and business-friendly foundation for enterprise security modernization initiatives.

Announcing Preview of SAP LogServ integration with Google SecOps for SAP Cloud ERP Private customers

2026-07-22T17:07:08.276000+02:00

This blog was co-authored by Ajith Urimajalu (Engineering, Google), Brad Nixon (Product, Google), Jesper Christensen (SAP Architect, Google), Krishna Rajapantula (ECS Lead of Security Engineering Operations), @Hemanth_Kusampudi (ECS Service Owner)

We are thrilled to announce the preview integration between SAP LogServ and Google Security Operations, exclusively for SAP Cloud ERP Private customers around the globe.

SAP LogServ is an SAP Enterprise Cloud Services (ECS) service aimed to provide SAP Cloud ERP Private customers access to their infrastructure and OS logs. LogServ centralizes the logs from all systems, applications, and ECS services used by a registered customer into a storage location.

Main Features include:

Near Real Time Log Collection: Integrate into a customer's SIEMs or Log Management systems.
Log Retention: Retain logs indefinitely or with an adjustable retention policy for each data source.
Recovery of logs: Ability to recover logs which were retained.

Google SecOps, with its Triage and Investigation Agent (TIN), is setting new standards in cybersecurity innovation. TIN is an AI-powered investigation assistant embedded directly in Google SecOps. The agent automatically analyzes alerts using Mandiant principles and industry best practices, determines if the alerts are true or false positives, and provides a summarized explanation for its assessment. By dynamically refining search queries, enriching data with Google Threat Intelligence (GTI), and reconstructing process trees, it offers a cutting-edge solution to protect critical business data.

The innovative integration with SAP LogServ enables SAP RISE customers to leverage the powerful security analytics and AI-driven threat intelligence capabilities of Google SecOps, seamlessly integrated with the log management features of SAP LogServ. This collaboration aims to enhance your security operations and provide comprehensive protection beyond your SAP environments to your whole IT estate.

LogServ complements the existing Google SecOps threat monitoring and detections with the log types provided by SAP ECS as the system provider. This includes logs like: ICM, SAP Web Dispatcher, SAP Gateway, SAP HANA Audit logs.

Benefits of the Integration

SAP-centric Setup: Using SAP LogServ and the Application Telemetry Collector, logs are seamlessly forwarded to Google SecOps via Cloud Storage and Bindplane agents.
Enhanced Security: Gain deeper insights into potential threats and vulnerabilities spanning beyond your SAP systems looking at your IT estate using Google SecOps' Unified Data Model (UDM).
Centralized Monitoring: Streamline your security operations by adding log data from SAP LogServ directly into your Google SecOps feeds.
AI-Powered Response: Using the Triage and Investigation Agent (TIN), significantly reduces manual triage time as the AI evaluates incoming alerts, executes an investigation plan, and provides a structured analysis of its findings and reasoning.
Proactive Threat Detection: Respond to threats in real-time utilizing detection rules built specifically for SAP environments

Securing the Crown Jewels: Why SAP RISE Customers Need Google SecOps and SAP LogServ Today

Your SAP environment houses the crown jewels of your enterprise—financial data, supply chain operations, and critical IP. Yet, for many Security Operations Centers (SOC), the SAP landscape remains a blind spot. Traditional security tools often fail to ingest, parse, and analyze complex SAP application logs at scale, leaving organizations vulnerable to sophisticated lateral movement and insider threats.

The days of flying blind are over.

Why This is a Game-Changer for SAP Security

Until now, correlating threats that originate in your broader IT environment and move into your SAP systems was a highly manual, complex, and slow process. By pairing SAP LogServ’s deep, system-level visibility with Google SecOps' planetary-scale analytics and AI, we are eliminating those silos.

For SAP Managers and CISO Leaders:

Mandiant Expertise in a Box: Google SecOps now includes the Triage and Investigation Agent (TIN). TIN is an AI-powered investigation assistant that doesn't just flag alerts—it acts on them. Using Mandiant principles and industry best practices, TIN automatically analyzes alerts, determines true/false positives, dynamically refines search queries, and reconstructs process trees. It summarizes its findings instantly, drastically reducing manual triage time and mitigating SOC burnout.
Proactive Defense, Not Reactive Scrambling: Instead of waiting for an audit failure or a breach notification, you can now respond to threats in real-time utilizing out-of-the-box detection rules built specifically for SAP environments.

For SAP Technical Architects and Security Engineers:

Unprecedented Visibility: SAP LogServ (an SAP Enterprise Cloud Services offering) centralizes critical infrastructure and OS logs—including ICM, SAP Web Dispatcher, SAP Gateway, and SAP HANA Audit logs.
Unified Data Model (UDM): Using the Application Telemetry Collector, logs are seamlessly forwarded to Google SecOps via Cloud Storage and Bindplane agents. Once ingested, they are mapped to Google’s UDM, allowing your security engineers to query SAP data alongside network, endpoint, and cloud data in sub-seconds.
Near Real-Time Collection & Indefinite Retention: Maintain compliance and investigative power with adjustable, long-term log retention and near real-time SIEM integration.

The Real-World Impact

Consider this scenario: A compromised credential from a phishing attack allows a threat actor to access a standard corporate workstation. From there, they attempt to pivot into your SAP Web Dispatcher.

Without this integration, the initial phishing alert sits in one queue, while the SAP login anomaly sits buried in an un-parsed log file. With SAP LogServ and Google SecOps, TIN instantly correlates the endpoint alert with the SAP HANA audit log, reconstructs the process tree, enriches the data with Google Threat Intelligence (GTI), and presents your SOC analyst with a structured analysis and containment plan—all before the attacker can exfiltrate your financial data.

Don't Wait for the Next Threat. Get Started Today.

Don't miss this opportunity to enhance your security posture with the powerful combination of SAP LogServ and Google SecOps. Threat actors are increasingly targeting ERP environments. Delaying your SAP security modernization is a risk you cannot afford.

Your 3-Step Action Plan:

Engage SAP: Coordinate with your SAP ECS representative immediately to enable LogServ and provision your destination Cloud Storage bucket and Pub/Sub notifications.
Deploy & Ingest: Follow our detailed documentation to deploy the Application Telemetry Collector and create your Google SecOps feeds: [Set up log ingestion for SAP RISE].
Activate Defenses: Download and deploy our out-of-the-box detection capabilities directly from the [SAP Detection Rules repository on GitHub].

Secure your SAP crown jewels with the intelligence of Mandiant and the scale of Google.

To get started, coordinate with your SAP ECS representative to enable LogServ and provision your destination Cloud Storage bucket and Pub/Sub notifications. For detailed instructions on preparing your environment, deploying the Application Telemetry Collector, and creating Google SecOps feeds, visit the Set up log ingestion for SAP RISE documentation.

You can also explore out-of-the-box detection capabilities in Google’s SAP Detection Rules repository on GitHub.

Automating SAP Security Tasks and SoD Analysis with ZSecTools (Open-Source)

2026-07-23T13:06:52.357000+02:00

Hi SAP Community,

As SAP Security administrators, we all know that keeping an ABAP stack secure, compliant, and clean involves a lot of repetitive tasks, custom queries, and sometimes a bit of frustration. While enterprise governance solutions manage high-level corporate compliance, security professionals on the ground often need a localized, agile set of utilities for immediate daily operations and deep-dive analysis.

That is why I created ZSecTools—an open-source toolkit designed specifically to support SAP Security professionals in their day-to-day activities.

The tool was originally developed for personal use to support day-to-day SAP security administration and SOD analysis work. It is now shared as open source in the hope that it can be useful to others facing similar needs.

I've been working in the SAP security field since 2011, and I've come to realize that I would like to share my knowledge with the community to create and share value.

You can find the full source code and documentation on GitHub: 👉 https://github.com/va87git/zsectools

What is ZSecTools?

ZSecTools is not a certified governance tool, nor is it meant to replace robust enterprise risk management software. Instead, think of it as a professional Swiss Army knife. It is built to provide immediate added value, automating heavy tasks and offering deep visibility into the security authorization model of your SAP systems.

Architecture Overview & Deployment

To keep deployment simple, clean, and isolated, ZSecTools leverages a modern architecture that can be run in two different ways depending on your environment:

Backend & Processing: Powered by a Node.js engine that handles the heavy lifting, including complex SoD calculations and mass operations.
Data Layer: Uses a localized PostgreSQL database to store configuration matrices, imported data, and report results securely.
Flexible Deployment Options:
- Dockerized Stack: You can spin up the full environment with a simple container setup to keep everything isolated.
- Self-Contained / Portable Scripts: If you cannot or prefer not to use Docker, the repository includes automation scripts that use curl to pull down portable versions of Node.js and PostgreSQL. This creates a fully local, self-contained installation that doesn't require administrator privileges or permanent system installations.
SAP Connectivity (BYOD): To connect to your ABAP backend, the tool relies on a Bring Your Own Dependencies approach. Out of respect for SAP licensing compliance, the repository does not include proprietary files. Users must download the required SAP NW RFC SDK libraries directly from the SAP Me portal using their own S-User account, as detailed in the README setup instructions.

Key Features & Capabilities

Segregation of Duties (SoD) Analysis: Run targeted SoD checks directly through the toolkit to identify conflicting access risks within your user base.
Custom Security Quality Reports: The tool includes several built-in custom reports designed to measure and audit the overall quality and health of your SAP security configuration.
Mass Maintenance Operations: Managing roles and users one by one can be time-consuming. ZSecTools includes powerful mass functionalities to streamline user and role administration.
License Exposure Estimation (STAR-aligned): By uploading a properly configured SoD matrix, you can run a report to estimate your license risk profile based on critical permissions. Since the official STAR matrix is publicly available on the SAP Support Portal, you can easily map these criteria within the tool to evaluate your system's license exposure ahead of official measurements.

Pre-configured SAP Role Included

To make the deployment straightforward, the repository includes a dedicated SAP role export file. Importing this file provides a pre-configured role with the minimum authorization objects and RFC call permissions required for the toolkit to function safely, allowing you to review exactly what the tool can access before running it.

Designed for Practitioners

I want to emphasize that ZSecTools is built to support people who already have a solid understanding of SAP authorization objects and security concepts. It acts as an accelerator for your existing skills, giving you the technical utility you need to manage your systems more efficiently.

Get Involved & Active Development

The project is published under an open-source license and is currently under active development. This means new features, optimizations, and reports are planned for the near future.

Feel free to explore the repository, try it out in your sandbox environments, and share your thoughts or open an issue on GitHub if you have suggestions or find it useful!