There is a switch in a closet somewhere in your building that has been running for eleven years. Nobody thinks about it. It has never failed, never been rebooted outside a power outage, and never appeared on a risk register.
It is probably the most exploitable device you own.
The conversation about network hardware almost always happens in performance terms. Is it fast enough? Does it support the port density we need? Can it handle the new access points? Those questions matter, but they miss the more consequential one: is anyone still writing security patches for it?
For a large amount of infrastructure sitting in production right now, the answer is no.
What End of Support Actually Means
Vendors publish lifecycle dates in stages, and the distinction between them matters more than most organizations realize.
- End of sale simply means you can no longer buy the product new. It says nothing about support and triggers no urgency.
- End of software maintenance is where the risk begins. The vendor stops issuing feature updates and, critically, stops issuing security patches. Any vulnerability discovered after this date remains in the device permanently.
- End of support closes the last door. No technical assistance, no hardware replacement, no advisories. The device is on its own.
The gap between these dates is often years, which is why organizations drift past the meaningful one without noticing. Procurement tracks end of sale because it affects purchasing. Nobody tracks end of software maintenance because it does not affect anything visible until a CVE lands.
Why “It Still Works” Is the Wrong Test
Network hardware is unusual among IT assets in that it degrades almost invisibly. A laptop gets slow and someone complains. A server throws errors and monitoring catches it. A switch just keeps forwarding packets, silently, for a decade, doing its job perfectly while its firmware becomes an archaeological artifact.
That reliability is exactly what makes the risk persistent. There is no operational signal prompting replacement, so replacement never gets budgeted, so the device stays.
The functional test everyone applies is “does it pass traffic.” The security test that actually matters is different: can this device receive a patch if a critical vulnerability is published tomorrow? If the answer is no, the device’s remaining useful life is not determined by its hardware. It is determined by how long it takes someone to find and weaponize a flaw in the firmware version it is frozen on.
That timeline is not under your control.
The Devices Most Likely to Be Forgotten
Some categories reliably fall off the inventory.
- Edge switches in remote closets and satellite offices. They were installed during a build-out, they work, and nobody has physically visited that closet in years. These are frequently the oldest devices in an entire estate.
- Wireless controllers and older access points. Wireless gets refreshed when coverage complaints arrive, which means the controller often survives multiple AP generations.
- VPN concentrators and remote access appliances. This category deserves specific attention because these devices are internet-facing by definition and have been among the most heavily targeted infrastructure of the last several years. An unpatched remote access appliance is not a theoretical exposure.
- Firewalls kept past their support window because the replacement project stalled. Common, and the irony is uncomfortable: the device whose entire purpose is security is running unpatched code.
- Anything inherited through acquisition. Merged environments routinely contain infrastructure nobody on the current team specified, documented, or has credentials for.
The Attacker’s Perspective
Network infrastructure is an appealing target for reasons that have nothing to do with the data on it.
A compromised switch or router sits below most security tooling. Endpoint detection does not run on it. It rarely appears in log aggregation with any useful detail. An attacker who establishes persistence on a network device can survive endpoint reimaging, server rebuilds, and password resets, because nobody thinks to look there.
It is also a privileged vantage point. From a network device, an attacker can observe traffic, modify routing, disable logging, and move laterally without generating the signals that a compromised workstation would.
And the vulnerabilities are public. When a vendor publishes an advisory for a device family that includes both supported and end-of-life models, the patch covers the supported ones. The advisory tells everyone exactly what is wrong with the unsupported ones and no fix is coming. That is not an obscure attack path. It is a documented one with a permanent shelf life.
What a Refresh Actually Involves
Organizations often defer a refresh because they imagine it as a single large purchase. In practice it is a sequence, and the purchase is not the hard part.
The first step is an accurate inventory, which is where most programs discover the real problem. Many organizations cannot produce a complete list of network devices with model, firmware version, and lifecycle status. Discovery tooling helps, but so does a physical walkthrough of closets and remote sites, which routinely surfaces equipment absent from every system of record.
From there the work divides into assessment, design, and migration. Assessment maps each device against vendor lifecycle dates and current exposure. Design determines whether the replacement is like-for-like or an opportunity to change architecture, since a refresh is the cheapest moment to introduce segmentation, better visibility, or a different management model. Migration is the part that requires planning against maintenance windows, because swapping core infrastructure is disruptive in ways that swapping laptops is not.
This is also where most organizations reach outside. The specific challenge is not installing switches, which is straightforward. It is knowing what to buy against a five to seven year horizon, understanding which product lines are early in their lifecycle versus quietly approaching end of sale, and sequencing a migration so that dependencies do not surface mid-cutover. Working through enterprise networking solutions with a partner who tracks vendor roadmaps across multiple manufacturers changes the quality of that decision considerably, mainly because lifecycle information is scattered, inconsistently published, and occasionally revised. Buying a platform that reaches end of sale eighteen months after installation is an expensive and entirely avoidable outcome.
Three practical items worth confirming during any refresh:
- Where the replacement sits in its own lifecycle, not just whether it is currently sold. Ask for the published end-of-sale and end-of-software-maintenance dates before purchase, not after.
- Whether the licensing model creates a second cliff. Some platforms continue functioning but stop receiving threat intelligence or security updates when a subscription lapses, which produces the same exposure through a different mechanism.
- What happens to the old equipment. Devices leaving the environment carry configurations, credentials, and certificates. Wiping them properly is a step that gets skipped when equipment goes to a recycler or a resale channel.
Building a Lifecycle Practice
The goal is to stop treating this as a periodic crisis and start treating it as maintenance.
That requires three things, none of them technically difficult. An inventory that records lifecycle dates alongside serial numbers and firmware, reviewed quarterly rather than during an audit. A budget line for infrastructure replacement that exists every year rather than appearing when something breaks. And a policy position on how long past end of software maintenance the organization is willing to run a device, with exceptions documented and owned by someone senior enough to accept the risk.
That last one is the piece that changes behavior. Once continuing to run unsupported infrastructure requires a named person to sign off on it, the conversation stops being about whether the device still works and starts being about who is accountable when it does not.
Conclusion
Aging network hardware fails quietly, which is precisely why it is dangerous. There is no performance complaint to trigger action, no error to catch in monitoring, no user filing a ticket. The device works exactly as well on the day its last patch was issued as it does five years later, and that stability is what keeps it in production long past the point where it should have been retired.
The test worth applying is not whether it works. It is whether it can be fixed. Infrastructure that can no longer receive a security update is running on borrowed time, and the length of that loan is being decided by people who do not work for you.