Cleaning Up SAP Authorisations: A Pragmatic Guide
A step-by-step approach to bringing order to historically grown authorisations.
Read more →2025 was a wake-up call for SAP security: for the first time, 23% of organisations reported a cyber attack on their SAP environment. Zero-day exploits such as the NetWeaver incident (CVE-2025-31324) demonstrated how quickly ransomware groups exploit SAP vulnerabilities. The good news: most successful attacks don’t use zero-days but known, unpatched vulnerabilities. The following 10 measures significantly reduce your attack surface.
1. Establish Patch Management with Prioritisation
SAP publishes monthly Security Notes. In H1/2025 alone, 14 were HotNews with CVSS scores above 9.0. A simple “we patch quarterly” approach is no longer sufficient. Establish a process that evaluates HotNews patches within 72 hours and applies critical patches within 2 weeks.
2. Eliminate Default Passwords and Users
Sounds trivial but is alarmingly common in practice: SAP* users with default passwords, DDIC without a lock, EARLYWATCH with extensive authorisations. A systematic scan of all clients provides clarity.
3. Inventory and Harden RFC Connections
RFC connections are a frequently underestimated attack vector. Document all trusted and stored-credentials connections. Remove connections no longer needed. Use SNC for the remaining ones.
4. Monitor Critical Transactions
SE16, SM59, STMS, SU01 – these transactions should not be used without monitoring. Configure the Security Audit Log (SAL) for critical activities and evaluate it regularly.
5. Clean Up ICF Services
Many HTTP services in the Internet Communication Framework are activated by default but not needed. Every active service is a potential attack surface. Systematically deactivate all unused services.
6. Authorisations Based on the Least-Privilege Principle
31% of all SAP patches in 2025 addressed missing authorisation checks. If your users simultaneously have too many authorisations, the risk compounds. Start with the most critical profiles: Who has SAP_ALL? Who has access to debugging in the production system?
7. Configure Gateway Security
SAP Gateway Security (reginfo, secinfo) controls which programmes may externally call RFC function modules. An open configuration potentially allows anyone on the network to call function modules.
8. Enforce Encryption
SNC for RFC/dialog, TLS for HTTP/HTTPS, encryption of the HANA database. Many systems still run with unencrypted communication – this is no longer acceptable in 2026.
9. Automate Security Monitoring
Manual log evaluation does not scale. Implement automated alerts for suspicious activities: unusual login times, mass data exports, changes to critical tables.
10. Create an Incident Response Plan
What happens when an attack is detected? Who is notified? How is the system isolated? A documented and tested plan is the last line of defence – and an audit requirement.
Conclusion
Most of these measures don’t require a large budget – but rather systematic approach, priorities and experience. If you’d like to know where your SAP landscape stands today, we offer a free Security Quick-Check as an initial consultation.
Request Security Quick-Check →
Related Articles
S/4HANA Migration Checklist
12 points your Basis team must clarify before the project starts.
Read more →SAP Profile Parameters: On-Prem, Cloud & S/4HANA
The most important security parameters compared across all three environments.
Read more →Need support with this topic?
We help you with implementation – from analysis to go-live.
Get in touch