A Patching Cadence for Servers, Firewalls and Hypervisors

Unpatched software is the door ransomware crews walk through when phishing fails. The problem in most small and mid-size companies is not that nobody patches. It is that workstations get Windows Update and everything else gets patched when someone remembers. The firewall, the hypervisor and the backup server are exactly the things that get forgotten and exactly the things that matter.

A cadence is a written rule for how fast each layer gets patched and who does it. Here is one that works without a dedicated team.

Two clocks: emergency and routine

Every patch falls into one of two clocks. The emergency clock starts when a vendor publishes a critical advisory for something you expose to the internet or that an attacker on the LAN could use to take over the domain. The routine clock is the monthly window for everything else.

The mistake is treating everything as routine. A VPN appliance vulnerability that is being exploited in the wild cannot wait for the third Saturday.

Emergency, within 72 hours: internet-facing firewalls and VPNs, remote access gateways, public web servers, anything with an actively exploited CVE per the CISA Known Exploited Vulnerabilities catalog.
Emergency, within 7 days: hypervisors, domain controllers, backup servers and Exchange when the advisory is critical.
Routine, monthly: Windows and Linux servers, applications, agents, drivers and firmware without a critical advisory.
Routine, quarterly: switches, access points, out-of-band management controllers (iDRAC, iLO), UPS network cards, printers.

Servers: the monthly window

Pick a fixed window and keep it. Second Tuesday is Microsoft's release day; patching servers the following weekend gives a few days for early reports of broken updates to surface. Announce the window to the business once, then stop asking permission every month.

Use a tool that reports, not just installs. WSUS is free and still works. Intune and Windows Autopatch cover Entra-joined servers and workstations. Third-party RMM platforms add Linux and application patching. Whatever you use, the report of what is missing is the deliverable.

Snapshot or confirm a fresh backup before the window. A snapshot older than the window is not a rollback plan.
Patch in order: domain controllers one at a time, then application servers, then the file server. Reboot each and confirm the service is up before the next.
Hold one server back for a day if the update touches something fragile, such as Exchange, SQL Server or a line-of-business application with its own patch notes.
Reboot. A patch installed without a reboot is not applied, and 'pending reboot' servers accumulate silently.
Record what was installed and what was skipped. The skipped list becomes next month's first item.

# Windows: what is pending, and does the box need a reboot?
Get-WindowsUpdate -MicrosoftUpdate -IgnoreReboot | Select-Object KB, Title, Size
(Get-Item 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired' -ErrorAction SilentlyContinue) -ne $null

# Ubuntu / Debian
sudo apt update && apt list --upgradable
[ -f /var/run/reboot-required ] && echo 'reboot required'

Firewalls and VPNs: the 72-hour clock

Edge devices are the highest-value target and the least-patched device in most networks, because patching them means a maintenance window with an outage and because nobody is subscribed to the advisory feed. Fix the second problem first and the first one becomes routine.

Subscribe to your vendor's PSIRT mailing list and to CISA's KEV catalog. When an advisory lands for hardware you own, it goes on the emergency clock regardless of what else is happening.

Keep the firewall on a supported firmware branch. Vendors stop shipping fixes for old branches, and a firewall on end-of-life firmware cannot be patched at all.
Take a configuration backup before every firmware update and store it off the device.
If you run a high-availability pair, patch the secondary, fail over, patch the primary. If you run a single unit, schedule after hours and have console access ready.
After patching, verify: VPN reconnects, NAT rules present, logging still forwarding, MFA still enforced.

Hypervisors and management planes

The hypervisor is one layer below everything you care about. A vulnerability there hands the attacker every VM at once, and hypervisors are routinely skipped because patching them means moving or pausing workloads. Build that into the plan rather than around it.

VMware ESXi, Hyper-V and Proxmox all publish advisories and all support rolling updates in a cluster. A standalone host needs a window where the VMs are down or migrated to a temporary host.

ESXi: use Lifecycle Manager with a baseline of critical patches, put the host in maintenance mode, remediate, exit. Check hardware compatibility for the target build before starting.
Hyper-V: patch the host through the same monthly cycle as other Windows servers. Use Cluster-Aware Updating in a cluster; on a standalone host, save-state the VMs and reboot.
Proxmox: apt update and apt dist-upgrade from the enterprise or no-subscription repository, then reboot when a new kernel is installed. Migrate VMs first in a cluster.
Firmware and BIOS: schedule alongside the hypervisor update, since both need a reboot. Dell, Lenovo and Supermicro all publish update catalogs.

Frequently asked questions

What if an update breaks something?

That is what the snapshot and the ordered rollout are for. Restore the snapshot, note the KB or build number, and exclude it until the vendor ships a fix. Patching one server at a time means the break is one server, not all of them.

We have a legacy application that only runs on an unsupported OS. How do we handle that?

Isolate it. Put the server on its own VLAN with firewall rules allowing only the specific clients and ports it needs, remove internet access, and treat it as already compromised for planning purposes. Then put a replacement date on the calendar.

Who should own the cadence?

One named person with a calendar reminder and a report to send. If nobody inside can own it, this is a common piece of a managed services agreement; RackLedge handles the full cadence including edge and hypervisor layers for its clients.

Takeaway

Write down the two clocks, subscribe to the advisory feeds, and give every layer an owner and a window. Servers monthly, edge devices within 72 hours of a critical advisory, hypervisors and firmware on the same schedule. The rule is simple; keeping it is the work.