Patch Management & Maintenance Windows

Patch Management and Maintenance Windows

Unpatched software is one of the most common ways attackers get in — not through exotic zero-days, but through vulnerabilities with fixes available for weeks or months. Patching is also one of the most common ways operations teams cause their own outages: an update changes a library's behavior, a reboot does not come back cleanly, or every server in a pool restarts at once. Patch management is the process that balances those risks: knowing what you run, deciding what to patch first, testing updates in stages, applying them in controlled windows, verifying health, and proving compliance.

The goal is a routine so dependable that urgent patches — the critical vulnerability exploited in the wild — can be rolled out in days or hours without heroics.

TL;DR

Start with an accurate inventory of systems, operating systems, packages, and firmware.
Prioritize by severity, active exploitation (such as CISA's KEV catalog and EPSS scores), and exposure, not CVSS alone.
Roll out in rings: test, pilot, then broad deployment, with health checks between stages.
Use maintenance windows and change approval for planned work, and an expedited path for emergencies.
Automate patching with rolling batches, load balancer draining, reboots only when needed, and post-patch verification.
Prefer immutable infrastructure where possible: rebuild images and replace instances instead of patching in place.

Quick Example

A rolling patch run with Ansible that drains each server, updates packages, reboots only when required, and waits for the application to be healthy before continuing:

serial: "20%" limits each batch to a fifth of the pool, and max_fail_percentage: 0 stops the run at the first unhealthy host. See Ansible.

Core Concepts

Inventory

You cannot patch what you do not know exists. Maintain an inventory of physical and virtual servers, cloud instances, containers and base images, network devices, endpoints, and their operating system versions, installed packages, and firmware — ideally collected automatically by agents or cloud APIs. Tie each asset to an owner and an environment. See IT Asset Management.

Prioritization

Define patch timelines by risk tier, for example: actively exploited and exposed within days; critical within two weeks; others in the monthly cycle. See Vulnerability Management.

Patch Rings

Each ring waits a defined soak period and passes health checks before the next starts. Emergency patches compress the rings rather than skipping them entirely.

Maintenance Windows and Change Control

Maintenance windows are pre-agreed times when disruption is acceptable — chosen around business cycles, time zones, and on-call coverage. Routine patching under a standard change process with pre-approval keeps the cadence reliable; emergency changes follow an expedited approval. Communicate windows to stakeholders and tie them to the change calendar. See Change Management.

Many organizations align with vendor schedules — Microsoft releases security updates on the second Tuesday of each month — and plan out-of-band handling for urgent releases.

Reboots and Live Patching

Kernel and core library updates require reboots or process restarts to take effect. Detect when reboots are needed (needs-restarting -r, /var/run/reboot-required), schedule them in windows, and restart services that still use old libraries. Live patching (kpatch, Canonical Livepatch, and similar) applies some kernel fixes without rebooting, reducing urgency but not eliminating periodic reboots.

Tooling

Immutable Infrastructure

For cloud and container workloads, the cleanest patch is a replacement: build a new machine image or container image with updated packages, test it, and roll it out with the normal deployment process, retiring old instances. This makes rollback a redeploy of the previous image, keeps servers identical, and turns patching into a CI pipeline. Long-lived servers that cannot be replaced still need in-place patching.

Verification and Reporting

Post-patch checks: application health endpoints, service status, error rates, and key business transactions.
Compliance reporting: percentage of assets patched per severity tier within target timelines, and exceptions with owners and expiry.
Metrics: mean time to patch by severity, patch coverage, failed patch rate, and reboot compliance.

Best Practices

Patch Continuously, Not Annually

Small, regular updates are safer than infrequent large ones. A monthly rhythm with a fast lane for exploited vulnerabilities keeps both risk and disruption low.

Design for Rolling Maintenance

Redundant instances behind load balancers, drain procedures, and health checks let patching happen during business hours without downtime.

Keep a Rollback Plan

Snapshots, package version pins and downgrade procedures, or previous images make reverting a bad patch quick.

Track Exceptions Explicitly

Systems that cannot be patched need documented exceptions, compensating controls, owners, and review dates — not silent omission.

Common Mistakes

Patching Everything at Once

Prioritizing by CVSS Alone

Updates Without Restarts

FAQ

What is patch management?

The process of identifying, prioritizing, testing, deploying, and verifying software updates across systems to fix vulnerabilities and bugs while minimizing disruption.

How quickly should critical patches be applied?

Actively exploited vulnerabilities on exposed systems should be patched within days; other critical issues commonly within two weeks; and lower-risk updates in the regular monthly cycle. Exact targets depend on policy and regulation.

What is a maintenance window?

A pre-scheduled period when changes that may cause disruption, such as patching and reboots, are allowed — chosen to minimize business impact and ensure staff are available.

What are patch rings?

Groups of systems that receive updates in sequence — test, pilot, broad, then sensitive — so problems are found on a small group before they affect everything.

Is immutable infrastructure better than patching servers?

For workloads that can be rebuilt automatically, yes: replacing instances with freshly built images is more consistent and easier to roll back. Systems that cannot be replaced still require in-place patching.