Every Red Hat Summit has a keynote version of the roadmap and a hallway version. The keynote is polished and rehearsed; the hallway is where you get the operational detail that actually changes your upgrade calendar. At Red Hat Summit 2026 in Atlanta, I sat down with Scott McBrien from Red Hat for the hallway version of the RHEL roadmap, and it was dense enough to unpack properly rather than leave as one paragraph in my show-floor recap.
Watch the Video
RHEL 10.2 and RHEL 9.8: Two Trains, Same Station
Scott confirmed both RHEL 10.2 and RHEL 9.8 are launching soon, on their normal minor-release cadence. Worth restating anyway: RHEL 9 is not a legacy track winding down — it’s a fully supported peer release train getting the same features and hardening work as RHEL 10, just on an older ABI baseline. If you’re planning a migration window, both trains are moving at once, and neither is standing still while you decide.
Fedora Hummingbird and the Zero-CVE Images: What “Redistributable” Buys You
The detail that stood out most was the status of hardened, zero-CVE images for Fedora 40 going GA — the same Fedora Hummingbird Linux and Red Hat Hardened Images work I covered from the keynote stage, but with Scott’s “so what” for operations teams attached.
“Zero-CVE” doesn’t mean an image immune to future disclosures. It means the image ships from a known-clean baseline at build time — unnecessary packages stripped out, the remaining surface scanned and remediated against currently known CVEs. The value is velocity, not permanence: instead of every team independently hardening a minimal base image from scratch, that work is done centrally, and your security team audits the delta instead of starting from zero.
Redistributable matters just as much and is easy to undervalue. A hardened image you can’t legally rebuild or ship downstream only helps the org that pulled it. Redistributable means integrators, ISVs, and downstream distributions can build products on that same hardened baseline without a separate licensing negotiation each time — the difference between an internal tool and an actual supply-chain building block.
The Long-Life Add-On: No More Two-Year Ceiling
The lifecycle change is the one I keep thinking about. Red Hat’s extended lifecycle coverage used to cap at two years past the point you invoked it. That cap is gone. The RHEL Enterprise Linux Long-Life Add-On — the same signage I passed on the show floor all week — is now available for as long as you actually need it, still a paid add-on, but no longer bounded by an arbitrary clock.
A strict two-year cap suits a typical enterprise app server fine, but it’s the wrong shape for embedded controllers, medical devices, and anything behind a regulatory recertification process, where an OS upgrade means a multi-month recertification with an external auditor, not a maintenance window. A fixed window forces those customers to either recertify on a clock unrelated to their real risk, or quietly run unsupported. Removing the cap turns the Long-Life Add-On from a stopgap into a genuine long-lifecycle option, priced for however long the deployment actually runs.
DNF5 Skips RHEL 10, Lands in RHEL 11
The most concrete forward-looking data point: DNF5 is already shipping in Fedora today, but it’s expected to land in RHEL 11 rather than being backported into RHEL 10 — and RHEL 11 itself is targeted for around mid-2028.
That’s a deliberate delay, not an oversight. DNF5 is a full rewrite — new C++ core, new API and plugin surface, behavioral differences in transaction resolution and output versus the DNF4/libdnf stack in RHEL 9 and 10. Package management sits underneath everything: Ansible modules, Kickstart and image-build tooling, container builds, every script that shells out to dnf. Swapping that layer mid-release, inside an existing major version’s tooling contract, risks breaking the exact automation RHEL’s stability guarantees exist to protect. A major version boundary is the one place Red Hat can change that contract on purpose, with a documented migration path, instead of surprising a production fleet with a minor update. Fedora is where that risk gets burned down in public first, well ahead of the mid-2028 target.
The Takeaway for Planning
None of these four items is a surprise on its own — RHEL ships on a cadence, hardened images were already teased at the keynote, and lifecycle extensions have been trending this way for a while. What Scott’s rundown gave me was the specific shape of each: which Fedora version the zero-CVE images target, that the Long-Life Add-On cap is gone rather than merely extended, and — most useful for anyone maintaining automation against dnf — that you have roughly until mid-2028 before DNF5 becomes a RHEL problem rather than a Fedora one. That’s the kind of detail worth getting from the person doing the work, not just the stage.
Related Reading
- Red Hat Summit 2026 in Atlanta: Open Source Meets AI
- Red Hat Summit 2026 Keynote: Eight Announcements That Matter
- RHEL 10: What’s New in Enterprise Linux
- Immutable Linux with bootc: Atomic Updates and Rollback
- DNF Cheat Sheet 2026
About the Author
I am Luca Berton, AI and Cloud Advisor. I work at the intersection of platform engineering, cloud security, and enterprise AI deployments. Book a consultation.
