EOL Software: When No Patch Is Coming

Why EOL Is Permanently Critical

End-of-life means the vendor has stopped providing security updates. This creates a fundamentally different risk profile than supported software:

The Attacker Perspective

Why Attackers Love EOL Targets

• Guaranteed exploitation: Known CVEs will work forever. No race against patches.
• Exploit kits ready: Popular EOL software has exploit code readily available
• Easy discovery: Version fingerprinting reveals EOL status immediately
• Signal of weak security: If they run EOL externally, internal security is likely weak
• Low attacker effort: No 0-day development needed, just use public exploits

Attack Timeline

Attacks against EOL systems are often trivial:

1. Scan (seconds): Fingerprint software version from banner or response
2. Identify (seconds): Check if version is EOL
3. Exploit (minutes): Use known CVE with public exploit code
4. Compromise (minutes): Gain shell access or data

Commonly Found EOL Software

Operating Systems

Web Servers & Middleware

• Apache 2.2: EOL December 2017
• nginx 1.18 and earlier: Various EOL dates, check specific version
• PHP 7.4: EOL November 2022
• PHP 8.0: EOL November 2023
• Tomcat 8.5: EOL March 2024
• Node.js LTS versions: Check nodejs.org for current EOL schedule

Databases

• MySQL 5.7: EOL October 2023
• PostgreSQL 11: EOL November 2023
• PostgreSQL 12: EOL November 2024
• SQL Server 2012: Extended support ended July 2022
• MongoDB 4.x: Various EOL dates by minor version

Remediation Strategies

Option 1: Upgrade (Preferred)

Upgrade to a supported version of the same software:

• Best outcome: Minimal architectural change, continued vendor support
• Timeline: Plan for 1-4 weeks depending on complexity
• Risk: Application compatibility, testing requirements

Upgrade should be the default approach unless technical constraints prevent it.

Option 2: Migrate to Alternative

Move to a different but supported platform:

• CentOS → Rocky Linux, AlmaLinux, or RHEL
• Windows Server 2008 → Windows Server 2022 or Linux
• Legacy application → Modern equivalent or SaaS

Migration is appropriate when the EOL software has no supported upgrade path.

Option 3: Replace with Modern Architecture

Sometimes EOL systems indicate technical debt that should be addressed:

• Containerize applications for easier updates
• Move to managed cloud services (RDS, Azure SQL, etc.)
• Rewrite legacy applications

Longer timeline but addresses root cause of EOL accumulation.

Option 4: Decommission

Sometimes the right answer is to turn it off:

• Is this system still needed?
• Can its function be absorbed by other systems?
• Is the business value worth the security risk?

Compensating Controls

When immediate remediation isn't possible, implement compensating controls to reduce risk.These do not eliminate the risk—they reduce it while you plan remediation.

Network Isolation

• Remove from internet: If internet exposure isn't required, block it
• IP allowlisting: Restrict access to specific known IPs
• Network segmentation: Isolate EOL systems from critical assets
• VPN requirement: Require VPN to access the system

Web Application Firewall (WAF)

• Deploy WAF in front of EOL web servers
• Enable virtual patching rules for known CVEs
• Block common exploit patterns
• Rate limit and bot protection

Enhanced Monitoring

• Increase logging and log retention
• Deploy IDS/IPS with signatures for known exploits
• Alert on any unusual activity
• Consider deploying honeypot alongside to detect targeting

Access Restrictions

• Implement MFA for all access (even if software doesn't support it, put MFA proxy in front)
• Reduce administrative access to minimum necessary
• Audit and remove unnecessary services/ports

Building an EOL Tracking Program

Inventory Requirements

Maintain an inventory that tracks:

• All software versions in production (OS, middleware, databases, applications)
• EOL dates for each software component
• Internet exposure status
• Business criticality
• Remediation plan and timeline

Proactive Planning

• 12-month warning: Begin planning for EOL software 12 months out
• 6-month warning: Remediation project should be approved and funded
• 3-month warning: Implementation should be in progress
• EOL date: No internet-facing EOL without approved exception

Exception Process

When EOL systems must remain temporarily:

• Document business justification
• List all compensating controls implemented
• Set hard expiration date (no indefinite exceptions)
• Require executive sign-off accepting residual risk
• Review monthly until remediated

Metrics to Track

• Number of EOL systems (total and internet-facing)
• Average age past EOL date
• Time to remediate once EOL detected
• Exception count and average exception duration

Related Security Guides

EOL software is often found alongside other attack surface issues. Review these related guides:

• Exposed RDP Guide — EOL Windows servers often have exposed RDP, creating a doubly dangerous combination.
• Exposed SSH Guide — Outdated SSH daemon versions (OpenSSH, Dropbear) on EOL operating systems compound risk significantly.
• Exposed Admin Panels Guide — EOL CMS platforms and management interfaces require immediate attention.
• Attack Surface Monitoring Guide — Learn how to continuously monitor for EOL software appearing on your perimeter before attackers discover it.

Summary: EOL Response Checklist