Postponed updates leave publicly known vulnerabilities open on your systems. This article covers managing operating system, application and network device patches through prioritisation, testing and staged rollout.
In many businesses, updates are postponed with the thought "everything is working, let's not touch it now". Yet the release of a security fix also means the flaw is now public knowledge; from that moment, unpatched systems become easier targets. Patch management means neither applying updates at random nor putting them off indefinitely, but handling them in a planned way with a way back if something goes wrong.
What is a patch, and why is delay risky?
A patch is an update the manufacturer releases to fix a bug or a security vulnerability in software or a device. Not all updates are alike: security patches close a known vulnerability, bug fixes improve stability, and feature updates bring new functions and involve more change. This distinction decides how quickly each should be applied.
The cost of delay grows over time. As pending updates pile up, finding the cause becomes harder if a problem appears when they are finally applied together. Some vulnerabilities are exploited even before a fix is released; these are called "zero-day" vulnerabilities. In such cases, following the manufacturer's interim mitigation advice and applying the patch quickly once it is out matter even more.
The scope is not just computers
Operating systems
Staff computers, servers, phones and tablets belong to this group. Even with automatic updates switched on, an update may have been downloaded but not applied because the device has not been restarted. Computers that run for weeks without being shut down, and laptops that have not connected to the office network for a long time, need separate attention in this respect.
Applications
Browsers, office applications, PDF readers, file compression tools, remote access programs and accounting or ERP clients also need regular updates. Most of these are not updated along with the operating system; they have their own update mechanisms and must be tracked separately. Browser extensions belong on this list too. Removing applications you don't use is an easy way to reduce the amount of software that needs updating.
Network devices and firmware
Firmware is the software embedded in a device that runs and controls it. Firewalls, modems, switches, wireless access points, network storage devices (NAS), printers, IP cameras, the management card of an uninterruptible power supply (UPS) and servers' BIOS/UEFI all fall into this group. These devices often do not update themselves and can run for years on the version they were installed with.
Devices with a management interface exposed to the internet, or that provide remote access (VPN), are the highest priority; attackers frequently target known vulnerabilities in them. Before a firmware update, back up the device's configuration and read the release notes. A power cut during the update can leave some devices unusable, so carry it out at a planned time with the device on a UPS.
What should come first?
Treating every update with the same urgency is neither realistic nor free of unnecessary disruption. When setting priorities, ask: Is the affected system exposed to the internet? Do manufacturer or security agency advisories say the vulnerability is being actively exploited? Does the system hold critical or personal data? What is the vulnerability's severity? (Severity is usually expressed as a score from 0 to 10.)
| Priority | Example situation | Example approach |
|---|---|---|
| Urgent | An actively exploited vulnerability in an internet-facing firewall, VPN or email server | Within a few days, with unplanned maintenance if needed |
| High | Operating system, browser and office application security patches on staff computers | In the regular monthly cycle, after a short pilot |
| Normal | Feature updates, non-critical bug fixes | In planned maintenance, after testing |
The timings in the table are examples; set your own according to your risks and resources, and put them in writing. What matters is that each priority has a target time and that cases where it is exceeded stay visible.
Testing, staged rollout and rollback
Rather than pushing an update to everyone at once, proceed in stages. First choose a pilot group of a few users representing different kinds of work: one person each from accounting, production and sales, for example. If business applications, printers and special hardware work without problems in the pilot group, apply the update to the remaining users, and then to servers in a maintenance window.
On servers, make sure a current backup exists before updating. On virtual servers, taking a snapshot beforehand allows a quick rollback; but a snapshot is not a substitute for a backup and should be deleted once the work is done. Announce the maintenance time to affected users in advance. On systems that back each other up, update them one after the other, not at the same time.
Think about rollback before updating: Can this update be uninstalled? Returning to a previous firmware version may not be possible on every device. It should also be clear who decides, and at what point, to roll back if a problem appears.
The final step is verification. An update showing as "deployed" in the management tool does not mean it has been installed on every device. Check failed installations, devices waiting for a restart and computers that have not reported in for a long time separately.
Testing should not become an excuse to postpone updates indefinitely. Set a date for the wider rollout in advance in case the pilot group shows no clear problems; if problems do appear, check the manufacturer's known-issues list and recommended workarounds.
Software and devices at end of support
Every piece of software and every device has an end-of-support date. After that date, the manufacturer no longer releases security patches. The device or program keeps working, but newly discovered vulnerabilities are no longer closed; however good your patch management is, these systems become the weakest link over time.
Know end-of-support dates in advance and reflect replacement in the budget. For systems that cannot be replaced right away, such as an old accounting application or a computer attached to a production machine, limit the risk: move them to a separate network segment, block their internet access and allow access only to the people and devices that need it. Some manufacturers offer paid extended support for certain products; this can buy time for a migration but is not a permanent solution.
A similar trap is halting updates for compatibility reasons. Not updating computers because a business application does not work with the new version only postpones the problem. Ask the application's vendor for a timeline for a compatible version and record the dependency as a known risk.
Practices that make it easier
Fixing a set week of the month for updates helps both users and IT be prepared. Not letting users postpone restarts indefinitely, making sure remote laptops can receive updates without connecting to the VPN, and using a central management tool that shows the update status of devices on one screen all reduce the effort involved. A short monthly report is enough: how many devices are up to date, which are behind, and why each exception exists.
Checklist
- Are all computers, servers, mobile devices, applications and network devices included in update tracking?
- Are priority levels and target times for security patches written down?
- Are critical vulnerabilities in internet-facing devices and services handled first?
- Are updates tried on a pilot group first and then rolled out in stages?
- Are backups and configuration copies taken before server and network device updates?
- Are failed installations and devices waiting for a restart checked regularly?
- Are software and devices at end of support known, with a replacement plan or additional safeguards?