CentOS 7 End of Life: Secure Migration Paths for Stranded Servers

CentOS Linux 7 reached end of life on 30 June 2024, and every CentOS 7 server still running today has gone more than two years without an update from the CentOS Project. Many of these hosts run quietly inside data centres, appliances and container base images, often holding service accounts, SSH keys and database credentials that outlive the operating system. This guide is for Linux administrators, infrastructure leads and security teams who still have CentOS 7 in their estate. It sets out the official dates, how to find every affected host and identity, the conversion and upgrade paths published by each distribution project, paid extended support, and how to contain hosts that cannot move yet. The general decision framework for unsupported operating systems is in the Operating System End of Life and Extended Support Guide; this page is the CentOS 7 specific companion.

This is an independent guide from NHI Mgmt Group, based on the CentOS Project's public documentation as of November 2026. It is not sponsored or reviewed by the CentOS Project. Product features change, so confirm settings against the CentOS Project's current documentation.

Key takeaways

• No more updates, and the mirrors are gone. The CentOS Project stopped publishing CentOS Linux 7 updates on 30 June 2024 and moved its packages to vault.centos.org, which is an archive, not a patch source.
• Four distributions publish routes off CentOS 7. AlmaLinux (ELevate), Oracle Linux (a migration script), Red Hat Enterprise Linux (Convert2RHEL and Leapp) and Rocky Linux (rebuild or upgrade first) each document a path; they differ in whether you change major version in place.
• Converting is not upgrading. A same-version conversion to another EL 7 distribution only buys time if that distribution offers paid extended support; the long-term destination is EL 8, 9 or 10.
• The identities matter as much as the hosts. Inventory local accounts, service accounts, SSH keys and directory joins on each CentOS 7 host before you migrate or isolate it.
• Containment is a stopgap with a deadline. Hosts that cannot move need network isolation, restricted access and an owner-signed exception with an end date.

What is changing and why

CentOS Linux was a free rebuild of Red Hat Enterprise Linux (RHEL). In December 2020 the project shifted its focus to CentOS Stream, a distribution that tracks just ahead of the next RHEL minor release, and stopped building new CentOS Linux major versions. CentOS Linux 8 ended early, and CentOS Linux 7 ran to the end of its planned life. Red Hat describes CentOS Stream as the upstream development platform for future RHEL releases rather than a like-for-like replacement for CentOS Linux, which is why most organisations treat Stream as a separate choice rather than a direct migration target.

After end of life the CentOS Project publishes no security fixes, bug fixes or new packages for CentOS 7. Red Hat's end of life page notes that third-party support offerings may exist but would be separate forks with no connection to the CentOS Project, CentOS Stream or Red Hat. In practice the risk grows every month: new vulnerabilities in the kernel, OpenSSL, OpenSSH, glibc and other core packages are fixed upstream for supported releases but not in CentOS 7 repositories.

Official timeline and current status

Dates below come from the CentOS Project and Red Hat announcement pages listed in Standards and references, checked on 8 November 2026. Extended support dates can change, so confirm against the vendor page before committing to them.

Who and what is affected

• Physical and virtual servers: anything reporting CentOS Linux release 7.x, including hosts that were "temporarily" pointed at the vault so that installs still work.
• Appliances and vendor builds: commercial products built on CentOS 7 (monitoring, backup, telephony, security tools). The product vendor, not you, controls the operating system, so the question becomes whether the vendor has a supported release on a newer base.
• Container images: images built FROM a CentOS 7 base inherit every unpatched package, even when the host runs a supported operating system. See the Container Image Security Guide.
• Build and CI agents: older toolchains are often pinned to CentOS 7 to produce compatible binaries, and these agents usually hold signing keys or deployment credentials.
• Machine identities on the host: service accounts, cron jobs running as root, SSH keys in authorized_keys, Kerberos keytabs from directory joins, and application secrets in configuration files all move, or must be retired, with the host.

Finding affected systems and identities

Work from several sources, because no single one is complete. The Asset Inventory and CMDB Security Guide covers reconciling them.

1. Vulnerability scanner and agent data: filter authenticated scan results and endpoint agents for an operating system of CentOS Linux 7. Most scanners also raise an unsupported operating system finding.
2. Configuration management and inventory: query configuration management facts and the CMDB for the release file value (the /etc/centos-release or /etc/os-release content) and kernel versions in the 3.10 series used by EL 7.
3. Package repository traffic: look in proxy and mirror logs for requests to vault.centos.org or internal mirrors of CentOS 7 repositories. These point to hosts that are still installing packages.
4. Container registries: scan registry images for a CentOS 7 base layer, and list running workloads that use them.
5. Cloud accounts: list instances launched from CentOS 7 machine images in every account and region.

For each host, record the identities it holds or uses: local accounts with login shells, sudo rules, SSH public keys in authorized_keys and private keys stored on the host, directory joins (SSSD or Winbind) and their machine accounts, keytabs, and secrets in application configuration. This list drives the migration plan and the clean-up afterwards. The SSH Key Management Guide and the SSSD and Linux Active Directory Integration Guide explain what to look for.

Migration options

Distributions are listed alphabetically; the order is not a ranking. Each row reflects what the project's own documentation states, checked on 8 November 2026.

Availability: AlmaLinux and Rocky Linux are free to use. Oracle Linux is free to download and use, with paid support offered separately. RHEL requires a subscription; Red Hat lists a developer subscription for teams and consulting services in addition to the migration offer. Check each project's current terms before choosing.

