Server patch management is the process of finding, testing, approving and installing updates on your Windows, Linux and Unix servers, then proving they were applied. Done well, it closes known vulnerabilities quickly without breaking production. This guide covers the server patching process, the best practices that matter most, and what to look for in server patch management software.
It is written for infrastructure and server teams in large or regulated organizations, where maintenance windows are tight, estates are mixed and auditors want evidence.
What is server patching?
Server patching means applying vendor updates to server operating systems and the software that runs on them. Updates fix security vulnerabilities, correct bugs and sometimes add features. Server patch management is the wider discipline around it: inventory, prioritization, testing, scheduling, deployment, verification and reporting.
Servers are harder to patch than laptops or desktops. The reasons are practical:
- No real “off hours.” Many servers run 24/7, so every reboot needs a scheduled window and an owner who agrees to it.
- Several operating systems. A typical estate mixes Windows Server with RHEL, Ubuntu or SUSE, and sometimes IBM AIX or Oracle Solaris. Each has its own update source and tooling.
- Many versions of each OS. Different releases need different patches and have different dependencies.
- Many stakeholders. Application owners, change boards and business units all have a say in when a server can go down.
- High cost of failure. A failed patch or a messy rollback on a production server affects customers and revenue, not one user.
- Isolated networks. Some of the most critical servers have no internet access at all.
When the process is manual, patching takes too much staff time and sometimes simply does not happen. Unpatched servers are the result, and they are what attackers look for.
The server patch management process
Most mature teams follow the same lifecycle, whatever tools they use:
| Step | What happens | Output |
|---|---|---|
| 1. Discover | Build and maintain an inventory of every server, its OS, version, owner and environment | A complete asset list |
| 2. Assess | Compare installed updates with available ones and map them to vulnerabilities (CVEs) | A gap list per server |
| 3. Prioritize | Rank by severity, exploitation status and server exposure | An approved patch list |
| 4. Test | Apply to test or QA servers and check the applications on top | Go/no-go decision |
| 5. Deploy | Roll out in stages within approved maintenance windows | Patched servers |
| 6. Verify and report | Re-scan, confirm compliance and keep evidence for audit | A compliance report |
The best practices below make each of these steps faster and safer.
Server patching best practices
1. Write a patch management policy
A written policy sets expectations before the next emergency. It should define patching frequency, target timeframes by severity, the types of updates in scope, roles and responsibilities, and how exceptions are approved and documented. Review it when your estate or your regulatory obligations change.
2. Keep an accurate server inventory
You cannot patch what you do not know about. Pull server data from your hypervisors, cloud accounts and directory services, and record the owner and maintenance window for each server. Group servers by environment (dev, QA, staging, production) and by application so you can target patches precisely.
3. Prioritize by risk, not by release date
Not all patches are equal. Patch first where a vulnerability is critical, the server is exposed, and the flaw is being actively exploited. The CISA Known Exploited Vulnerabilities catalog is a useful public input for that last question. Feeding vulnerability scanner results into your patch tool helps you rank work the same way your security team does.
4. Test before you deploy
Patches can conflict with applications or other system components, and the problem often shows up only after deployment. Reduce that risk:
- Pilot each update on test servers that match production versions.
- Identify dependent systems and applications that an update could affect, and test them too.
- Confirm installation requirements, such as disk space, reboots and prerequisites, for each OS version.
- Automate testing where you can, so the team is not stuck in a weekend-long patching scramble.
5. Use standard maintenance windows, and plan for emergencies
Downtime is expensive and erodes trust. Agree standard maintenance windows with application owners for routine updates. Rotate rollouts between environments, for example development one week and production the next. Tell affected users in advance, and make sure backups or snapshots exist for anything that could be affected.
Also write a separate process for out-of-band (emergency) updates: how to identify affected servers, who approves the patch and reboot, and how much testing is acceptable when time is short.
6. Roll out in stages
Move updates from QA to staging to production instead of patching everything at once. Set success criteria for each stage, such as a target compliance rate on the previous group, before you advance. If something goes wrong, the blast radius stays small.
7. Check servers before the window opens
Many patch failures have nothing to do with the patch. The server is offline, credentials have expired, the disk is full or the server points at the wrong update source. Running pre-flight checks before the maintenance window lets you fix these problems in advance instead of discovering them afterwards.
8. Have a rollback plan
Decide in advance how you will reverse a bad update for each OS. That may be a snapshot, a package transaction rollback or a boot environment. Make sure the previous package versions are still available in your repository so a rollback can succeed.
9. Verify compliance in real time
A rollout is not complete until you can show how many servers are actually patched. Patch compliance is the share of servers that have received required updates or have a documented exception. Check it during the maintenance window, not days later, so you can fix failures while the window is still open. Track the trend over time to see whether your process is improving.
10. Centralize and automate
Updates come from many sources: Microsoft, each Linux distribution, Unix vendors and third-party software. Collecting them by hand from vendor sites and repositories can become a full-time job. A central server patch management platform that covers every OS you run, on-premises and in the cloud, removes that work and gives you one view of compliance.
Windows Server patching
Microsoft releases security updates for Windows Server on Patch Tuesday, the second Tuesday of each month, with out-of-band releases when needed. For years, most on-premises teams have approved and distributed these updates through Windows Server Update Services (WSUS).
Microsoft now lists WSUS as no longer actively developed. Existing capabilities continue to work, so this is a planning question, not an emergency. Server teams generally have two sensible paths:
- Keep WSUS and add governance on top. Use a platform that integrates with your existing WSUS for approvals, maintenance windows, reporting and third-party application updates.
- Replace WSUS. Use a platform with its own update repository, so there is no WSUS server to maintain.
You do not have to choose on day one. Many teams start with their existing WSUS and pilot a replacement on a small group of servers. Our guide to WSUS deprecation options compares the paths in more detail, and WSUS replacement options shows how JetPatch supports both.
Linux and Unix server patching
Linux servers use native package managers (YUM or DNF, APT, Zypper) and vendor repositories. For compliance, it helps to patch at the advisory level, for example Red Hat RHSA, RHBA and RHEA errata, so you can show which advisory and CVE were remediated rather than only that a package was updated. Local repository mirrors keep patch content consistent across servers and reduce bandwidth during the window. See Linux patch management for how this works with JetPatch.
AIX and Solaris still run critical workloads in energy, finance, government and telecom. They are often patched by hand with SUMA, NIM or IPS commands and tracked in spreadsheets, which leaves a gap in compliance reporting. Bring them into the same process and reports as Windows and Linux wherever possible.
Patching air-gapped and isolated servers
Servers in production plants, clinical networks, energy control systems and classified environments are often isolated by design. They still need patches, and frameworks such as ISO 27001, NIS2 and PCI-DSS still expect evidence that they are patched on a defined cadence.
Manual methods such as USB drives and ad-hoc scripts are slow and hard to audit. A sound process brings verified updates to the servers instead of bringing the servers to the internet:
- Collect updates on the connected side, from official vendor sources only.
- Verify the integrity of every update before it enters the isolated zone.
- Use one controlled path into the isolated network.
- Approve, schedule and stage deployments inside the isolated network.
- Record approvals and installations automatically, so the audit trail exists when patching finishes.
For more on this, see air-gapped patch management.
Server patch management software: what to look for
Server patch management tools range from free vendor utilities to full enterprise platforms. Common options include WSUS for Microsoft updates, Microsoft Configuration Manager (SCCM) as part of a broader device management suite, Azure Update Manager for Azure and Arc-connected servers, and dedicated patch management platforms. Each fits a different situation. Use these questions to compare them:
| Requirement | Questions to ask |
|---|---|
| OS coverage | Does it patch every OS you run, including AIX and Solaris if you have them? |
| Windows update layer | Can it work with your existing WSUS, replace it, or both? |
| Deployment model | Does it run on your own infrastructure, or does patch data go through a vendor cloud? |
| Isolated networks | Can it patch fully air-gapped servers with verified updates? |
| Governance | Does it support approvals, maintenance windows, staged rollouts and ITSM change gates? |
| Pre-flight checks | Does it find failing servers before the window opens? |
| Rollback | Which operating systems support rollback, and how? |
| Reporting | Can it produce audit-ready compliance reports by OS, environment and policy? |
If ConfigMgr is used only for server updates in your environment, a server-focused platform is often the simpler fit. Keep ConfigMgr where you use its full suite.
How JetPatch helps
JetPatch is installed software that runs on your own infrastructure, on-premises or in your private cloud tenancy. It patches Windows Server, eight Linux distributions, IBM AIX and Oracle Solaris from one console.
- Windows, your choice. JetPatch integrates deeply with your existing WSUS, including bidirectional group sync and third-party application patching through the WSUS pipeline. Or it replaces WSUS with the JetPatch repository. See Windows patch management.
- Linux at the advisory level. RHSA, RHBA and RHEA errata with CVE correlation, managed local repositories, optional pre-download before the window, and transaction-based rollback on supported distributions.
- Air-gapped servers. Offline Windows Patching delivers digitally verified updates to isolated servers with no new internet exposure, and local Linux repositories serve isolated Linux servers.
- Fewer failed patches. Endpoint Readiness and Predictive Patching flag offline servers, credential issues, low disk space and misconfigured repositories before the window opens.
- Governed rollouts. Remediation Plans with maintenance windows and SLA tracking, Sequence Patching from QA to production, and optional ServiceNow or Jira change approval.
- Audit evidence. Compliance reports by OS, environment and plan, exported to CSV and PDF.
FAQ
What is server patching?
Server patching is applying vendor updates to server operating systems and software to fix security vulnerabilities and bugs. Server patch management adds the process around it: inventory, prioritization, testing, scheduled deployment, verification and reporting.
How often should servers be patched?
Most teams patch on a monthly cycle aligned with vendor releases, such as Microsoft Patch Tuesday. Critical or actively exploited vulnerabilities should be handled faster through an out-of-band process. Your policy should set target timeframes by severity.
What are the most important server patching best practices?
Keep an accurate inventory, prioritize by risk, test before deploying and roll out in stages within agreed maintenance windows. Check servers for problems before the window opens, have a rollback plan, and verify compliance as soon as the rollout finishes.
Do I need to replace WSUS to patch Windows servers?
No. WSUS is no longer actively developed, but its existing capabilities still work. You can keep WSUS and manage it through a platform such as JetPatch, or replace it with the JetPatch repository when you are ready.
Can one tool patch Windows, Linux and Unix servers?
Yes. JetPatch patches Windows Server, major Linux distributions, IBM AIX and Oracle Solaris from one console with one compliance view. That replaces separate tools and separate reports for each OS.
How do you patch servers without internet access?
Collect updates on a connected system, verify their integrity, and move them into the isolated network through one controlled path. Then deploy and record them inside that network. JetPatch Offline Windows Patching and local Linux repositories automate this for air-gapped servers.
Want to see how this works on your own servers? Request an evaluation and run JetPatch on a pilot group of Windows, Linux or Unix servers, connected or air-gapped.
