Linux Patch Management: Process, Deadlines and Evidence

Want security updates on your Linux servers applied on a predictable schedule? Linux server management covers updates in maintenance windows with evidence. CVE monitoring reports new vulnerabilities affecting the versions you run.

Security updates for Linux distributions are published almost daily. Installing them with apt upgrade or dnf upgrade is quick. The difficult part is the questions before and after: which updates are urgent, which can wait for the next maintenance window, when does the server need a reboot, and how do you prove to customers, auditors or under NIS2 that the process works?

This guide describes the process in six steps, deadlines by criticality with their sources, automation with unattended-upgrades and dnf-automatic, handling kernel updates and documentation for audits.

Contents

• What Linux patch management covers
• The process in six steps
• Deadlines by criticality
• Automatic updates: unattended-upgrades and dnf-automatic
• Kernel updates, livepatching and reboot windows
• Containers and software outside the package manager
• Evidence for audits and NIS2
• Our approach at WZ-IT
• Status and methodology

What Linux patch management covers

Patch management covers more than the distribution's packages. A typical server has several layers that are updated separately:

A process that only covers the first layer leaves the others unprotected. This is the most common finding in organically grown environments.

The process in six steps

The German BSI IT-Grundschutz describes the requirements in module OPS.1.1.3 Patch and change management: a concept, defined responsibilities, controlled auto-update mechanisms and prompt assessment and prioritisation of patches (BSI OPS.1.1.3, edition 2023, German). In practice this results in six steps:

1. Inventory: which servers, distributions, releases, package sources, containers and applications exist? Without an inventory no vulnerability can be mapped to a system.
2. Monitor sources: security advisories of the distributions (Debian Security, Ubuntu Security Notices, Red Hat errata), vendor advisories for third-party repositories and vulnerability databases such as the NVD.
3. Assess and prioritise: severity, active exploitation, exposure of the system, existing safeguards. This determines the deadline.
4. Test: apply updates to a test or less critical system first, node by node in clusters. Define a rollback path, for example a snapshot or backup.
5. Apply: in the maintenance window or, for critical flaws, out of schedule. Then check reboot requirements and test functionality.
6. Document: what was installed on which system and when, what was deliberately not installed and why? The BSI requires decisions against a patch to be documented with reasons (OPS.1.1.3.A15).

NIST describes four scenarios in SP 800-40 Rev. 4, each of which should have its own procedure: routine patching, emergency patching, emergency mitigation before a patch is available, and unpatchable assets, for example after end of life (NIST SP 800-40 Rev. 4). For systems without updates see the guide Linux end of life.

Deadlines by criticality

There is no generally binding deadline in days for companies. The BSI speaks of "promptly", the NIS2 Implementing Regulation (EU) 2024/2690 of "within a reasonable time". Concrete deadlines are set in your own policy. Three criteria support them:

• Severity by CVSS: the specification rates scores as follows: 0.1 to 3.9 low, 4.0 to 6.9 medium, 7.0 to 8.9 high, 9.0 to 10.0 critical (FIRST CVSS v3.1).
• Active exploitation: the Known Exploited Vulnerabilities (KEV) catalog of the US agency CISA lists flaws that are demonstrably being attacked. For US federal agencies, deadlines have been set since June 2026 by BOD 26-04, which replaces BOD 22-01: they depend on KEV listing, internet exposure, whether exploitation can be automated and how much control it grants; the shortest deadline is three days, less urgent cases get two weeks (CISA BOD 26-04, BleepingComputer). This is not binding for companies, but it is a useful benchmark.
• Exposure: a service reachable from the internet is more urgent than an internal service behind VPN and firewall.

A policy can derive levels like these. The values are a starting point and are adjusted to protection requirements and operating windows:

What matters is that the deadline is documented and met. A short deadline that is regularly missed is harder to defend in an audit than a realistic deadline with clean evidence.

Automatic updates: unattended-upgrades and dnf-automatic

Debian and Ubuntu: the unattended-upgrades package installs updates from defined sources automatically. On Ubuntu Server it is installed by default and applies security updates once a day; updates from -updates and -backports are not enabled by default (Ubuntu Server docs). On Debian it is usually installed but may be missing or disabled depending on the installation and is enabled with dpkg-reconfigure unattended-upgrades (Debian Wiki). It only reboots automatically if Unattended-Upgrade::Automatic-Reboot is set to true; according to the Ubuntu documentation the default is false.

RHEL, AlmaLinux, Rocky Linux: dnf-automatic is controlled through /etc/dnf/automatic.conf and systemd timers. Red Hat documents the timers dnf-automatic-notifyonly.timer (report only), dnf-automatic-download.timer (download) and dnf-automatic-install.timer (download and install) (Red Hat documentation). With upgrade_type = security, installation is limited to updates with a security advisory (dnf-automatic).

Automation makes sense for low-risk security updates. It does not replace verification: whether updates actually ran, whether services are running after the update and whether a reboot is pending belongs in monitoring.

