Red Hat Enterprise Linux End of Life (EOL) Dates and End of Support (EOS) Dates

Your Red Hat Enterprise Linux end of life date is fixed years in advance: every major release of Red Hat Enterprise Linux gets a 10-year life cycle, and once it ends, Red Hat stops shipping patches. This guide lists the end date for each version, explains the phases behind it, and shows what you can do before a deadline lands on your production servers. If you run one enterprise Linux operating system or a whole fleet, the dates below tell you how long you can keep getting security support and when to schedule an upgrade. Red Hat end of life planning is far cheaper than an emergency migration, so start with your oldest release.

Red Hat Enterprise Linux End of Life Dates by Version

Each major release moves through Full Support, Maintenance Support and the Extended Life Phase, and the date that matters most for patching is the end of Maintenance Support. After that point you receive no new errata, which means no RHSA security advisories and no RHBA bug fix advisories, unless you buy an add-on. The table works as an end of service life (EOSL) cheat sheet for the RHEL EOL dates most teams plan around. Confirm each one in the Customer Portal documentation before you commit a project timeline, because Red Hat reserves the right to adjust them.

RHEL 9 and RHEL 10 Support Windows

Unlike RHEL 8, RHEL 9 stays in Full Support until May 31, 2027 and in Maintenance Support until May 31, 2032. RHEL 10 runs to May 31, 2030 and May 31, 2035. Both major version lines follow the same pattern, so this enterprise Linux distribution gives you a predictable runway as long as you track each minor release and its security updates.

RHEL 7 and RHEL 6 Red Hat EOL Status

RHEL 7 reached its end of Maintenance Support on June 30, 2024, and RHEL 6 left Maintenance Support in 2020. Neither gets routine fixes now, and technical support is limited to what a paid add-on allows. If an audit shows either release still running, treat it as your first migration target.

RHEL Life Cycle Phases From Full Support to Retirement

Red Hat describes the Linux lifecycle as a ten-year run in three phases, designed to reduce change inside a release over time. The split matters because your subscription gets different value in each one, from new hardware enablement early on to documentation-only access at the end. In every active phase, Critical and Important issues receive RHSA advisories and urgent defects receive RHBA advisories, at Red Hat's discretion.

Full Support Phase

During Full Support, you receive security fixes, urgent bug fixes, new minor releases, refreshed hardware enablement and select software enhancements. This is the phase to adopt a release in, because the platform is still moving.

Maintenance Support Phase

Under Maintenance Support, you receive only qualified security errata and bug fix errata. New minor release content and hardware enablement stop, so your lifecycle changes from improving to merely staying safe. RHEL 8, the current Red Hat Enterprise Linux release many enterprise teams still run, sits here today.

Extended Life Phase

In the Extended Life Phase, you keep access to documentation and existing packages, but the kernel and every other component stop receiving fixes. The Extended Life Phase is where an unpatched system quietly becomes a liability.

RHEL 8 End of Life and Its Errata and Support Policy

For most teams the nearest deadline is RHEL 8 end of life on May 31, 2029. Until then, RHEL 8 keeps receiving errata under the Red Hat Enterprise Linux support policy: security advisories for Critical, Important and qualifying Moderate CVEs, plus selected high-priority bug fixes, are delivered through the Customer Portal. Red Hat also works to preserve binary compatibility across minor releases, so a patched system keeps running your software. RHEL 8 packages come with security updates until then. Check which release you run with cat /etc/redhat-release, then compare the result with the table above. A vendor that supports a ten-year window rarely extends it, so budget for the move rather than a reprieve, and treat the deadline as fixed for production planning.

Extended Life Cycle Support Add-ons After EOL

When a release reaches EOL, Red Hat sells Extended Life Cycle Support (ELS) as an add-on for some releases, and its newer ELCP model stretches coverage further for eligible Linux versions. Extended support of any kind trades money for time, not for a long-term fix, and every extended support term ends eventually.

Extended Life Cycle Premium (ELCP)

Starting with RHEL 9, ELCP replaces separate add-ons and unifies the older add-ons into one model. Extended Life Cycle Premium extends errata coverage for eligible even-numbered minor releases, and renewable Long-Life terms can continue coverage in one-year steps. Your subscription level decides which releases qualify, and ELCP planning guides explain the ELCP terms in detail for each ELCP-eligible release.

Extended Update Support and Legacy Offerings

Extended Update Support (EUS) and Update Services for SAP Solutions (E4S) let you stay on one minor release longer. Customers on RHEL 6 and RHEL 7 can keep the legacy ELS arrangement only through its committed end date.

Risks of Running RHEL After End of Support

Once end of support passes, new vulnerabilities keep appearing but your servers stop receiving the fixes. The risks grow every month: audit findings, downtime after an exploit, and rising cost to upgrade a system that has drifted further from supported software. Outdated enterprise workloads also start failing vendor checks, since many application vendors certify only against supported releases.

Unpatched CVEs and Compliance Gaps

A release past its Red Hat end of life gets no new kernel or OpenSSL errata, so each new CVE stays open on your servers. Frameworks such as PCI DSS, HIPAA and SOC 2 expect timely security patches, so a RHEL system past EOL can fail compliance reviews. Cyber insurance underwriters ask the same question, and the answer can affect your premium or coverage.

Your Options When RHEL Reaches End-of-Life

You have four realistic paths, and the right one depends on your budget, your deadline and how much of the stack you can change. IT teams usually combine two, such as an upgrade for most infrastructure and paid coverage for a stubborn server.

In-Place Upgrade With Leapp

The Leapp tool performs an in-place upgrade from one major version to the next, keeping your data and configuration. It is the fastest migration route for standard workloads, but test it first, especially where Python or OpenSSL versions changed.

Rebuild or Switch to a RHEL-Compatible Distribution

A clean rebuild on a newer RHEL release removes years of configuration drift. Alternatively, you can move to a compatible distribution such as AlmaLinux or Rocky Linux, which share RHEL packaging while staying outside Red Hat's subscription model.

Third-Party Extended Support

Independent vendors sell patches and packages for releases Red Hat has retired, covering components like OpenJDK and the kernel. This third-party route buys migration time, but your vendor support terms still need checking.

Red Hat Long-Life Add-On Extensions

Red Hat Enterprise Linux Long-Life terms extend coverage in yearly renewals for eligible releases. They suit a server you cannot move yet, but plan the exit anyway: each renewal costs money without reducing your upgrade work.