Skip to content
atlas

Patch management

Also known as: update management

The routine of keeping all software up to date so that known weaknesses are closed before attackers use them.

Draft - this entry has not been reviewed yet.

Formal

The repeated process of finding out which patches exist for the organisation's software, ranking them by risk, testing them, installing them within a set time and confirming they took effect.

In plain English

Like a car recall - the fault is known and a fix exists, but it only helps once each car is actually brought in.

In practice

A serious weakness in the VPN used by a pension fund is announced on Tuesday; the IT operations manager tests the fix that night and has every VPN device updated by Thursday, as the fund's 72-hour rule demands.

Why it matters

Once a weakness is made public, attackers race to use it; many real attacks, including ransomware, succeed simply because a fix was available but never installed.

How to put it into practice

The usual steps, in order. Adapt them to your organisation.

  1. Name an owner for patching each asset type, including outsourced systems, and write the responsibility into contracts with IT suppliers.
  2. Keep a complete inventory of hardware, operating systems, applications and firmware, so you know what needs patching.
  3. Set deadlines by risk in a patch policy, for example emergency patching within days for exploited flaws on internet-facing systems and a monthly cycle for the rest.
  4. Check vendor advisories and the CISA KEV catalogue every day, and match new vulnerabilities against the inventory.
  5. Prioritise by known exploitation, internet exposure and asset criticality, not by CVSS score alone.
  6. Test patches on a pilot group, roll them out in rings to everyone else, and turn on automatic updates wherever it is safe.
  7. When a patch cannot be applied, mitigate by changing configuration, isolating the system or virtual patching, and record a risk acceptance with an owner and an expiry date.
  8. Verify installation with vulnerability scans, and replace or isolate end-of-life software that no longer receives updates.
  9. Report coverage, time to patch and overdue exceptions to management every month.

Common pitfalls

  • Patching only Windows on Patch Tuesday and forgetting firmware, network devices, browsers and third-party software.
  • Treating VPN gateways and firewalls like any other system, although attackers often exploit flaws in them within days.
  • Assuming a deployed patch is installed without checking it with a scan.

Good guides

Technical deep dive

NIST SP 800-40 Rev. 4 (2022) reframes patching as preventive maintenance and recommends that organisations define a small number of maintenance plans by asset type and risk rather than treat each patch as a project. It distinguishes routine patching on a regular cadence from emergency patching for vulnerabilities that are actively exploited or critical on exposed systems, and adds two alternatives when no patch can be applied: mitigation (configuration changes, virtual patching at an IPS or WAF, isolation) and risk acceptance with a documented owner and expiry. A patch cycle typically runs: intake from vendor advisories and vulnerability feeds, applicability matching against the asset and software inventory, prioritisation, testing, staged deployment in rings (a pilot group, then broad deployment), verification, and exception handling.

Prioritisation has moved beyond CVSS base scores, which describe technical severity but not likelihood. Common inputs now include CISA's Known Exploited Vulnerabilities (KEV) catalogue, which US federal agencies must act on under Binding Operational Directive 26-04 (June 2026, replacing BOD 22-01), with a deadline for each CVE set by the asset's exposure, KEV status, whether exploitation can be automated and the technical impact, as short as three days for an internet-facing asset with an automatable KEV that gives total control; the Exploit Prediction Scoring System (EPSS) from FIRST, which estimates the probability of exploitation in the next 30 days; internet exposure; and asset criticality. Time-to-exploit for publicised vulnerabilities has fallen to days in many cases, so edge devices - VPN concentrators, firewalls, file-transfer appliances - are generally treated as emergency-class regardless of internal SLAs.

Operational realities complicate the cycle. Microsoft releases security updates on the second Tuesday of each month (Patch Tuesday), but third-party applications, browsers, firmware (BIOS/UEFI, BMC, network devices) and container base images follow their own rhythms. Reboots, maintenance windows and application compatibility create lag; medical and OT systems may be certified only for specific versions and require vendor approval. End-of-life software receives no patches at all and must be isolated or replaced. Tooling is shifting toward cloud-managed services, and Microsoft announced in 2024 that WSUS is deprecated, with no new feature development. In containerised environments the unit of patching is the image: fixes are applied by rebuilding from an updated base and redeploying, not by patching running containers.

Metrics that auditors and boards ask for are coverage (share of assets reporting patch status), mean time to remediate by severity, and SLA compliance, with exceptions tracked explicitly. The control anchors are CIS Controls v8 Control 7 (Safeguards 7.3 and 7.4 on automated OS and application patching), ISO/IEC 27002:2022 control 8.8 (management of technical vulnerabilities) and NIS2 Art. 21(2)(e) on vulnerability handling. Patch management is complementary to vulnerability scanning, which verifies that patches actually landed, and to hardening, which removes components that would otherwise need patching.

What to learn first

Everything this builds on, foundations first.

  1. Patch
  2. →Threat
  3. →Vulnerability
  4. →CVE and CVSS
  5. →Patch management

Relationships

Sources & further reading

Standards & official texts

  • NIST SP 800-40 Rev. 4 - Guide to Enterprise Patch Management Planning · NIST
  • CIS Critical Security Controls v8 - Control 7 · Center for Internet Security

Course material

  • Cyber Security Fast Track - Ordliste

Where this data comes from

This entry was drafted by an AI from the sources above and has not yet been checked by a person. Treat it as a starting point, and check anything important against the sources.

See the review queueSuggest a correction on GitHubThis term as JSON

Check yourself

Loading…

Atlas is in beta.