What Are SAP Patch Days?

Patch days (also sometimes referred to as patch Tuesdays/update Tuesdays) serve as critical checkpoints for users and system administrators alike.

Microsoft established patch Tuesday in 2003, which designates the second Tuesday of each month as the release date for security patches. This standardized approach allows software vendors, most prominently Microsoft, Adobe, and SAP, to deliver updates that address newly discovered vulnerabilities in their products. These vulnerabilities, if left unaddressed, can be exploited by malicious actors to gain unauthorized access to systems, steal sensitive data, or disrupt operations.

Patch Tuesdays proved to be significantly beneficial. By centralizing the release of updates, patch Tuesdays provide a predictable schedule for IT professionals to plan, test, and deploy patches across their networks. This helps to streamline the update efforts and minimize downtime. Additionally, patch Tuesdays raise awareness about security vulnerabilities, prompting users and administrators to prioritize installing the updates to mitigate potential threats. The consolidated release schedule also fosters collaboration within the cybersecurity community, allowing security researchers to analyze the patches and identify any potential issues before widespread deployment.

However, patch Tuesdays also come with certain challenges. The sheer volume of updates released on a single day can overwhelm IT teams, especially in larger organizations with diverse software landscapes. Testing and deploying these updates can be a time-consuming process, potentially leading to delays and increasing the window of vulnerability. Throughout the following sections, we’ll go over the release of patches by SAP and how to react to this release cycle with a proper process in place to review SAP Security Notes. We’ll also discuss patch days for operating systems.

SAP Security Patch Day

When it comes to SAP, since September 2010, all security patches have been released on the second Tuesday of the month. This has helped Basis teams focus their patching efforts in a predictable way. Looking at the historical numbers (see figure below), we can see the average number of SAP Security Notes released by SAP on any given patch day; for example, since July 2013, the number is 20.2, meaning that, on average, SAP customers will get approximately 20 SAP Security Notes to address.

If we calculate the average of SAP Notes before July 2013, the number increases to 60. The reason for this is that on July 8, 2013, SAP changed its policy for which vulnerabilities will be released as a SAP Security Note and which will be fixed through a support package regular update (not security).

According to SAP there are two distinct types of SAP Security Notes:

• Patch day security note: SAP Security Note that solves vulnerabilities that were reported by external sources/researchers and that were found internally and have a CVSS of 9.0 and higher. These SAP Security Notes are released the second Tuesday of every month.
• Support package security note: Any vulnerability found internally and with a CVSS lower than 9.0 will be part of the support package but not released as individual SAP Security Notes.

This distinction is important for understanding the stable volume of patches that SAP has been releasing over the past years to help its customers focus their time on the vulnerabilities that imply a higher risk.

Reviewing SAP Security Patch Day

As software vendors such as SAP adopt this coordinated disclosure of patches, organizations need to prepare to adopt these updates, analyzing them to decide which vulnerabilities should be patched and the proper timing (critical vulnerabilities might be patched ASAP, whereas lower criticality vulnerabilities might be pushed to a later time).

If done manually, users would have to review each one of the SAP Security Notes and compare the information of the note with all the systems in the SAP landscape, which could be in the hundreds.

This is where vulnerability management comes into play because whatever mechanism we use to assess the security of our SAP applications should consider timely detection of released SAP Security Notes. That makes it possible to quickly identify if there are systems that are exposed to recently patched security vulnerabilities.

Patch Days for Operating Systems

As mentioned before, SAP adhered to the coordinated released of security patches practice, which was started by Microsoft in 2003. Microsoft’s embracing of this approach coincided with updates that affect Microsoft Windows Server, a potential building block for SAP applications. Eventually, other operating system vendors also adopted the coordinated release of security patches (but not all of them), and it became a well-known practice for software vendors to do the scheduled release. In this section, we’ll revisit some of the nuances of applying operating system patches to operating systems running SAP applications.

