Introduction: The Threat Is Already Inside
There was a time when SAP systems were seen merely as back-office applications—isolated, internal, and safely hidden behind the corporate firewall. Back then, cybersecurity mostly meant protecting networks or email servers.
Today, the landscape has changed completely. SAP now sits at the very heart of business operations—from production to finance, from procurement to customer engagement—and has become a direct target for cyberattacks.
These attacks exploit weak points such as credential theft, abuse of Remote Function Calls (RFC), unpatched services, or misconfigured web settings. That’s why the role of the Basis team has evolved—from simply keeping systems running to keeping systems secure.
The Basis Layer: An Invisible but Critical Security Wall
Attackers rarely storm the perimeter firewall; they prefer to slip through configuration mistakes. A single parameter error can turn a robust architecture into an open gate.
Common pitfalls include:
Misconfigured trusted RFC connections
Permanent assignment of broad profiles such as SAP_ALL
Bypassed transport approval or review gates
Missing SSL/TLS settings in ICM or HTTP services
Small “conveniences” can create massive vulnerabilities.
Three Lessons from the Field
Scenario A — The “Trusted” RFC Trap: Test → Production
At a logistics company, a test system was connected to production (PRD) through a trusted RFC for convenience.
In SAP, trusted means the call executes with the target user’s authorizations—so a wrong setup can completely skip the authorization chain.
A developer unintentionally modified live data from the test system, corrupting shipment schedules.
Lesson: Use trusted RFCs only when absolutely necessary—always with minimal privileges and detailed logging.
Scenario B — When Logs Go Silent
To “save” disk space, SM20 logging was disabled.
As a result, brute-force login attempts went unnoticed for days and were discovered only after user complaints.
Lesson: It’s not enough to store logs; they must be readable, correlated, and capable of triggering alerts.
Scenario C — Patch Neglect and Data Integrity Loss
NetWeaver and HANA components were left unpatched for years because “everything was working.”
When a critical SAP Security Note was ignored, attackers exploited the gap and altered financial data integrity.
Lesson: “Working” does not mean “secure.” A strong patch-and-test culture is non-negotiable.
When Cyberattacks Hit the Real World
In 2025, the large-scale cyberattack against Jaguar Land Rover demonstrated how deeply modern production and ERP systems depend on each other.
The company’s manufacturing lines and supply chain were disrupted for weeks.
Independent security analysts later suggested that the incident may have been linked to an unpatched SAP NetWeaver vulnerability.
Although not officially confirmed, the case reignited awareness of how critical patch management and access controlare to any enterprise cybersecurity strategy.
The Jaguar Land Rover case reminds us:
In SAP environments, security is not just a technical matter — it’s a strategic necessity for the continuity of production, finance, and the supply chain.
When managed properly, SAP can become an organization’s strongest line of defense.
(Sources: The Guardian, SecurityWeek, GateKeeperHQ)
Core Security Domains for SAP Basis Teams
User and Role Management
Access security in SAP systems goes far beyond simply creating user accounts or assigning roles.
Tools like SU01, PFCG, and SUIM are extremely powerful—but when misconfigured, they can create significant vulnerabilities.
Unnecessary roles should be reviewed and removed regularly, temporary accounts should close automatically, and all permissions must follow a task-based authorization principle.
Privileged Access Management (PAM)
Privileged access remains one of the highest-risk areas within SAP landscapes.
In Emergency Access (Firefighter) scenarios, broad privileges such as SAP_ALL must never be permanent—they should only be granted temporarily through fully recorded and auditable sessions.
These access processes should be managed via SAP GRC Access Control, SAP Emergency User Management (SUEM), or third-party PAM tools, with approval workflows, session recording, and reporting mechanisms in place for every access request.
Multi-Factor Authentication (MFA)
The final link in the security chain is authentication—and MFA is no longer optional.
For Basis, development, and privileged users, MFA must be enforced across all access points: SAP GUI, Fiori Launchpad/NWBC, HANA Database, and web services.
Authentication should be integrated with the corporate Identity Provider (IdP) using SAML 2.0 or OAuth for secure, enterprise-wide identity federation.
Transport Security
In SAP environments, every transport represents not only a change package but also a potential security risk.
Transport processes must therefore be traceable, auditable, and subject to approval workflows.
All transports should pass through SAP Solution Manager (ChaRM), SAP Cloud ALM, or similar governance tools, and the STMS (Transport Management System) should integrate tightly with these workflows.
Before reaching the production system (PRD), each package must pass through Quality Gate validation to ensure compliance and security.
This ensures that only technically correct and security-approved code reaches the live system.
Custom Development (ABAP) Security and Code Scanning
Custom developments (Z-programs) often become invisible yet critical security risks within SAP systems.
No matter how robust the infrastructure, a single insecure ABAP code can bypass all protection layers.
Therefore, code must be reviewed and approved from a security perspective before reaching the transport stage.
Static Code Analysis (SAST): Use SAP’s built-in Code Vulnerability Analyzer (CVA) or third-party code scanning tools to perform mandatory pre-transport security checks.
Security Approval: All custom developments must undergo formal security reviews for issues such as SQL injection, missing authorization checks, and RFC exploitation, ensuring that only approved code moves to production.
Logging and Monitoring Culture
System security is not achieved merely by collecting logs—it depends on interpreting them effectively.
In SAP environments, logs such as SM20, ST03N, and STAD should not just be stored; they must be correlated and analyzed through SIEM or UEBA tools to identify unusual behavior.
True security lies not in having logs, but in making incidents visible, contextual, and actionable.
Further Reading
Explore this article to learn about the most common and often overlooked critical security errors in the SAP Basis layer and how to prevent them!
Inter-System Communication Security (RFC, Gateway, ICM, SICF)
One of the most frequently overlooked areas in SAP infrastructure is inter-system communication.
Simple safeguards at the RFC, Gateway, and ICM layers can drastically reduce the attack surface.
Unnecessary RFC connections should be disabled, reginfo and secinfo files must remain up to date, and TLS (Transport Layer Security) should be enforced on the ICM level.
At the SICF layer, only essential services should remain active. Unused or anonymous-access services must be deactivated.
Active services should be protected with appropriate authentication methods such as SSO2, X.509 certificates, or user/password, and failed login attempts should be limited.
These measures are especially critical for Fiori, OData, and external integration services.
SAP Router Security (Hardening)
The SAP Router manages and secures communication between SAP systems and external connections,
but if misconfigured, it can become a direct entry point for attackers.
The SAPROUTTAB file should allow only authorized and known IP addresses, and the default rule should always be *“D ” (deny all).
dev_rout log files must be monitored regularly, and SNC (Secure Network Communication) encryption should be enabled to protect communication channels.
This configuration ensures that external access remains secure and prevents the SAP Router from becoming the weakest link in the network defense chain.
Database Layer Security
Database-level security—especially in SAP HANA environments—is critical.
In production systems, the SYSTEM user must be locked, DEFAULT_SCHEMA_OWNER accounts removed, and audit trail functionality enabled.
System and tenant users should have clearly separated duties, and where data protection is essential, Transparent Data Encryption (TDE) should be activated to secure data at rest.
SAP-Specific Network Segmentation
In SAP architectures, hosting the application (App), database (DB), and web layers within the same network segment introduces serious risks.
These layers should reside in separate VLANs, with dedicated firewall rules for RFC Gateways, and SAP Cloud Connector must be placed within the DMZ.
Critical communication ports—such as 32xx, 33xx, and 5xx13–5xx14—should be tightly controlled and restricted only to required systems and connections.
SNC (Secure Network Communication) Encryption
To ensure secure communication between SAP components, SNC encryption must be enabled.
It protects both SAP GUI ↔ Application Server and Server ↔ Server (RFC) traffic, maintaining confidentiality and data integrity.
Certificates used for SAPCryptolib and STRUST must be renewed periodically, and their validity should be actively monitored.
Profile Parameter Security
SAP system parameters directly affect critical aspects of security—from password strength to session behavior.
Parameters such as login/min_password_lng, login/fails_to_user_lock, and rdisp/gui_auto_logout should be reviewed regularly and configured in line with corporate security standards.
Consistent parameter governance ensures that user access and session management remain compliant and predictable.
Backup and Restore
Data security isn’t just about creating backups—it’s about ensuring that backups can actually be restored.
Backups should be stored in immutable repositories and tested through regular restore drills.
The most expensive incident is not data loss—it’s discovering that your backup cannot be restored.
SAP Security Patching and System Currency
Sustainable security in SAP environments depends on keeping systems continuously up to date.
SAP Security Notes must be reviewed every month, and components such as NetWeaver, Kernel, ABAP, and HANAshould remain current.
Patch management should always follow a test → approval → production (PRD) flow,
with a defined hotfix procedure for emergencies.
Regular patching ensures that “working” does not silently become “vulnerable.”
Practical Security Measures by Attack Type (Quick Reference Guide)
Attack Type | Recommended Measures |
Credential Theft / Brute-force Attacks | MFA (Multi-Factor Authentication), strong password policies, account lockout after failed attempts, service account isolation, SIEM alerting |
RFC / Trust Abuse / Lateral Movement | RFC whitelist, trusted connection restrictions, RFC call logging, SNC-based encryption |
Malware / Ransomware | EDR (Endpoint Detection & Response), immutable backups, network segmentation, regular restore drills |
Phishing / Business Email Compromise (BEC)
| DMARC/DKIM/SPF configuration (email authentication), user awareness training, dual approval for critical transactions |
DDoS / Availability Attacks
| WAF (Web Application Firewall), reverse proxy, ISP-level DDoS protection |
Unpatched Exploits | Vulnerability scanning, rapid patch deployment, rollback plan and testing |
Proactive Security Culture: The Cost of Being Reactive
Taking action after a security incident usually means paying a higher price — both financially and operationally.
Real security is not about reacting to incidents but anticipating them.
Organizations must cultivate a proactive security culture: detect risks early through regular checklists and automation routines, monitor SAP Security Notes updates monthly, conduct system audits quarterly, and perform at least one penetration test annually.
Security should not be treated as a purely technical issue, but as an integral part of enterprise risk management. A proactive culture turns security from a burden into a continuous resilience capability.
Compliance and Audit Readiness
Security in SAP systems goes far beyond technical controls—it also encompasses compliance and audit obligations.
Standards such as GDPR, ISO 27001, and SOX define how data is stored, who can access it, and how every action must be traceable.
To meet these requirements, authorization matrices should be properly documented, log retention periods must comply with regulations, and all system changes should be recorded in a traceable manner.
Basis teams today are no longer just technical operators; they are key enablers of organizational compliance strategy, bridging technology with governance.
Security in Modern SAP Architectures: Adapting to Cloud and Fiori
SAP environments are no longer limited to on-premise systems—cloud, hybrid, and Fiori-based architectures have fundamentally reshaped the security landscape.
In these models, every component—access, data, and integration—requires its own layer of protection.
SAP BTP Security Model:
On the cloud side, the SAP Business Technology Platform (BTP) manages authorization through a Role / Role Collection structure.
Authentication relies on OAuth 2.0, while secure external connectivity is handled via Destination Services, forming the backbone of BTP application security.
Fiori Security:
Proper role design within Fiori Launchpad is not just about user experience—it’s a security necessity.
Each Fiori app consumes specific OData services, and it’s crucial to know which SICF endpoints these services expose.
Only essential endpoints should remain active, protected with appropriate authentication mechanisms.
SAP Cloud Connector Security:
The SAP Cloud Connector—the bridge between on-premise and cloud systems—can become a critical vulnerability if misconfigured. Therefore, Access Control Lists (ACLs) must be reviewed regularly, connections should remain open only for required systems and services, and the connector should ideally reside within the DMZ.
Certificate management must also be handled with precision to ensure trust and data integrity across hybrid landscapes.
Automation and Continuous Monitoring: “Manual Is No Longer an Option”
In a modern SAP landscape, manually monitoring dozens of control areas is no longer feasible.
Effective security depends on a strong culture of automation and continuous monitoring.
Centralized Log Management:
Logs from SAP, the operating system, and databases should be aggregated in a central location and streamed into a SIEMsolution.
Correlation rules must be defined, and behavioral analytics (UEBA) should automatically detect abnormal activities.
This transforms monitoring from a manual task into a proactive detection mechanism.
Monitoring with SAP Solutions:
SAP Solution Manager provides built-in security alerting scenarios, while SAP Focused Run delivers automated deviation detection and alert mechanisms for large-scale environments.
These tools replace manual verification with continuous, systematic oversight.
Vulnerability Management:
SAP-specific vulnerability scanners such as SecurityBridge or Onapsis should be executed on a regular basis.
Findings must feed directly into change management workflows, ensuring that every discovered vulnerability becomes a managed risk, not an uncontrolled exposure.
Operating System and Infrastructure Layer Security
The security of an SAP system begins with the robustness of the platform it runs on.
Before addressing application-level security, the infrastructure itself must be secure and properly maintained.
Operating System Hardening:
Disable unnecessary services, tighten local firewall rules, and ensure that SAP operating users work with minimal privileges only.
Regular Patch Management:
Security extends far beyond SAP patches.
Establish a consistent patch policy for Linux, Windows, and AIX operating systems, as well as for the hypervisor and even hardware firmware layers.
SAP Host Agent:
Often overlooked, the SAP Host Agent plays a critical role in monitoring and system administration.
It must always remain up to date and properly configured to ensure accurate data collection and system visibility.
Conclusion: From Operator to Security Architect
A Basis expert today is no longer just the person who “keeps the system running,”
but the one who keeps the system secure.
Success is now measured not only by downtime, but also by compromise time — the duration between an attempted breach and its detection.
Behind every resilient SAP landscape lies a culture that:
- enforces MFA,
- applies patches on time,
- automates routine processes,
- understands cloud and hybrid architectures, and
- documents parameters and procedures with precision.
Because ultimately, it’s not the firewalls that protect systems —
it’s careful people and disciplined processes.