Firmware updates on a live network

Firmware sits in an awkward place. It is the layer with the most serious vulnerabilities and the least appetite for change, because a failed firmware update on a switch is not a rollback — it is a site visit.

So most organisations end up at one of two extremes by default rather than by decision: update immediately because the vendor said so, or never update because the last one caused an outage.

Neither extreme survives contact

Updating immediately means running vendor code that has been in the field for days. Firmware regressions are real and they surface in exactly the configurations that are unusual — which, on any network that has grown organically, is most of them.

Never updating means accumulating known, published, exploitable vulnerabilities in the devices that carry every packet. It also means that when an update finally becomes unavoidable, the jump is across several major versions, which is the riskiest kind.

A workable middle

Read the release notes and triage. Most releases are not urgent. A remote unauthenticated vulnerability in a component you expose is urgent; a fix for a feature you do not use is not. This triage takes minutes and it is the step that gets skipped.

Let a release age, unless it cannot. A few weeks between release and deployment lets other people find the regressions. Security fixes for something reachable from outside are the exception.

Update one first. One access switch, one access point — something real, in production, whose failure is survivable. Then wait. A regression that only shows under load will not appear in ten minutes.

Never both members of a redundant pair on the same night. The whole point of the pair is that they fail independently, and identical firmware applied at the same moment removes exactly that property.

Before you touch anything

Save the running configuration off the device, and confirm you can read the file. A configuration backup that lives only on the device being updated is not a backup.

Know the rollback path and whether the device actually supports one. Many switches hold two firmware images and can boot the previous one; many access points cannot. That difference decides whether an update is reversible, and it is worth knowing before rather than during.

And check console access. If the update goes wrong, the network is how you would normally reach the device, and the network is what just broke. Somebody needs to be able to get to a physical port, or the recovery plan is a drive.

Write down what you decided

Including the decision not to update. A note saying "reviewed, no security content, deferred" is the difference between a considered position and an oversight — and it is what makes the next review take five minutes instead of starting again.