Everyone talks about software EOL. Nobody talks about hardware EOSL.
End-of-Support-Life (EOSL) hardware creates exactly the same security exposure as EOL software — firmware vulnerabilities that will never be patched, CVEs that accumulate without remediation, and compliance findings that auditors increasingly flag. But unlike software EOL, hardware EOSL almost never shows up in a vulnerability scanner.
What EOSL Means for Hardware
When a hardware vendor declares a product End-of-Support-Life (sometimes called End-of-Service-Life or End-of-Sale), they stop:
- Issuing firmware updates and security patches
- Providing technical support
- Selling replacement parts
- Publishing security advisories
The firmware on your EOSL hardware is permanently frozen at whatever version it was at when support ended. Any CVEs discovered after that date — and there will be CVEs — have no patch path.
The Categories Most at Risk
Network Infrastructure
Routers, switches, firewalls, and load balancers are the highest-risk EOSL hardware category. They run continuously, face the internet directly, and contain embedded operating systems with their own CVE exposure.
Cisco IOS versions, Juniper firmware, Fortinet FortiOS — all have their own lifecycle dates. A switch running IOS 12.x is carrying vulnerabilities that Cisco stopped patching years ago, but it shows up in most network scans as "network device," not as "EOL software with unpatched CVEs."
Server Hardware
Physical servers from major vendors (Dell PowerEdge, HPE ProLiant, Lenovo ThinkSystem) have EOSL dates that affect:
- iDRAC/iLO/IMM firmware (out-of-band management — high-value attack target)
- BIOS/UEFI firmware
- NIC, RAID controller, and storage adapter firmware
- Vendor management software agents
EOSL server hardware in a datacenter or colo may still run perfectly well — but its management firmware is accumulating unpatched CVEs indefinitely.
Storage Systems
SAN arrays, NAS devices, and object storage appliances have complex firmware stacks. EOSL storage hardware often remains in production long after support ends because storage migrations are expensive and disruptive. The firmware running your storage fabric may be years past end of support.
Security Appliances
This is the highest-risk category. Hardware security appliances — next-gen firewalls, IDS/IPS systems, SSL inspection appliances — are explicitly security infrastructure. Running EOSL security hardware is a compounding risk: the device meant to protect your environment has its own unpatched vulnerabilities.
How EOSL Hardware Creates Compliance Findings
Most compliance frameworks have evolved to address hardware lifecycle, not just software:
PCI DSS 4.0 — Requirement 6.3 covers all system components, which includes hardware. A EOSL network device in the cardholder data environment requires the same Targeted Risk Analysis as EOL software.
NIST SP 800-53 — SA-22 (Unsupported System Components) explicitly covers hardware that has reached end-of-support. FedRAMP inherits this requirement.
SOC 2 — CC6.1 covers the use of security-enhanced configurations for all infrastructure components. EOSL hardware with unpatched firmware fails this control.
ISO 27001:2022 — Annex A 8.8 (Management of technical vulnerabilities) applies to hardware firmware as well as software.
Why Scanners Don't Catch It
Vulnerability scanners look for CVEs in running software. They fingerprint operating systems, detect software versions, and match against CVE databases. They don't typically:
- Query hardware asset management systems for EOSL status
- Check firmware versions against vendor lifecycle databases
- Flag network devices as "end of support" even when they are
This is the same CVE blind spot that affects EOL software, amplified by the fact that hardware asset management is often maintained in a separate system (or a spreadsheet) that never gets cross-referenced against vendor lifecycle data.
What to Do
01 — Build a hardware inventory with firmware versions
Your network team knows your switch and router models. Your systems team knows your server hardware. Your storage team knows your SAN. Combine these into a single inventory with current firmware versions.
02 — Cross-reference against vendor EOSL announcements
Every major hardware vendor publishes EOSL dates. Cisco publishes EOL notices on their website. Dell, HPE, Lenovo, Palo Alto, Fortinet, Juniper all have lifecycle pages. Check each hardware model and firmware version against the vendor's current lifecycle table.
03 — Prioritize by attack surface
Not all EOSL hardware is equal risk. Rank by:
- Internet-facing vs internal
- Management plane exposure (iDRAC/iLO accessible from where?)
- Vendor CVE history for that product family
- Regulatory scope (is it in your CDE, healthcare network, or federal environment?)
04 — Document compensating controls for hardware you can't replace immediately
Hardware replacement cycles are 3–7 years. You can't always replace EOSL hardware immediately. Document: what the hardware is, its EOSL date, its current firmware version, what compensating controls are in place (network segmentation, monitoring, access controls), and a replacement timeline.
05 — Include hardware in your EOL monitoring program
The same discipline you apply to software EOL tracking should apply to hardware. Set calendar reminders for hardware EOSL dates. Include hardware in your quarterly security reviews.
The Bottom Line
EOSL hardware is the EOL risk nobody tracks until an auditor finds it or a breach investigator traces a compromise back to an unpatched firmware CVE.
The pattern is identical to software EOL: known vulnerabilities, no patch path, accumulating exposure. The only difference is that software EOL has gotten attention, and hardware EOSL largely hasn't.
Check your software stack for EOL exposure at endoflife.ai — and use what you learn there as a template for building the same discipline around your hardware inventory.