Get this wrong and every command below it is suspect. RHEL 8, 9, and 10 all run DNF 4. On RHEL 10.2, dnf --version reports 4.20.0 and the real binary is /usr/bin/dnf-3. DNF 5 is Fedora’s default, not RHEL’s. Every command in this post is DNF 4 syntax. Do not copy Fedora instructions onto a RHEL box.
What did change in RHEL 10: modularity is gone. There are no module streams in RHEL 10, so dnf module enable and dnf module reset are dead weight on a 10 box. Anything that used to be a stream is now an ordinary package.
dnf update and dnf upgrade are the same command. Both install every available update. The difference that matters is what you filter it with, which is the next section.

Start with the list, not the install. dnf updateinfo gives the summary — how many security, bugfix, and enhancement notices are pending. dnf updateinfo list updates security lists the security ones with their advisory IDs and severities, and dnf updateinfo list security --installed shows what is already on the box. Read one advisory in full with dnf updateinfo info RHSA-2026:1234.
Then pick the scope. dnf update installs everything. dnf update --security installs only packages with a security advisory. dnf update --bugfix installs only bug fixes. One advisory only: dnf update --advisory=RHSA-2026:1234, or one CVE only: dnf update --cve=CVE-2026-12345. One severity only: dnf update --sec-severity=Important — the levels are Critical, Important, Moderate, Low. And dnf upgrade-minimal --advisory=RHSA-2026:1234 installs the smallest version that fixes that advisory, not the newest version in the repo. Red Hat’s security updates guide documents all of these.
Make it scriptable. dnf check-update --security exits 100 when security updates are available, 0 when there are none, and 1 on error. Wire that into whatever watches the fleet, and a box that has not been patched stops being invisible.
Do not trust --security blindly. It is only as good as the advisory metadata in the repos the box is pointed at. If the metadata is stale or missing, --security installs nothing and exits happy, and nothing in the output tells you it missed anything. Look at the dnf updateinfo counts first. Zero advisories on a box unpatched for a month is a repo problem, not a clean bill of health.
And know what --security is for. It buys time during an incident — patch the critical CVE now, do the full update in the window. It is not a patching policy. A box that only ever gets --security drifts, and the eventual full update becomes the big, scary one you were avoiding.

Install it, then read the config before you enable anything. dnf install dnf-automatic — the package exists on RHEL 8, 9, and 10. Its behaviour lives in /etc/dnf/automatic.conf, in the [commands] section. Out of the box it downloads updates and reports them, and installs nothing: apply_updates = no.
Pick a timer, and understand that the timer wins. The package ships four: dnf-automatic-download.timer downloads only, dnf-automatic-install.timer downloads and installs, dnf-automatic-notifyonly.timer reports only, and dnf-automatic.timer follows whatever automatic.conf says. The named timers override the config file — enabling the install timer installs updates even if the config still says apply_updates = no. Enable the one you mean: systemctl enable --now dnf-automatic-install.timer.
Limit it to security, on purpose. In [commands], upgrade_type = security restricts the run to packages with a security advisory; default takes everything. On a server you do not babysit, security-only is the defensible choice.
The reboot setting is where the versions split. On RHEL 9 and 10, reboot = never is the default, when-needed reboots only when the run replaced something that needs it, and when-changed reboots after any applied update. The default reboot command is shutdown -r +5 — five minutes, no further confirmation. On RHEL 8 the reboot option does not exist at all; the setting is silently ignored, so an RHEL 8 box will install updates and never reboot, whatever the config says. Check what your dnf actually is with rpm -q dnf before you rely on it.
Production rule, stated plainly: never let dnf-automatic install on production. Notify-only or download-only on production, install on dev and staging, and let a human — or a canary ring, in Part 4 — decide when production moves. An unattended install at 06:00 with a reboot five minutes later is how a quiet Tuesday becomes an incident.

Versionlock is the precise tool. Install the plugin — one package name on all three releases: dnf install python3-dnf-plugin-versionlock. (RHEL 7 uses yum-plugin-versionlock instead; see the ELS note at the end.) Then dnf versionlock add kernel pins the installed version, dnf versionlock add kernel-5.14.0-362.18.1.el9 pins a named version, dnf versionlock list shows what is pinned, dnf versionlock delete kernel releases one, and dnf versionlock clear releases them all. The locks live in one plain-text list file on all three releases: /etc/dnf/plugins/versionlock.list — set by locklist in /etc/dnf/plugins/versionlock.conf. (The /etc/yum/pluginconf.d/versionlock.list path in older articles is RHEL 7’s yum plugin, not DNF’s.)
Exclude is the blunt tool. In /etc/dnf/dnf.conf, under [main], exclude=kernel* blocks matching packages from every transaction, from every repo, with no record in dnf versionlock list and no expiry. It is the right tool for exactly one job: skipping one bad release while everything else moves.
When each is appropriate: versionlock when a vendor certifies a version — a kernel a storage driver is built against, a database version an application is qualified on. Exclude when one release is broken and you need it gone today. Neither is a substitute for the discipline in Part 4: every pin gets a reason, an owner, and an expiry date, because a pinned package silently misses security fixes.

