Most server intrusions exploit a flaw that already had a fix for weeks. The gap is rarely the patch itself. It is the routine around it: who applies updates, how you learn that a reboot is due, and what you do when an update breaks something.
A distribution's security repository holds fixes only, with no new features, so the risk of breaking your application is small and the risk of skipping them is large. Let them run daily without anyone clicking. A new major version of PHP, PostgreSQL or Node.js is different: it is an application change that deserves staging, a date and a note in the change log. On Debian and Ubuntu the line between the two sits in Allowed-Origins; on RHEL it is upgrade_type = security. Automatic security fixes plus manual feature upgrades is the compromise that holds up.
A kernel patch that is installed but not booted protects nothing: the old kernel keeps running until the next restart. The same goes for glibc, which almost every process loads. needrestart lists the services that still map replaced libraries and tells you whether a full reboot is due. Schedule that reboot for a quiet hour, tell your customers, and check afterwards that every service came back. If you truly cannot reboot, Ubuntu Livepatch or kpatch on RHEL applies some kernel fixes in memory. With two servers behind a load balancer, reboot one at a time.
For entities registered with DNSC under OUG 155/2024, the Romanian transposition of NIS2 approved by Law 124/2025, vulnerability handling is part of the minimum risk-management measures, and after an incident you will be asked when the patch was published and when you applied it. For any company that processes personal data, a server breached through a flaw that had been fixed for months is hard to defend before ANSPDCP under GDPR Article 32. The log that unattended-upgrades writes on its own is the simplest evidence you can keep.
| Update type | How it is applied | Restart needed | Staging first |
|---|---|---|---|
| Security patch for packages | Automatic, daily | Only the affected service (needrestart) | Optional |
| Kernel, glibc, systemd | Automatic, with a planned reboot | Full reboot or livepatch | Recommended |
| New version of PHP, PostgreSQL, Node.js | Manual, planned | The service | Mandatory |
| Docker image | Rebuild in CI and roll out | The container is replaced | Mandatory |
# /etc/apt/apt.conf.d/50unattended-upgrades (fragment)
Unattended-Upgrade::Allowed-Origins {
"${distro_id}:${distro_codename}-security";
};
Unattended-Upgrade::Remove-Unused-Dependencies "true";
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "03:30";
# /etc/apt/apt.conf.d/20auto-upgrades
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";sudo dnf install -y dnf-automatic
# /etc/dnf/automatic.conf (fragment)
[commands]
upgrade_type = security
apply_updates = yes
sudo systemctl enable --now dnf-automatic.timerapt list --upgradable
sudo unattended-upgrade --dry-run
sudo needrestart -bEvery package was current, yet the server had not rebooted in fourteen months and still ran an old kernel with known flaws. needrestart also showed PHP-FPM using a replaced library. A planned reboot at 03:00 on a Tuesday took two minutes.
dnf-automatic was applying every update, including a new MariaDB minor release that changed a sorting rule and broke a report. The team switched to security-only updates and now applies feature upgrades once a month, on a staging copy first.
Patching customer servers by hand left some of them months behind. A weekly list of pending updates per server, plus a rule that critical fixes go out the same day, closed the gap without adding anyone to the on-call rota.
For flaws that are being exploited right now, the same day, even with an unplanned restart. For everything else, a daily automatic run is enough. What matters is knowing which category you are in, so follow your distribution's advisories and, if you have NIS2 duties, the DNSC bulletins.
Rarely, as long as you limit them to the security repository. The real risk comes from feature upgrades applied automatically and from reboots nobody checks. Keep a snapshot before each maintenance window and a simple check in the morning that your services answer.
Compare the installed version, shown by apt policy or dnf info, with the fixed version named in your distribution's advisory, which carries the CVE identifier. For a larger estate, a vulnerability scanner run on a schedule does that comparison for you.
A production server starts getting attacked within minutes of receiving a public IP address, however small the project is. This guide ranks the controls by impact, from SSH access to incident response, with the Romanian rules that apply along the way. Every topic has its own page with a short answer, examples and ready-to-use configuration.