SAP S/4HANA 2025 introduces four breakthrough security mechanisms that activate automatically upon installation. This is the result of several years of evolution in secure-by-default thinking – moving from aspiration to reality. The problem is that only 32% of organisations have completed their conversion, and the 2027 deadline is approaching relentlessly. With 23% of companies having experienced cyberattacks on their SAP environments in the past year, the question is: are you ready for a transformation in which security is not an add-on, but the foundation?
From aspiration to reality – the evolution of security by design
In 2018, when SAP introduced the first release of S/4HANA 1909, the concept of security built into the system sounded like a bold promise. Seven years later, in the S/4HANA 2025 release, it is no longer an aspiration – it is the foundation of the architecture. SAP itself describes this transformation: “What began as a bold initiative to strengthen the default security posture has, over the years, become a fundamental product principle.”
Every subsequent version of S/4HANA – from 1909 through 2020, 2021, 2022, 2023 to today’s 2025 – brings additional layers of protection. This is progressive hardening that applies automatically during new installations, ECC conversions, and system copies. The key word is automatically. You do not need to switch anything on. You do not need to remember successive parameters. The system does it for you.
“This is precisely what distinguishes SAP’s contemporary approach from what we saw a decade ago,” says Jarosław Kamil Zdanowski, Partner at SNOK and an expert in SAP Basis and cybersecurity. “Security used to be a checklist to complete after go-live. Today it is built into the structure of the system. But be aware – this is only the starting point, not the finish line.”
Four pillars of security in the 2025 release
The latest S/4HANA release brings four specific innovations that deserve particular attention.
TLS 1.3 – next-generation encryption
The first innovation is support for TLS 1.3 – the latest transport-encryption standard. It covers all web interfaces: SAP Internet Communication Manager (ICM), SAP Start Service and SAP Host Agent. Implementation requires Kernel Version 793 PL84 or higher and CommonCryptoLib version 8.5.55 or later.
What does this mean in practice? TLS 1.3 simplifies cipher suites, always enforces Perfect Forward Secrecy, and speeds up connection establishment. This is not a cosmetic change – it is a fundamental difference in security architecture. While TLS 1.2 requires two full round trips to establish a secure channel, TLS 1.3 reduces this to one.
The end of the era of old login tokens
The second innovation sounds like a funeral for a technology: SAP is discontinuing support for old SAP login tokens, retaining only modern SAP Assertion confirmation tokens. The old tokens, deemed unsafe, are disappearing from the landscape. This is also part of a broader trend – since the 2023 release, SAP has been systematically eliminating outdated trust-based communication mechanisms.
“We see this with clients every month,” comments Michał Korzeń, CTO of SNOK and an architect of enterprise and AI solutions. “Older solutions are convenient. But convenience has a cost. Organisations that put off modernising their authentication mechanisms build up technical debt that, in the context of NIS2 and upcoming audits, can prove very painful.”
Logs for SIEM systems – the end of manual processing
The third innovation is security logs in a machine-readable format from ICM. It sounds technical, but it has fundamental practical significance. Until now, integrating SAP logs with corporate security information and event management systems has been an administrator’s nightmare – closed formats, non-standard structures, the need for dedicated parsers.
S/4HANA 2025 puts an end to this problem. Security logs from ICM are now structured in a way that enables direct integration with Splunk, Microsoft Sentinel, IBM QRadar and other security-management platforms. That means real-time monitoring, automated alerts, and the inclusion of SAP in a unified organisational security picture.
“This breaks a fundamental problem faced by security operations centre teams,” adds Jarosław Zdanowski. “SAP typically operates in a silo. The SAP Basis team has its own tools, the information-security team has its own, and there’s a gulf between them. Logs in a readable format are the bridge that finally connects them.”
Content Security Policy – a second line of defence
The fourth innovation is Content Security Policy in reporting mode. CSP acts as a second layer of defence against Cross-Site Scripting attacks in web applications. Reporting mode allows organisations to test policies without risking the disruption of genuine functionality.
At the same time, SAP is disabling the legacy ICM content-scanning interface, replacing it with dedicated security-checking mechanisms built directly into browser-based applications. This is a practical shift of security closer to the user, making it a natural part of the application rather than an external add-on.
What we inherit from previous versions
Security built into S/4HANA 2025 is not just about four new features. It is the accumulation of protections built up over seven years of development. Every system you install or convert to today automatically receives the full stack of defensive mechanisms.
From version 1909: strengthened authorisation, improved RFC interface protection, activation of the security audit log.
From version 2020: strong password policies, protection of intra-system communication, activation of all switchable authorisation-control scenarios.
From version 2021: activation of the HANA audit log, logging of changes to critical business tables, WebDynpro protection, an HTTP allowlist, and clickjacking protection.
From version 2022: mandatory SSL protection for session login tokens, RFC gateway protection, and enforcement of TLS 1.2 as the minimum for all web interfaces.
From version 2023: automatic activation of HANA data-at-rest encryption (in HANA2 SP07 and later), and blocking of user-role assignment via transports (eliminating the risk of unauthorised permissions in production environments).
“This is exactly the strength of the progressive model,” explains Jacek Bugajski, CEO of SNOK. “Clients sometimes ask: why upgrade again if the current version works? The answer is simple – every new version of S/4HANA delivers protections that in older systems would require months of manual configuration. That’s not a cost, it’s an investment in peace of mind.”
The gap between default and sufficient
Let us, however, look at the hard truth: default security is the starting point, not the finish line. SAP itself states plainly: “Default security settings cannot and will not cover every aspect of security configuration in S/4HANA systems.”
What does this mean in practice? Three areas require your attention:
First: settings specific to your organisation. Default security parameter profiles are generic – tuned to average needs. Your company may need stricter password policies, specific network restrictions, or dedicated audit policies.
Second: regular security updates. SAP publishes security information on the second Tuesday of every month. Default security does not replace this process. According to the SAPinsider 2025 survey, 35% of organisations cite patch management as their biggest security challenge – for the third year running. The reason? Difficulty scheduling downtime (64% of respondents) and verifying application compatibility with updates (57%).
Third: security of custom code. Your ABAP modifications, extensions, custom interfaces – all of these require dedicated protection. Switchable authorisation controls and other framework tools help, but they do not replace a security review of your own code.
Polish realities – a compliance stack that shows no mercy
If you run an organisation in Poland, you carry an additional layer of complexity. And it is not only about the language of the interface.
NIS2 – board-level accountability that hurts
The NIS2 directive, implemented in Poland during 2024/2025, represents a paradigm shift. It applies to medium and large organisations in critical sectors – energy, transport, banking, healthcare, and public administration and digital infrastructure.
What does this specifically mean for SAP? An ERP system is a critical business application. NIS2 requires cyber risk management viewed through the lens of social and economic impact. Security updates (paragraph 6.6 of the directive), incident response, supply-chain security, documentation – all of this becomes mandatory and subject to audit.
But most importantly: board-level accountability. The board is personally responsible for compliance. Financial penalties, suspension of operations, potential disqualification from management roles – this is no longer abstract, it has been reality since October 2024.
“We recently spoke with the CIO of a large manufacturing company,” recounts Jacek Bugajski. “The first question asked was: who goes to prison if there’s a breach? That shows a shift in awareness. NIS2 is not just another IT regulation – it is a business risk at the very top of management.”
DORA – if you operate in finance
If you operate in the financial sector, since 17 January 2025 you carry an additional compliance layer – DORA (the Digital Operational Resilience Act). It requires managing IT and telecommunications risk, digital resilience testing, incident reporting, and supplier risk management.
What does this mean for SAP? Protection of data exports (Excel, PDF from SAP), supply-chain management, and incident-response documentation. DORA is more restrictive than NIS2 for financial institutions.
JPK_CIT – because Polish tax compliance matters too
Since January 2025, JPK_CIT (the Standard Audit File for corporate income tax) has been mandatory. This is not SAP security in the strict sense, but it has a direct impact on system architecture.
The Polish specifics: automatic data extraction from ERP, generation of XML according to the Polish XSD schema, validation, and transmission to the e-Urząd Skarbowy (e-Tax Office) system. It requires dedicated extensions (e.g. SAP-certified Melasoft solutions) and integration with SAP FI/CO.
“This is exactly the kind of example we talked about – default security does not cover local compliance requirements,” comments Jarosław Zdanowski. “JPK, the Polish audit file, is a challenge that requires local expertise. That’s why partnering with Polish firms that understand the regulatory landscape and have ready-made solutions is so important.”
The 2025 threat landscape – what is really attacking SAP
Data from the SAPinsider/Onapsis 2025 survey is unambiguous: 23% of organisations experienced cyberattacks affecting SAP environments in the past year, while 92% consider data in SAP systems mission-critical.
The threat ranking has changed dramatically:
Number one: data theft. It jumped from fourth place in 2024 to first in 2025. The reason? Centralisation of data for AI initiatives, deployments of the SAP Business Data Cloud, and concentration of critical business information. Attackers no longer just want to lock systems (ransomware) – they want to steal data.
Number two: unpatched systems. Consistently in the top three for years. The zero-day vulnerability in S/4HANA discovered and exploited in 2025 showed that attackers have deep technical knowledge of SAP and are actively searching for weaknesses.
Number three: connections with other systems. A jump from tenth place to third. Cloud, hybrid cloud, expanding application landscapes – every integration point is a potential attack vector.
“This answers the question of why machine-readable logs in S/4HANA 2025 matter so much,” emphasises Michał Korzeń. “It’s not about architectural elegance. It’s about the fact that without real-time visibility across connected systems, you’re blind. And blindness in cybersecurity is a guarantee of trouble.”
SecurityBridge and bowbridge – a Polish context for global tools
SNOK, as a partner of both SAP and SecurityBridge and bowbridge Software GmbH, has a unique perspective on how these tools work alongside default security.
SecurityBridge – the platform that sees everything
SecurityBridge is the first and only fully integrated cybersecurity platform operating entirely embedded within the SAP environment. 200+ clients worldwide, 5,000+ production systems secured. In Poland we deliver implementations that demonstrate concrete business value.
Case study: Stock Spirits Group – a spirits producer operating in Poland, the Czech Republic and Italy. During its S/4HANA transformation, SNOK implemented SecurityBridge. The challenge? Transitioning from regional entities to a pan-European entity, increased cyberattack risk, and a lean SAP team requiring efficient alert management.
The result? Critical security back doors closed, a strengthened protective posture, streamlined monitoring without overwhelming a small team, and correct baseline configuration eliminating false alarms.
Quote from Stock Spirits: “With my many years of experience in SAP, it is clear that SecurityBridge fills critical security gaps that SAP itself is unable to address” – Jaromir Wróblewski, Group IT Infrastructure Manager.
SecurityBridge integrates with Splunk, Microsoft Sentinel and IBM QRadar. Automated vulnerability scanning, patch management, code-security analysis, machine-learning-based behavioural anomaly detection, and round-the-clock continuous monitoring. And most importantly – deployment within 48 hours with no additional infrastructure required.
“Clients often ask: is SecurityBridge a competitor to default security?” says Jarosław Zdanowski. “The answer is: no, these are complementary layers. Default security gives you a healthy foundation. SecurityBridge gives you eyes, ears and reflexes. You see what’s happening, respond to threats, manage vulnerabilities, automate compliance. It’s the difference between having a lock on the door and having an alarm system, cameras and guards.”
bowbridge – when malware targets file uploads
bowbridge fills a specialisation missing from the standard toolkit: antivirus protection for SAP applications. Why doesn’t a standard antivirus program work? Because files uploaded to SAP are encrypted in transit, stored in closed repositories (not on the file system), and a system-level antivirus has no access to encrypted files within the SAP database or content server.
bowbridge integrates with the SAP NetWeaver virus scan interface – the only solution designed specifically for this interface. Complete in-memory scanning, support for two engines (Trellix and SOPHOS), full scanning of SAPCAR archives, and detection of Cross-Site Scripting attacks even in hidden files.
For RISE with SAP – where SAP secures the operating-system layer (antivirus protection at the file-system level) but cannot secure the application layer (files in the memory of the SAP work process, the database, the content server) – bowbridge fills exactly that gap.
“We’ve seen cases where organisations had state-of-the-art endpoint protection, but malware got in through an SAP file-upload form in an HR application,” recounts Michał Korzeń. “The standard antivirus didn’t catch it, because the file never touched the file system in a way that would let it see it. In the HANA database it was encrypted. bowbridge scans in memory before the file is ever committed to persistent storage. That is precisely what defence in depth looks like.”
The reality of conversion – where we stand in 2025
The hard truth about S/4HANA adoption: only 32% of organisations have completed their conversion. 27% are in active implementation. 21% are still in the assessment phase. And the 2027 deadline – the end of mainstream ECC support – is just around the corner.
The Basis Technologies model (reviewed by SAP experts) predicts that only 57% of ECC clients will complete their conversion by 2027. 80% by 2030. The full transformation will continue until the mid-2030s.
What does this mean in practice? A resource shortage. Consulting prices will rise. Expert availability will shrink. Organisations that wait until the last moment will pay more. This is not scaremongering – it is simple supply-and-demand economics.
“We have clients who came to us in 2023 asking for a pre-conversion audit,” recalls Jacek Bugajski. “Those who started then are now finishing, or in the final stages. We also have clients who came in 2024 saying: we’ll do it in a year. And here we have to tell the truth – a realistic timeline is 18-36 months, depending on complexity. The later you start, the greater the pressure, the more shortcuts, the higher the security risk.”
What to do – an action plan
If you are planning a conversion
Carry out a baseline security assessment before you begin. You cannot carry security debt from ECC into S/4HANA – that would be like building a new house on faulty foundations.
Build security into the project timeline and budget from day zero. Not as a later add-on, but as a core element. Security built into the project costs five times less than security bolted on afterwards.
Plan for compliance from the outset. NIS2, DORA (for financial institutions), JPK_CIT, GDPR – these are not separate projects. They are requirements that must be built into the system architecture.
Consider RISE with SAP if you have limited infrastructure resources. The shared-responsibility model – SAP secures the platform, you secure the application – can be effective, provided you understand where the boundary of responsibility lies.
If you already have S/4HANA
Verify that default security settings are active. SAP Note 2926224 contains the full checklist. Opting out is possible for profile parameters, but SAP explicitly does not recommend it. If someone in your organisation disabled some settings during the conversion “because something wasn’t working,” you may have security gaps.
Close visibility gaps. Default security does not cover integration with security-management systems. Machine-readable logs from ICM in S/4HANA 2025 make this significantly easier, but someone still needs to connect those logs to Splunk/Sentinel/QRadar and configure the relevant alerts.
Consider third-generation platforms such as SecurityBridge for continuous monitoring and bowbridge for file-based protection. Default security, plus native SAP tools, plus specialised platforms, add up to a complete toolkit.
For everyone
Patch management cannot be ad hoc. The second Tuesday of every month is SAP’s update day. You need a process: monitoring security bulletins, assessing impact, testing in a test environment, and deploying to production. Automated vulnerability-scanning tools (SecurityBridge, Onapsis, Pathlock) reduce the manual effort involved.
Train your people. Security awareness is not a one-off training session at onboarding. It is a continuous programme. Phishing, social engineering, credential compromise – 57% of attacks exploit human error.
Audit regularly. Quarterly access reviews, annual comprehensive security assessments, penetration testing. Do not wait for a regulator’s audit or an attacker’s breach.
SNOK and PWCyber – where expertise meets an educational mission
SAP system security in Poland is not just a matter of commercial deployments. It is also an educational and awareness challenge. SNOK is an active participant in the PWCyber initiative – the Cybersecurity Cooperation Programme run by Poland’s Ministry of Digital Affairs.
PWCyber is a platform bringing the public sector together around a shared goal: raising the level of cybersecurity in Poland. As part of this initiative, SNOK runs educational activities focused on the specifics of securing SAP environments – an area that, despite its critical importance to the Polish economy, remains a niche topic in cybersecurity discussions.
“SAP systems are the backbone of the Polish economy – from energy through manufacturing to the public sector,” says Jacek Bugajski. “But when we talk about cybersecurity in Poland, the discussion focuses on classic topics: firewalls, endpoints, phishing. Meanwhile, SAP requires specialist knowledge – from authorisation mechanisms through RFC protocols to vulnerabilities in ABAP code. This is not knowledge that security teams have naturally. That’s why we’re involved in PWCyber – to help close this competency gap.”
In practice this means participating in conferences, webinars, expert publications, and collaboration with technical universities. The topics covered range from SAP security fundamentals for information-security teams to advanced subjects for SAP Basis administrators – from implementing NIS2 in SAP environments, through SAP-specific penetration testing, to building vulnerability-management programmes.
“We see the effects of this work in the field,” adds Jarosław Zdanowski. “Five years ago, a conversation with a client’s security team about SAP ended at ‘do you have a firewall in front of SAP?’ Today they ask about SACF, about segregation of duties in GRC, about anomaly monitoring in SecurityBridge. That is precisely the change in awareness we’re aiming for. Because the technology keeps evolving – we saw that with S/4HANA 2025 – but people need to know how to use it.”
This is particularly important in the context of NIS2 and growing regulatory requirements. Organisations need not only tools but also knowledge: how do you carry out an SAP security audit in line with the directive’s requirements? How do you build an incident-response plan that accounts for the specifics of the SAP environment? How do you document security controls in a way that auditors – who may not be SAP experts themselves – can understand?
“PWCyber gives us a platform to spread this knowledge more widely than just among our direct clients,” concludes Michał Korzeń. “It’s an investment in the long-term resilience of Polish business. Because when organisations understand the threats and have the competencies to counter them, the whole ecosystem is safer. And that is in all of our interests.”
The future is security by design, not added later
S/4HANA 2025 and its default security are a symptom of a broader trend in enterprise software: security is becoming the default, not optional. Zero-trust architecture, AI-based threat detection, automated compliance monitoring – these are no longer buzzwords, they are reality.
For Polish organisations facing the choice of migrating now or waiting, the data is unambiguous. Waiting means rising operating costs (25-30% annually), resource shortages, accumulating technical debt, and multiplying security gaps.
“Every day of delay is a day when your ECC system is one patch older, one vulnerability more exposed, and one experienced consultant less available on the market,” concludes Jacek Bugajski. “But if you do it right – with security from day zero, with local partners who understand the Polish compliance context, with third-generation tools complementing default security – this is not an IT project. It is a business transformation that delivers competitive advantage.”
S/4HANA 2025 gives you a healthy foundation. What you build on it is up to you.
Summary
Default security in SAP S/4HANA 2025 automatically activates TLS 1.3, disables outdated login tokens, provides logs in a format readable by security-management systems, and introduces Content Security Policy. This is a starting point that needs to be supplemented with security-specific configuration, regular updates, protection of custom code, integration with security-management systems, and compliance controls. The Polish context (NIS2, DORA, JPK_CIT) and the 2027 deadline are creating pressure to act. Organisations that treat security as an add-on will pay the price in the form of non-compliance penalties, security breaches, and lost opportunities. Those that build security in from the outset of the project gain a competitive advantage.
document.getElementById(“page”).classList.add(“newLayout”);
Want to see this in practice, or discuss an implementation for your company? Contact us – we respond within 48 hours.