What it is: kpatch applies simple security and bug fixes to the running kernel through the kernel’s livepatch subsystem — no reboot, no process restart. What it is not: a kernel upgrade. It covers a defined class of fixes, for selected Important and Critical CVEs, and Red Hat is explicit that live patching does not address all critical or important CVEs.
Subscribe, do not hand-install. dnf install kpatch for the utility, then dnf install kpatch-dnf and dnf kpatch auto — that subscribes every installed kernel to the live patching stream, and every kernel installed in future, to cumulative patches. Each patch contains all the fixes of the ones before it, so there is nothing to pick between. If you must patch one kernel by hand, dnf install "kpatch-patch = $(uname -r)" installs the patch module for the running kernel only.
Verify it the same way every time. kpatch list shows loaded patch modules marked [enabled] and installed ones beneath. An empty patch package — version 0-0, meaning no live patches exist for that kernel yet — does not appear in kpatch list at all; check it with rpm -qa | grep kpatch instead. On RHEL 10.2 and later, kpatch list also reports the CVEs each loaded patch fixes. And remember: uname -r does not change after a live patch — the kernel version on disk is not the kernel version in memory, and a live patch moves neither of them.
The coverage window is the part people get wrong. On RHEL 10, kpatch support starts at 10.2 — the first supported kernel is kernel-6.12.0-211.16.1.el10_2, and older minor releases are not eligible at all. With a standard subscription, live patches for a minor release stop when the next minor release ships: 10.2 patches stop when 10.3 arrives. On RHEL 8 and 9, live patches are provided for six months after a kernel errata release, and Extended Update Support is what stretches that window. No third-party live patches are supported, ever — only the modules Red Hat ships. And do not run SystemTap or kprobe tooling during or after loading a patch; the patch may not take effect until the probes are removed. Red Hat’s live patching guide and the kpatch support KB are the two pages to read before you enable it.

Install the tool first — it is not on minimal images. dnf install dnf-plugins-core provides needs-restarting on RHEL 8, 9, and 10. Then, after any update, dnf needs-restarting -r answers the only question that matters: exit code 1 means a reboot is needed, exit code 0 means it is not. The output names what forced it — usually kernel-core, glibc, or systemd.
Without -r it answers a different question. Plain dnf needs-restarting lists the processes still running with old libraries mapped in memory — restart those, not the box. dnf needs-restarting -s lists services to restart instead. On RHEL 9.4 and later, dnf needs-restarting --reboothint also flags a reboot for a CPU microcode update.
The rule, without exceptions worth naming: kernel, glibc, systemd, microcode — reboot. Everything else — restart the service. And check the kernel you are actually running: uname -r against rpm -q kernel. If they differ after an update, the new kernel is on disk and the old one is in memory. Every patch run ends with dnf needs-restarting -r, and the exit code decides the next step — not a human deciding from memory whether a glibc update needs a reboot.

Satellite changes what the patching unit is. A content view is a curated subset of repositories plus errata filters — the set of packages a group of hosts is allowed to see. You publish a version of the view, then promote it along lifecycle environments, typically Library to Dev to QA to Production, and each environment’s hosts see only the content that has been promoted to them. Patching a fleet stops being “run dnf on two hundred boxes” and becomes “promote a content view version” — hammer content-view version promote --content-view <name> --version <version> --organization-label <label> --to-lifecycle-environment <env> — where --version is the version number, not the version ID (--id is the alternative) — and the canary ring in Part 4 is just the Dev and QA environments doing their job.
Insights tells you what is unpatched before the auditor does. insights-client ships on RHEL 9; register a host with insights-client --register and check it with insights-client --status, and the console flags known issues, available advisories, and configuration drift across the fleet.
Neither tool patches anything by itself. Satellite decides what content a host may install; Insights decides what a host should install. The install is still dnf, still in a window, still followed by needs-restarting -r. Fleet tooling moves the decision up a level. It does not remove the decision.

RHEL 7 is out of full support. What remains is Extended Lifecycle Support, a paid add-on with a fixed end — check the lifecycle page before promising anything about a RHEL 7 box, because the dates are the whole conversation.
The commands are yum, not dnf. yum updateinfo list security, yum update --security, and yum install yum-plugin-versionlock for pinning. The concepts in this post transfer; the command names do not.
kpatch is not provided under ELS. No live patches are released during Extended Life Phase or with the ELS add-on. If a RHEL 7 box is still in production, the patching conversation is a migration conversation — and the sooner it happens, the cheaper it is.

Look: dnf updateinfo list updates security — then dnf update --security, or --advisory=RHSA-... for one advisory.
Automate: dnf install dnf-automatic, upgrade_type = security, enable dnf-automatic-install.timer — RHEL 8 has no reboot option, RHEL 9/10 do.
Pin: dnf install python3-dnf-plugin-versionlock, then dnf versionlock add <package> — exclude= in dnf.conf is the blunt tool.
Live patch: dnf install kpatch-dnf, dnf kpatch auto, verify with kpatch list — RHEL 10 kpatch starts at 10.2, and patches stop when the next minor ships.
Reboot: dnf needs-restarting -r — exit 1 means reboot; kernel, glibc, and systemd always mean reboot.
Fleet: promote a Satellite content view version through lifecycle environments; Insights tells you what is unpatched before the auditor does.