Choosing between rebuild, upgrade in place and convert

Small versus large estates: a handful of hosts is usually quickest to rebuild by hand on a current release. Estates with hundreds of hosts should group them by application owner and build pattern, pilot the chosen path on a representative group, and use automation (Red Hat publishes Ansible roles for Convert2RHEL at scale, and ELevate and Leapp can be driven by configuration management) to repeat it.

A phased programme

1. Inventory and classify every CentOS 7 host, image and appliance, with owner, application, criticality and identities held.
2. Contain first: apply the interim controls below to all hosts while the plan runs, starting with any that are internet facing.
3. Choose a path per group using the tables above, and record the reason and target date.
4. Pilot on a non-production copy of each build pattern; record every inhibitor and fix in a runbook.
5. Migrate in waves, lowest risk first, with a defined rollback point for each host.
6. Clean up identities: rotate secrets and keys that lived on the old host, remove its machine account from the directory, and delete stale local accounts on the new one.
7. Decommission old hosts and images, and block CentOS 7 base images in the registry.

Interim controls for hosts that cannot move yet

• Network isolation: move hosts to a restricted segment; allow only the specific inbound flows the application needs and deny outbound internet except to required services. See the Zero Trust Network Segmentation Playbook for Flat Networks.
• Access restriction: remove direct SSH from user networks, require access through a bastion or privileged access tool, disable root login over SSH and remove unused keys.
• Least functionality: disable and remove unused services and packages to shrink what an unpatched vulnerability can reach.
• Monitoring: forward authentication and audit logs to the SIEM and add file integrity monitoring on key binaries and configuration. See the Linux File Integrity Monitoring Guide.
• Exception record: a risk acceptance signed by the business owner, with compensating controls and an end date no later than the planned migration.

Testing and rollback

• Snapshot or back up first: every project's documentation recommends a backup or snapshot before converting or upgrading. Red Hat's upgrade documentation notes that LVM snapshots are not full backups and points to Relax-and-Recover or VM snapshots.
• Run pre-upgrade checks on a copy: the Leapp-based tools produce a report of inhibitors and risks without changing the system. Treat the report as a starting point; Red Hat notes it cannot catch every failure.
• Test the application, not just the boot: EL 8 changes default crypto policies, Python versions, network tooling and removed some packages. Run functional tests, authentication tests (directory login, sudo, SSH keys) and backup and monitoring agents on the migrated copy. The Linux System-Wide Crypto Policies and FIPS Mode Guide explains the crypto policy change that often breaks old clients.
• Define the rollback: for in-place work, rollback is restoring the snapshot or backup. For rebuilds, keep the old host powered off but intact until the new one has run through a full business cycle.
• Re-harden after migration: apply your Linux baseline to the new host rather than relying on settings carried over. See the Linux Server Hardening Guide.

Risks of doing nothing

• Unpatched core components: vulnerabilities fixed in supported releases stay open on CentOS 7 for good, and attackers who gain a foothold on one host can use local privilege escalation flaws that will never be fixed there.
• Credential exposure: long-lived SSH keys, keytabs and application secrets on unpatched hosts become a route into the rest of the estate. Treat a compromised CentOS 7 host as a credential incident and follow the SSH Key Compromise Response Playbook where keys are involved.
• Supply chain decay: repositories, language runtimes and agents gradually drop EL 7 support, so teams pull packages from unofficial sources to keep things working.
• Audit and compliance findings: NIST SP 800-53 SA-22 (Unsupported System Components) and CSF 2.0 PR.PS-02 expect unsupported software to be replaced or covered by a documented, justified exception.
• Slower incident response: confirm with your forensics and detection tooling vendors which agents they still provide for EL 7, and plan coverage for any gaps where risk is highest.

Framework mapping and metrics

Metrics to track: number of CentOS 7 hosts, images and appliances remaining (trend to zero); percentage with an approved path and date; percentage of remaining hosts in an isolated segment; number of open exceptions past their end date; number of secrets and keys rotated after migration compared with the number inventoried.

Practitioner checklist

• Combine scanner, CMDB, cloud, registry and repository log data into one list of CentOS 7 hosts, images and appliances.
• Record the owner, application and every identity (accounts, keys, keytabs, secrets) on each host.
• Isolate internet-facing and high-value CentOS 7 hosts first and remove direct SSH from user networks.
• Choose rebuild, in-place upgrade, conversion with extended support, or retirement for each group, and date it.
• Pilot each path on a copy, keep the pre-upgrade report, and write a runbook of inhibitors and fixes.
• Back up or snapshot every host before conversion or upgrade and keep it until the new system is proven.
• Rotate secrets and keys and remove directory machine accounts after each host is migrated.
• Block CentOS 7 base images in container registries and CI templates.

Standards and references

• CentOS Project: End dates are coming for CentOS Stream 8 and CentOS Linux 7
• Red Hat: CentOS Linux end of life
• Red Hat: Upgrading from RHEL 7 to RHEL 8
• AlmaLinux: ELevate quickstart guide
• Oracle: migrate-to-oracle-linux.sh README
• Rocky Linux: Migrating to Rocky Linux
• Convert2RHEL project
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: Operating System End of Life and Extended Support Guide · Linux Server Hardening Guide · SSH Key Management Guide · Legacy Application Security