While SAP systems are the core of many businesses, we must recognize that they operate within a broader IT infrastructure, most of the time reliant on underlying operating systems such as Windows or Unix/Linux. These systems also require regular patching to address vulnerabilities.

Many organizations have a well-established routine for applying SAP patches on designated SAP patch days. However, this focus can inadvertently overshadow the importance of patching the underlying operating systems. Even if you have a perfect SAP patching process, neglecting these updates to the underlying operating system can expose your entire IT environment to significant risks.

It’s important to adopt a holistic approach that includes regular patching of all system components, including operating systems. By aligning your operating system patch schedules with SAP patch days or aligning independent schedules, you can create a more robust security posture.

Next, we’ll explore some of the nuances of applying operating system patches for SAP systems running on Windows-based operating systems and Unix/Linux-based ones.

Microsoft Patch Days

In the case of SAP running on Windows, SAP recommends promptly applying all released security patches, incorporating the proper changes, which will most likely be kernel-related patches, which may potentially require a downtime window.

To streamline the patch deployment process, consider implementing automated patch management solutions. These tools can automatically download, test, and deploy updates, minimizing manual intervention and reducing the risk of human error. Additionally, thoroughly testing patches in a controlled environment before deploying them to production systems can help mitigate unexpected issues.

Windows Server Update Services (WSUS) is a useful solution for automating patch deployment in Windows environments. By acting as a central repository for updates, WSUS allows administrators to manage and distribute Microsoft updates to client computers within their network. This eliminates the need for manual intervention and ensures that all systems are up-to-date with the latest security patches and critical fixes.

WSUS synchronizes with Microsoft Update servers, downloading the latest updates and categorizing them based on their importance and target operating systems. Administrators can then create approval rules to automatically approve or reject specific updates, tailoring the deployment process to their specific needs. Once approved, updates can be deployed to target groups of computers using various scheduling options, allowing for flexible and controlled rollout.

WSUS also provides robust reporting and monitoring capabilities, enabling administrators to track the status of updates, identify issues, and generate detailed reports for compliance and auditing purposes.

Unix/Linux Patch Days

Unlike Microsoft, Unix and Linux vendors typically release security updates on an ad hoc basis, as vulnerabilities are discovered and patched. This approach can make it challenging to maintain a consistent patching schedule. To address this, it’s essential to establish a proactive monitoring and response strategy.

Stay informed about the latest security advisories and bulletins from your specific Unix or Linux vendor. Subscribe to security mailing lists, RSS feeds, and other notification channels to receive timely updates. Implement a robust vulnerability scanning process to identify and prioritize critical vulnerabilities.

When deploying patches, carefully consider the potential impact on system stability and performance. Thorough testing is crucial to avoid unexpected downtime or service disruptions. If possible, schedule patches during off-peak hours or during maintenance windows to minimize the risk of business disruption.

Conclusion

Patch days are essential for keeping SAP systems and their underlying operating environments secure. By understanding SAP’s monthly release cadence and prioritizing the most critical Security Notes, organizations can streamline their patching efforts and reduce risk.

At the same time, SAP applications rely on operating systems that also require consistent updates. Treating patching as a holistic process (covering both SAP and the OS layer) helps ensure a stronger, more resilient security posture. With clear processes, proper testing, and the right automation tools, teams can manage patch days efficiently and stay ahead of emerging vulnerabilities.

Editor’s note: This post has been adapted from a section of the book Cybersecurity for SAP by Gaurav Singh and Juan Perez-Etchegoyen. Gaurav is an SAP cybersecurity manager at Under Armour with more than 19 years of experience and a proven track record of helping organizations protect themselves from cyber threats while maximizing their SAP investments. Juan is the chief technology officer at Onapsis. With more than 20 years of experience in the IT security field, JP is a leading expert in business-critical application security, specializing in safeguarding ERP landscapes.

This post was originally published 12/2025.