Glossary · simply explained

Patch management

Patch management closes vulnerabilities before attackers exploit them — prioritised, tested and demonstrable.

Patch management is the orderly process of assessing, testing and rolling out software updates — for operating systems, applications, firmware and network devices. Its purpose is twofold: close security gaps before they are exploited, and keep systems stable and supportable.

The urgency has sharpened: between publication of a vulnerability and its mass exploitation often lie only days, for critical gaps in edge devices hours. Unpatched reachable systems — VPN gateways, firewalls, Exchange — are among the most common entry points of real attacks.

The process: from advisory to rollout

Effective patch management starts with visibility: a current inventory of all systems including version states. New patches are prioritised by risk — exploitability (is the gap in the KEV catalogue of actively exploited vulnerabilities?), exposure (reachable from the internet?) and system criticality count for more than the raw CVSS score.

Then follows the staged rollout: testing on reference systems, pilot group, broad distribution — with rollback plan and defined maintenance windows. Critical, actively exploited gaps need an emergency path that runs these stages in hours instead of weeks. What cannot be patched promptly (legacy, OT) is protected compensatingly: segmentation, virtual patching via WAF/IPS, access restriction.

Metrics and pitfalls

Measure time to patch per risk class — critical/exposed in days, not months.
Patch compliance rate: what percentage of systems is at target state?
Plan for blind spots: appliances, firmware, hypervisors, IoT — not just Windows.
Document and compensate exceptions, do not tolerate them silently.

Frequently asked questions about Patch management

How fast must a critical patch be applied?

For actively exploited gaps on exposed systems: within 24 to 72 hours, with an emergency change if necessary. Risk-based deadlines have proven themselves as a framework — say 72 hours for critical/exposed, 14 days for high, 30 days for medium. What matters is that deadlines are defined and measured.

Patching or availability — which weighs more?

That is the classic operations trade-off, and it resolves through process: tested staged rollouts, maintenance windows, redundancy for non-disruptive patching. The statistics are unambiguous: outages from exploited old gaps cost orders of magnitude more than planned maintenance windows.

What to do with systems that cannot be patched?

Compensate: segment strictly, restrict access to the necessary minimum, put virtual patching via WAF or IPS in front, sharpen monitoring. Legacy and OT systems are the main reason microsegmentation belongs in patch strategies — it makes the unpatchable manageable.

What is the difference between patch and vulnerability management?

Vulnerability management finds and assesses weaknesses (scanning, prioritisation), patch management fixes them. Both interlock: the scanner delivers the work list and afterwards measures whether the patch works — together they form the cycle of find, fix, verify.

Do network devices belong in patch management too?

Imperatively — firewalls, routers, VPN gateways and load balancers face the internet and are preferred targets; several of the most-exploited gaps of recent years hit exactly this device class. Managed network contracts should explicitly govern firmware states and patch deadlines.