CERT-EU’s advisory on SAP OVERPASS and S4GET identifies CVE-2026-44756, rated CVSS 10.0, and CVE-2026-58240, rated CVSS 9.8. The severity is important, but the business context is decisive for Swiss enterprises. SAP systems connect finance, procurement, manufacturing, logistics, identity and reporting. A rushed update can interrupt a production line; a delayed update can expose the controls that keep payments and operational data trustworthy.
Security leaders should therefore frame the response as an emergency change with a clear risk owner. The question is not whether the patch is inconvenient. It is whether the organisation can reduce exposure quickly while proving that segregation of duties, data integrity and recovery controls remain effective during the change.
Map the vulnerable path through the enterprise
Begin with the exact affected SAP products, versions, instances and deployment models. Include on-premises systems, private cloud tenants, development environments, disaster-recovery systems and interfaces managed by an integrator. A central configuration-management database may not show an older application server that still exchanges data with production.
Then map privilege and connectivity. Identify which components are internet-facing, reachable from partner networks, connected to identity services or trusted by business-critical applications. Trace administrator accounts, technical users, RFC connections, APIs and batch jobs. The same vulnerability has a different urgency on an isolated test system and a system that can influence payment files or production scheduling.
Ask suppliers for an impact statement that names affected releases, fixed versions, workarounds and indicators of compromise. Require the answer in writing and attach it to the change record. This gives procurement, audit and the board a common reference instead of a sequence of informal assurances.
◆ Key Takeaway
Critical SAP patching is a governance decision as much as a technical task. Swiss organisations should make exposure, downtime, privileged access and evidence visible in one controlled change record.
Patch without weakening control design
Emergency changes still need separation of duties. The person who prepares the technical change should not be the only person who approves it or validates the business result. For urgent remediation, use a shortened path with named substitutes, time limits and post-change review rather than bypassing approval entirely.
Coordinate with finance and operations before selecting the window. Freeze non-essential transports, confirm interface queues, notify plant or logistics owners and define a rollback decision point. Back up configurations and verify that recovery credentials are independent of the affected environment. For high-availability deployments, rehearse the sequence on a representative system if time allows, then verify each node rather than assuming the cluster is uniform.
Compensating controls can reduce risk while a patch is scheduled. Restrict administrative access, isolate affected services, disable unused interfaces and monitor privileged activity. Document the expiry of every temporary control. A workaround without an owner and deadline becomes a permanent exception that is difficult to defend during a resilience review.
Look for evidence of prior exploitation
Because these vulnerabilities affect trusted enterprise components, remediation should include a focused compromise assessment. Preserve SAP security logs, operating-system events, gateway records, privileged-user activity, configuration changes and relevant network flows. Record collection times and keep copies outside the potentially affected administration domain.
Hunt for new users, unexpected role assignments, altered interface destinations, unusual batch jobs, modified transport objects and access outside normal maintenance windows. Correlate SAP activity with identity-provider, endpoint and network telemetry. A clean patch result does not answer whether an attacker used the weakness before remediation.
If suspicious activity is found, pause normal recovery assumptions. Rotate exposed technical credentials, review connected systems and involve legal, privacy, insurance and regulatory contacts according to the impact. For a financial institution, evidence should also support operational-resilience reporting and demonstrate that critical services were restored with integrity, not merely availability.
Actions for Swiss SAP owners
- Inventory every affected SAP release, instance, interface, owner and deployment location.
- Prioritise internet-facing and highly privileged components before lower-risk development systems.
- Obtain vendor and integrator impact statements, fixed versions and compromise indicators.
- Approve an emergency change with segregation of duties, rollback criteria and a post-change review.
- Back up configurations and test recovery credentials outside the production trust boundary.
- Preserve logs and hunt for privilege, configuration, transport and interface anomalies.
- Report residual risk, temporary controls and verification evidence to operational-risk leadership.
The strongest response will be visible in the organisation’s evidence, not just in its patch dashboard. Swiss enterprises that connect SAP vulnerability management to change governance, business continuity and privileged-access review can move quickly without losing control. That capability will remain valuable long after these two CVEs leave the emergency queue.