Firmware updates of network devices in the company
Firmware updates for network devices bring bug fixes and security gaps, but each of them means a restart, i.e. a break. This article describes how to plan your service window, what order to update, when to consciously wait, and why it's a recurring, not a one-time, activity.
Network hardware is also software
The switch, access point and gateway are devices, but what actually works in them is software, so it has bugs, gets patches and at some point it stops being supported.
The difference from computers is visibility. The system on the laptop itself reminds about the update, while the switch locked in the closet reminds of nothing and can work on the version from the day of installation for five years without arousing anyone's interest because it works.
It is the "works" that is misleading here, because a device can work flawlessly while having a known and publicly described vulnerability for which a patch has existed for two years.
What do network device firmware updates provide?
It is worth separating three things that differ in urgency enough that treating them together leads to bad decisions.
Security fixes are most important as vulnerabilities in network device software are published and edge devices remain targets for continuous and automated Internet scanning. This is the one category that tends to be really urgent.
Bug fixes solve specific problems: connection drops in certain conditions, memory leaks causing restarts every few weeks or incorrect operation of functions in rare configurations. It happens that a problem that no one can diagnose turns out to be a known error with a ready fix.
New features are the least urgent and in a production environment there is no reason to upgrade if no one needs them.
This hierarchy has practical significance because a security update justifies an off-plan maintenance window, while a new feature justifies nothing.
Why This Isn't a "By the Way" Activity
Updating a network device requires a reboot, and a reboot means an interruption in the operation of everything that goes through it.
The scale of this disruption depends on where you are in the topology: a restart of a single AP will affect one room, a restart of a backbone switch will shut down everything behind it, and a restart of a gateway will bring the entire company to a halt.
Therefore, updating is a planned activity that consists of five elements.
Service Window is determined outside working hours, taking into account when the company is not actually working. For a two-shift production plant, "evening" is not the answer.
Sequence goes from the least critical to the most: first the access points in the less critical area, then the access switches, then the backbone, and finally the gateway, with each stage verified before the next.
Verification after every step comes down to checking that the device is back, that the ports have a link, that the clients are connecting and that the segmentation is still working. The question "is there an Internet" does not answer this.
Return plan means the possibility of uploading the previous version and saved configuration, as well as, which is sometimes omitted, a set hour, after which, instead of repairing further, we return to the previous state.
Information for people includes the date of the break, its scope and the indication of the person to whom you should report anything that has not returned after the update.
The order is also technically important
There is a rule that is surprisingly often overlooked: in centrally managed platforms, the controller or panel software updates before devices, not after them.
The reason is simple. A newer device managed by an older controller may not be recognised correctly, while the reverse order does not pose this risk.
The second rule is not to update everything at once, and it is not due to caution, but to the possibility of diagnosis. If something stops working after updating twenty devices at once, it's impossible to figure out which one is the cause, so phasing in, while costing more time on-site, saves time later.
When to consciously wait
Updating immediately after release is not a virtue in a production environment, which is worth remembering when the temptation to "let's do it right now" arises.
It's worth the waitif the release is fresh and does not include a security patch for your environment, if your environment is unusual due to configuration, integrations or legacy devices, if you are approaching a critical period for your business such as month end, season or inventory, or if the manufacturer has marked the release as early or testing. Many platforms separate release channels into stable and earlier, and production uses stable.
It's not worth the waitwhen the patch addresses a vulnerability in an internet-accessible device, when the current version causes a problem that already exists, or when the device is nearing the end of support and this is one of the last updates it will receive at all.
End of support is a separate issue
Updates eventually end because the manufacturer sets a date after which the device no longer receives patches, including security patches.
The problem is that the device after this date works exactly the same as before, giving no signal that anything has changed. What has changed fundamentally: from that moment on, each newly discovered vulnerability stays there permanently.
Therefore, the list of devices in the network should include a "supported until when" column, without which replacing equipment will always be a reaction to a failure instead of a decision planned together with the budget.
What updates won't fix
It's worth saying it directly so as not to treat them as solutions to problems they do not address.
Updates will not fix bad network design, because misplaced APs will remain misplaced in any software version. They will not replace segmentation or access control, which are separate layers, described in the article o basics of corporate network security. Will not fix the wiring problem, as the damaged track will remain damaged. They won't protect computers either, which is in a completely different area.
What it looks like with a managed network
Without central management, updating involves logging into each device individually and manually checking the version, which takes an evening with ten devices and, with three locations, the reason no one does it.
Management platforms show versions on all devices simultaneously and allow you to schedule updates for a selected time, but the scope of these possibilities is sometimes tied to the licence plan, which is worth checking before, not after, purchase.
For example, in Zyxel Nebula Control Centre, site-wide firmware management is available on the free Base plan, while scheduling per-device updates across an organisation requires the Plus plan or higher, and the Pro plan adds an organisation-wide change log, useful for determining who changed what and when.
Log retention is also important, as it determines whether it is possible to determine what happened after the update. In the Base plan, it is one day, in Plus it is seven days, and in Pro it is one year, which, given the weekend service window, means that there is nothing to analyse on Monday.
This is a recurring activity
We come to the sentence that brings this topic back to life: updates are not a state that can be achieved, but a process. A network updated today will be out of date in three months and no one will remember it.
In practice, it comes down to three questions that a company should be able to ask itself:
- Who checks for new versions and how often?
- Who decides whether and when to update?
- Who performs this and verifies the result?
If there is no answer to any of them, the devices work on the version from the date of installation, which is not the negligence of a specific person, but a natural consequence of the lack of assigned responsibility.
For us, patch management of network devices is part of ongoing care, not a separate order: we track manufacturer releases, assess their urgency, plan service windows, carry out updates in stages and verify the result. We also maintain a list of devices with end-of-support dates so that replacement remains a decision rather than a reaction. The scope and response times are written in the contract.
In corporate networks, we are a Zyxel Networks Partner and we also implement Ubiquiti UniFi.
The scope of permanent service is described on the website IT care, implementation on the site corporate networks, and the access mechanism thanks to which all this can be done remotely, in the article about remote management of the company network.
Book a free IT review and let's figure out how to see what versions your devices are working on today.