Most network hardware ages gracefully. A switch that reached end-of-life five years ago is very likely still forwarding frames perfectly well, and the main risk of keeping it is that a hardware failure means a scramble for a replacement. The data plane doesn't care how old it is. (There's a whole article in why switches outlast servers.)

The firewall is the exception, and it's a sharp one. It is the single piece of network hardware where end-of-life is not a quiet background risk you can reasonably defer. It's an active, growing, security-critical exposure — and the reason it's so dangerous is that nothing about the box visibly changes when it crosses the line.

Why the firewall is different

A firewall is not just a data-plane device. Its value is almost entirely in the parts that have to stay current to work:

  • The firmware, which patches the vulnerabilities attackers actively hunt for in internet-facing gear.
  • The threat-intelligence and signature feeds, which only mean anything if they're being updated against this week's threats.
  • The decryption, inspection, and application-awareness engines, which depend on current definitions to recognize current traffic.

A switch forwarding frames needs none of that to keep doing its job. A firewall defending a perimeter needs all of it, continuously. When the vendor declares end-of-life and the firmware updates and feed subscriptions stop, the box keeps passing traffic exactly as before — and quietly stops being a defense.

The silent failure mode

This is the trap's cruelty: nothing breaks. The firewall EOLs, the updates stop, and the device continues to pass traffic, enforce its rules, and show green on the dashboard. Every visible signal says "fine." Meanwhile:

  • New CVEs are disclosed against the platform, and no patch will ever come. Internet-facing firewall vulnerabilities are among the most aggressively exploited of all — they're a direct path into the network, and attackers scan for known-vulnerable EOL firewall models constantly.
  • The threat feeds freeze. The box is now defending against last year's threats with last year's definitions, blind to everything new.
  • The inspection engines fall behind modern traffic, silently passing things they'd have caught when current.

There is no outage, no alert, no red light. The firewall "works" right up until it's the entry point for an incident — and in the post-mortem, "the perimeter firewall was three years past end-of-life with known unpatched CVEs" is a sentence that ends the conversation about whether this was preventable.

Why it gets deferred anyway

Firewall replacement gets put off for the same reasons every unglamorous refresh does, amplified by a few specific to firewalls:

  • It still works. The absence of a visible failure is read as the absence of a problem. (It is the opposite.)
  • Replacement is disruptive. The firewall is a chokepoint; replacing it means a maintenance window, a rule migration, and the risk of an outage if the cutover goes wrong. That friction buys procrastination.
  • The subscription lapsed quietly. Feed and support subscriptions expire on their own schedule, sometimes before the hardware EOL, and a lapsed subscription on working hardware is easy not to notice.
  • Budget timing. Security hardware refreshes compete with everything else, and "the firewall still passes traffic" loses the argument against a visible, urgent need.

The discipline

Treat the firewall as the one box where end-of-life is a hard deadline, not a soft risk:

  • Know the dates, and watch two of them. Hardware end-of-life and the end of firmware/feed support. The second one is the one that matters for security, and it sometimes comes first. Past either, the clock is loud.
  • Track the CVE exposure specifically. Internet-facing EOL firewalls accumulate unpatched, actively-exploited vulnerabilities. That's not a theoretical risk profile; it's the most common initial-access vector there is. Treat a known-vulnerable EOL perimeter firewall as an open incident, not a future project.
  • Plan the replacement before you're forced into it. The disruptive cutover is far better done on a planned maintenance window than as emergency remediation after the box is named in an incident. A planned firewall refresh is routine. An emergency one, mid-breach, is not.
  • If you genuinely can't replace it yet, compensate and document. Tighten the rules, restrict management access, put compensating controls in front of it, and write down the risk acceptance with a hard replacement date. Running an EOL firewall undocumented is negligence; running one with eyes open and a dated remediation plan is at least a defensible decision.

Most end-of-life hardware is a reliability question you can take your time with. The firewall is a security question you can't. It's the one box where "it still works" is precisely the problem — because working and defending stopped being the same thing the day the updates stopped.