No set of steering committee minutes ever records the line “we hereby approve a two-year expansion of our attack surface”. That is nevertheless what those meetings approve. A change freeze on SAP ECC for the duration of the programme. Production copies in project systems, because user acceptance testing without real data proves nothing. Emergency authorisations for the system integrator, valid “until cutover”. Go-live criteria that contain not a single security condition. Each decision is individually reasonable. Together they open a window that stays open for one to three years, which is how long an SAP S/4HANA conversion programme actually runs.
The calendar does not help either. SAP provides mainstream maintenance for SAP Business Suite 7 until 31 December 2027, with extended maintenance from the start of 2028 to the end of 2030 carrying a premium of two percentage points on the maintenance base. Start now and you have a little over a year. A year of runway means cutting scope, and security is the easiest thing to cut, because it blocks nobody.
In short:
1/ freezing functional change in SAP ECC does not freeze risk - SAP Security Patch Day ships monthly regardless of your programme plan,
2/ under RISE with SAP the customer raises the request for a technical Basis security patch and accepts the downtime, and no penetration test runs without SAP’s approval - both statements come from SAP’s own material, not from a security vendor,
3/ an ABAP Test Cockpit run aimed at conversion does not check code security, because the security checks ship with the separately licensed SAP Code Vulnerability Analyzer, and an SAP ERP licence does not carry over to SAP S/4HANA,
4/ non-production and production systems sit inside the same virtual network under RISE, for reasons SAP states plainly - and your conversion sandbox should know it.
Three sentences that sound sensible and are not true
“The system is frozen, therefore it is stable”
This is the most common assumption in conversion programmes and the most expensive one. SecurityBridge put it in January 2026 in a single sentence worth pinning to the project room wall: freezing functional changes does not equal freezing security risks. You froze business change. You did not freeze the vulnerability disclosure calendar.
Through that period the legacy landscape typically runs without continuous vulnerability assessment, nobody watches custom code, interfaces and RFC connections, and controls fall back to manual work. The “no changes allowed” policy meanwhile creates a sense of safety with nothing behind it. Your change freeze does not bind an attacker, and during that window your systems are more predictable than they have ever been.
“We are moving to RISE, so SAP owns security”
Under RISE with SAP the responsibility boundary moves. The responsibility itself stays where it was. SAP runs the data centres, the network, the virtual machines, the operating system, the HANA database, backups, round-the-clock monitoring and incident management at the technical layer. What remains yours is application configuration, user identity, roles and access control, the audit log, integrations, custom development and regulatory compliance.
None of that is a surprise; anyone who has worked with public cloud knows the shared responsibility model. The surprises are three details from SAP’s own published cybersecurity FAQ for SAP S/4HANA Cloud, Private Edition.
First. SAP patches the operating system and the database on its own schedule. For technical Basis security patching the roles change: SAP reviews the available patches and builds tested deployment bundles, but as the material states, the customer contractually initiates the request to deploy them and permits the downtime inside the maintenance window. Nobody applies a Basis patch to your system merely because it was released.
Second. Vulnerability and penetration testing is available at the application layer only, and only with SAP’s prior approval and authorisation. An independent test before go-live is therefore a scheduled item with weeks of lead time, not something a team squeezes into cutover week.
Third, and most interesting for architects. Development, QA and production systems sit inside the same virtual network. SAP gives the reason openly: software logistics, meaning transports and client copies, require it. That is design, not a flaw. It does mean your conversion project system is not an island. It is production’s neighbour.
“The technical conversion passed, so the system is secure”
Conversion testing asks whether the process closes, whether the document posts, whether the report returns the same figures. It does not ask whether the program doing that has an authority check. A green functional test is not evidence about security, and nobody ever claimed it was.
Four things a conversion multiplies
A conversion programme does not invent new classes of vulnerability. It multiplies and legitimises the ones that would otherwise be exceptions requiring sign-off.
Production copies. Acceptance testing without production data has no value, so the copies get made - usually several, across several environments, over more than a year. A copy carries more than the personal data your data protection officer sees. It carries RFC destinations, technical accounts and trust relationships. Project systems have looser roles, weaker oversight and rarely make it into monitoring.
The conclusion is worth stating plainly, because these two points are usually discussed separately. A production copy is not only a data protection topic. It is a system that can log in wherever the original could, with the same destinations and the same technical accounts, only with worse roles, no monitoring and an access list nobody outside the project approved. The risk is not that someone exfiltrates data from the sandbox. It is that someone enters through the sandbox and comes out inside a system that posts documents.
Privileged access with an expiry date nobody entered. The integrator, their subcontractors, service accounts, emergency authorisations “for the duration of the project”. These categories rarely have an owner on the customer side, and even more rarely an expiry recorded in the system rather than in the contract. SecurityBridge lists excessive authorisations among the things organisations carry into the new environment alongside the data, and it is right, because role cleanup during a programme has no milestone anywhere in the plan.
Custom code. Covered separately below, because it is the most misunderstood item on this list.
Those four mechanisms do not act evenly. The longest window is the frozen source landscape, and it usually has no owner, because the operations team is waiting for the new system while the project team is looking at the target. The most intense is cutover, where change control runs in emergency mode by definition. The most underrated are the first two weeks after go-live, which we come back to separately below.
Paths nobody monitors. Joris van de Vis of SecurityBridge made the point sharply in August 2026: in SAP, several technical routes lead to the same business outcome, and usually only one of them - the standard transaction - is monitored. The side routes are lesser-known transactions, transport mechanisms, custom development, interfaces and background processing. During cutover every one of them runs at full tilt while change control operates in emergency mode. His conclusion is simple and uncomfortable: control the outcome, not just the process.
“We ran ATC” - what that scan actually covered
This sentence is spoken at every conversion programme review, and it almost always means something other than what the listener assumes.
ABAP Test Cockpit provides the check infrastructure plus functional correctness and performance checks. Security checks come from SAP Code Vulnerability Analyzer, built on the same infrastructure but a separate, separately licensed product. The check variant that runs the analyser alone is SLIN_SEC. The variant your conversion team runs tests S/4HANA readiness and simplification items, because those block go-live. Code security blocks nothing, so it does not join the run by accident.
Three facts from SAP’s own material change the conversation inside a programme:
- licensing is per user, capped at one hundred users, and a user is anyone who reads the results of a scan, not only whoever triggers it,
- the analyser can be activated without a licence - the system displays a warning, and that is all,
- an SAP ERP licence does not carry over to SAP S/4HANA; a new one is required.
That last point is the critical one for a conversion programme, because it hits the organisations that were doing everything right. You scanned code on SAP ECC for years, you have a process, exemptions and history. After conversion you hold the same process and no licence, at precisely the moment your code base changed the most.
Three further limits deserve attention before anyone shows the board a green chart:
The first run produces thousands of findings. That is SAP’s own description. It is not an argument against scanning; it is an argument for agreeing triage, ownership and closure criteria before the scan runs rather than after.
Data flow analysis does not cross compilation units. Scan a report that calls a function module, and a vulnerability inside that module will not be found. You have to scan the module. A green result then describes the scope of the scan, not the state of the system.
A finding does not block a release. In the standard configuration, priority three findings do not stop a transport, and a product can be released with findings open. The tool will not make the risk decision for you. It only makes the decision a conscious one.
Cutover, and the two weeks nobody watches
Cutover is the one moment where all four mechanisms run at once. Inside a day or two the full set of transports ships, integrations are switched, technical accounts get new passwords or keep the old ones, and change control operates in a mode the team itself calls emergency. That is not negligence; it is what switching over a business-critical system looks like. The trouble starts with the sentence every organisation says at that point: “we are not rolling back, a rollback costs a week of downtime.”
In normal operations a transport with a missing authority check stops at a gate. During cutover it goes through, because the criterion is “does it activate”, not “is it safe”. The difference is not in the tooling. It is that for forty-eight hours the cost of stopping anything exceeds the cost of letting it pass.
Then comes the part that is even less documented. For the first two weeks after go-live the whole team watches performance, period close and whether documents post. Security monitoring of the new system is usually not fully live yet, because alerting rules get tuned “once things settle”. Which means the hottest period of the entire programme is also the only one you have no data from. If something happened during cutover, you will learn about it from a source other than your own audit log.
What belongs in your gate criteria
The cheapest change in the whole programme costs one sentence in a document that already exists. Phase gate criteria and go-live acceptance criteria are written down, agreed and signed. Four items simply need to appear there instead of remaining somebody’s private worry.
A baseline measured before the freeze. Configuration, authorisations and code in SAP ECC described in numbers on the day the change freeze starts. Without that snapshot you cannot prove a year later what you carried over and what you did not, and an auditor will ask.
A blocking threshold for code findings. Not “we will scan the code”, but: which priority stops a transport, who may grant an exemption and for how long. The tool will not stop a transport on your behalf.
Retirement of project access as a milestone. Emergency authorisations, integrator accounts and service accounts with an expiry recorded in the system rather than in the contract, and a post-cutover task to verify it.
Monitoring live before go-live, not after. Security audit log, event collection and alerting rules switched on and tested in the target system before the cutover weekend. If the first week of production is also the first week of monitoring, you have no data from the hottest period of the entire programme.
Above those four sits the ownership question. A conversion programme has a manager, an architect, process owners and an implementation partner. It rarely has anyone with a written right to stop go-live on security grounds. Where that person does not exist, the risk decision is being made by the schedule.
Where SecurityBridge fits
Stated plainly: SNOK is a SecurityBridge partner and we deploy the platform for clients. So we will be precise rather than promotional.
SecurityBridge does not replace SAP Code Vulnerability Analyzer and does not resolve licensing on SAP’s side. What it does cover is exactly the layer that remains yours under RISE with SAP: continuous vulnerability and configuration assessment, monitoring of user activity and interface traffic, custom code analysis and compliance framework alignment. Inside a conversion programme there are four sensible positions: a baseline of SAP ECC before the freeze, oversight of the frozen landscape during the programme, code and transport control through the project, and a comparison of target state against baseline before go-live. The fifth position starts the day after go-live and lasts as long as the system does.
One thing from us
We have just completed an implementation at one of the largest public institutions in Poland running SAP. Details to follow, within whatever the agreement allows. We mention it here deliberately: what is written above is not theory from a vendor deck, but the list of questions that has to be settled inside a real programme, with a real deadline and a real audit at the end.
The short version
An SAP S/4HANA conversion is not risky because someone neglected security. It is risky because every decision that opens it up is individually sensible. A change freeze protects stability. Production copies are the precondition for meaningful testing. Emergency authorisations let the integrator work. The conversion ATC variant unblocks go-live. RISE takes infrastructure off your plate. Each has a good reason, and none of them has a point in the plan where somebody asks what they add up to.
Which reduces the whole list to one question worth putting to your next steering committee: who in this organisation has the right to stop go-live on security grounds, and where is that right written down. If the answer is “nobody” or “not sure”, then the risk decision belongs to the schedule - and a schedule will not answer to the auditor.
Sources
- SecurityBridge, Jephy Pothen, Security by Design in the Age of S/4HANA and SAP RISE Migrations, 13 January 2026 - securitybridge.com
- SecurityBridge, Joris van de Vis, Breaking the Rules: Why Standard SAP Controls Are Not Enough, 20 August 2026 - securitybridge.com
- SAP Community, Jana Subramanian, RISE with SAP S/4HANA Cloud, Private Edition: Cybersecurity FAQ Explained - community.sap.com
- SAP Community, SAP Code Vulnerability Analyzer (CVA) - FAQs - community.sap.com
- SAP, Maintenance strategy - SAP S/4HANA and SAP Business Suite 7 - support.sap.com
The RISE with SAP responsibility split described here follows material published by SAP. In any individual contract the Roles and Responsibilities document and the contract terms govern - check yours before basing a decision on this.