Kernel updates, livepatching and reboot windows

A new kernel only takes effect after a reboot. Libraries such as OpenSSL or glibc only take effect when the services using them are restarted. Pending restarts are shown by:

• Debian and Ubuntu: the needrestart tool, which detects running processes using outdated libraries (Debian Wiki), and on Ubuntu additionally the file /var/run/reboot-required.
• RHEL family: dnf needs-restarting -r reports whether a reboot is required (documentation).
• All: comparing uname -r with the most recently installed kernel version.

Livepatching applies selected kernel fixes at runtime. Canonical Livepatch is part of Ubuntu Pro, covers kernel vulnerabilities rated high or critical and is free for personal use on up to 5 machines. Canonical states explicitly: "Canonical Livepatch is not a replacement for rebooting" (Ubuntu Livepatch). Red Hat delivers live patches for RHEL through kpatch, each for a specific kernel build. Livepatching moves the reboot into a planned window but does not replace it.

Reboot windows are therefore agreed in advance, for example monthly outside business hours. In clusters and redundant services, nodes are rebooted one after another so the service stays available.

Containers and software outside the package manager

• Containers: an apt upgrade on the host does not update containers. Images must be pulled again and containers recreated. Pinned image versions instead of latest make updates traceable.
• Third-party repositories: vendor repositories for Docker, PostgreSQL or Node.js have their own cycles and security advisories that are tracked separately.
• Applications: CMS, groupware and self-compiled software have their own update mechanisms. BSI module SYS.1.3 calls for a documented, reproducible installation for software compiled from source (BSI SYS.1.3, edition 2023, German).

Evidence for audits and NIS2

In section 30, the German BSI Act obliges important and essential entities to take risk management measures, including under subsection 2 no. 5 security measures in the acquisition, development and maintenance of IT systems, components and processes, including vulnerability management and disclosure. Compliance must be documented (section 30(1)) (section 30 BSIG, German). For certain digital services, such as cloud and data centre services and managed service providers, Implementing Regulation (EU) 2024/2690 specifies in point 6.6 of its annex that security patches are applied within a reasonable time and how justified exceptions are handled (Implementing Regulation (EU) 2024/2690).

Solid evidence contains:

• Policy: deadlines per level, maintenance windows, responsibilities, exception rule
• Inventory: systems, releases, package sources, end of support
• Log per maintenance: installed packages with version, timestamp, reboots performed, functional test
• Exceptions: patches not installed with justification, safeguard and review date
• Metric: share of systems without open security updates older than the deadline

The package managers provide the raw data: /var/log/apt/history.log on Debian and Ubuntu, dnf history on the RHEL family.

Our approach at WZ-IT

Within Linux server management from 149.90 euros net per server per month we apply updates in agreed maintenance windows and document operations per server. Monitoring runs 24/7, and backups with up to 250 GB of storage per server are included. Response to P1 incidents follows the booked service level.

CVE monitoring matches new vulnerabilities from the NVD, vendor advisories and the distributions' security trackers against the software inventory and prioritises them by CVSS score. We assess exposure, exploitability and affected systems; the service level governs response, not a blanket patch-completion deadline. Where the starting point is unclear, work begins with the server audit from 290 euros net one-time. How reachable your systems actually are is shown by a vulnerability scan with OpenVAS.

Further guides

• Linux end of life: end of support and options for systems without updates
• Linux server hardening: checklist with CIS and BSI as references
• Linux server maintenance checklist: patch cycles as part of ongoing maintenance
• Linux kernel vulnerabilities 2026: patch management using current kernel flaws as an example

Status and methodology

• Collected: 26 October 2026.
• Frameworks: BSI IT-Grundschutz Compendium edition 2023 (OPS.1.1.3, SYS.1.3), NIST SP 800-40 Rev. 4 (April 2022), CVSS v3.1, CISA BOD 26-04 (replaces BOD 22-01), section 30 BSIG, Implementing Regulation (EU) 2024/2690.
• Tools: default behaviour according to vendor documentation from Canonical, Debian and Red Hat for RHEL 9.
• Example deadlines: our own derivation from the criteria above, not a requirement of any framework.

Sources

• BSI IT-Grundschutz OPS.1.1.3 Patch and change management (edition 2023, German)
• BSI IT-Grundschutz SYS.1.3 Linux and Unix servers (edition 2023, German)
• NIST SP 800-40 Rev. 4: Guide to Enterprise Patch Management Planning
• FIRST: CVSS v3.1 specification
• CISA BOD 26-04: Prioritizing Security Updates Based on Risk
• dnf-automatic and dnf needs-restarting
• Section 30 BSI Act (German)
• Implementing Regulation (EU) 2024/2690
• Ubuntu Server docs: Automatic updates
• Debian Wiki: UnattendedUpgrades
• Red Hat: Automating software updates in RHEL 9
• Ubuntu Livepatch
• Debian Security Information and Ubuntu Security Notices