On August 12th, we hosted a webinar exploring how autonomous patching can reduce downtime, accelerate remediation, and strengthen SAP cyber resilience.
For SAP environments, patching is a fundamental part of managing cyber risks, limiting exposure to known vulnerabilities, and maintaining secure and reliable systems. However, the process can be complex and resource-intensive, particularly in hybrid and distributed environments with extensive dependencies and integrations.
Kernel updates, HANA revisions, Host Agent updates, SAP Security Notes, operating system (OS) patches, and other infrastructure changes demand careful coordination across teams, from approvals and testing to maintenance windows and post-change validation. This creates a persistent challenge for organizations seeking to deploy critical security fixes quickly without disrupting the availability of business-critical systems.
In this fifth session of the Rise of SAP Autonomous Cyber Operations webinar series, IT-Conductor CEO and Co-Founder Linh Nguyen discussed how organizations can rethink that tradeoff by combining resilient SAP architecture with automated, dependency-aware patch orchestration.
One of the central points of the webinar was that zero downtime is not a realistic requirement for every SAP component.
Instead, the presentation divided patching into three categories:
The distinction becomes clearer when looking at individual components.
Figure 1: SAP Patching Downtime Matrix
SAP Host Agent, SAP Web Dispatcher, SAP Cloud Connector, SAProuter, and ABAP application servers can be patched live when the required redundancy or traffic-management capabilities are available. SAP kernel updates, central services (ASCS/ERS), HANA primary databases, and SAP Gateway or ICM can typically be reduced to minimal downtime through rolling updates, high availability, or takeover procedures.
Some changes remain more difficult to perform live. Major SAP kernel upgrades, standalone HANA revision upgrades, OS kernel updates without live-patching capabilities, firmware and BIOS changes, hypervisor upgrades, and single-instance environments may still require maintenance windows.
The webinar highlighted that patching downtime depends on both the component being updated and whether the SAP environment is designed with the redundancy, failover, and high-availability capabilities needed to minimize disruption.
High availability is typically associated with protecting SAP systems from unexpected failures. The webinar extended that idea to planned maintenance.
If an SAP landscape already includes redundant capacity, failover mechanisms, and health checks, those same capabilities can be used to keep services available while individual components are patched.
Figure 2: SAP Architecture for Resilient Patching
The reference architecture presented in the webinar included a global load balancer, redundant SAP Web Dispatchers, multiple application servers, an HA ASCS/ERS cluster, HANA system replication, and an HA pair of Cloud Connectors. The underlying principles were to avoid single points of failure, maintain redundant capacity for SAP services, shift traffic away from components being patched, and validate system health before failover or progression.
This changes the way patching is approached.
Rather than taking an entire SAP environment offline for a single maintenance event, individual components can be removed from service, patched, validated, and returned before the process moves to the next component.
For example, a Web Dispatcher can be removed from the load balancer, patched and restarted, health checks performed, and then returned to service. An application server can have logons disabled, existing sessions drained, the kernel updated, and health checks performed before logons are re-enabled.
Resilient architecture creates the conditions for minimal-downtime patching, but architecture alone does not determine which patches should be applied, in what order, or whether the environment is ready for the next change.
The webinar described SACO as bringing together three capabilities: intelligence, dependency mapping, and autonomous orchestration.
Figure 3: How SACO Orchestrates SAP Patching
The first phase begins with collecting SAP Security Notes, HANA revisions, kernel patches, SAP Host Agent updates, Cloud Connector updates, OS CVEs, hypervisor patches, and firmware advisories.
That information is then correlated with what is actually deployed, including installed versions, the running kernel, component inventory, exposure, internet accessibility, and business criticality.
The objective is to move beyond a generic list of available fixes and determine which patches are relevant to the environment and where remediation should be prioritized.
The second phase recognizes that SAP components cannot be patched in isolation.
Kernel versions, database revisions, database clients, application servers, JVM components, enqueue and message servers, backups, and system replication can all introduce dependencies that affect whether a change can proceed safely.
Before execution, SACO maps prerequisites, incompatible revisions, sequencing requirements, compatibility considerations, and rollback points. This dependency-aware approach allows the patching process to be planned as a complete sequence rather than a collection of independent technical tasks.
Once the dependencies are understood, SACO can execute component-specific playbooks.
Each playbook follows the sequence appropriate to the component.
For example, a Cloud Connector can fail over to its secondary instance before the primary is patched. A Web Dispatcher can be removed from the load balancer before maintenance begins. Application servers can be drained and updated one at a time.
The orchestration process therefore extends beyond automating installation. It coordinates failover, traffic management, patch execution, restart procedures, validation, and return to service as part of a single workflow.
A key part of the SACO model is that completing a patch does not automatically mean moving on to the next step.
Before advancing, the system validates the environment across four layers.
Figure 4: Autonomous Patching Validation
Infrastructure checks include CPU, memory, disk, and network health. SAP checks cover processes and services such as disp+work, the Message Server, Gateway, ICM, RFC connectivity, background jobs, and the lock table. Database validation covers replication, log shipping, backups, and alerts. Business-level checks can include login, Fiori launchpad access, reports, RFC pings, IDocs, OData, and representative transactions such as VA01 or ME23N.
The workflow proceeds only when those validations pass.
If a health check fails, the patch follows a predefined rollback process. The system rolls back the change, revalidates the environment, and notifies the appropriate team rather than leaving the next action to be determined during an active maintenance window.
This makes validation and rollback part of the patching workflow itself rather than activities performed after the technical change is complete.
The webinar also presented a five-level SACO Patching Maturity Model to illustrate how organizations can progressively reduce downtime.
Figure 5: SACO Patching Maturity Model
At Level 1, patching is manual and downtime may be measured in hours. Level 2 introduces automated installation, reducing downtime to approximately 30–60 minutes. Level 3 uses rolling application servers to bring that range down to approximately 5–15 minutes. Level 4 combines HANA replication with automated takeover, reducing downtime to less than two minutes. At Level 5, autonomous patch orchestration, health validation, and rollback extend across the SAP landscape, with downtime ranging from seconds to approximately two minutes depending on the component.
The maturity model shows that autonomous patching can be introduced progressively rather than through a single, all-or-nothing transformation. Organizations can advance by identifying where manual processes, architectural constraints, and gaps in automation contribute to downtime, then addressing those areas over time.
The webinar concluded by bringing the core elements of autonomous patching together into a broader SACO reference architecture. It connects discovery, risk correlation, dependency-aware change planning, resilient execution, automated validation, and continuous assurance into a single remediation lifecycle.
Figure 6: SACO Reference Architecture
Rather than treating patching as an isolated technical task, the architecture is designed to account for what is deployed, which vulnerabilities are relevant, how changes should be sequenced, and what must be validated before the process moves forward. Resilient execution is a key part of that approach. Rolling restarts, clustered services, load balancing, and HANA system replication allow individual components to be patched while workloads shift to available capacity. Automated health checks then verify both technical and business functionality after each change, and if a validation fails, the workflow follows a predefined rollback process before revalidating the environment. Continuous assurance completes the cycle by recording evidence, updating baselines, and recalculating cyber risk after remediation.
On March 12, we hosted a webinar featuring IT-Conductor ChAI™ (Change Automation Intelligence for SAP), our newest advancement in SAP transport...
We’re excited to announce that IT-Conductor FLUX™ is now available on the SAP® Store, delivering automated system refreshes for SAP NetWeaver and...
On June 24th, we hosted a webinar exploring autonomy in SAP cybersecurity, from detecting risks to remediating and verifying closure.