Firmware upgrades and config pushes during production
An access point that is upgrading cannot serve clients, and some configuration changes take radios down, so a push that lands during production drops everything it touches.
On this page5 sections
Is this your problem? It presents like this
- Many devices across an area, or the whole site, drop within minutes of each other.
- The drops line up with an upgrade window, a controller upgrade, or a configuration change.
- Access points show a recent reboot or an uptime that reset.
- Neighboring access points change power or channel as radio management reacts to the missing ones.
- It recurs on a schedule set by the management platform, not by the plant.
- Bands
- 2.4 GHz5 GHz5 GHz DFS6 GHz
Why it happens
Wireless platforms are built to stay current, and plants are built to stay running. NIST sides with the plant: check for updates, but automatic installation of updates is not recommended. Test every update first, and keep a way back, because an update to any part of the factory operation could result in downtime.
An access point is offline while it upgrades. One controller vendor says the AP cannot serve clients during an upgrade, and that upgrading a controller with many access points can take as long as 30 minutes1. Cloud platforms run upgrade campaigns on their own calendar. One cloud-managed platform sends advance notice, lets you defer one month at a time, and finishes every device inside a one-hour time slot, staggered or not. If nobody on the plant side owns that notice, the upgrade runs whenever the platform scheduled it.
Configuration pushes can hit just as hard. The controller vendor’s best practices say changing radio management settings needs a shutdown of the wireless network in every band. And when an access point drops out, its neighbors react: another vendor’s radio management may raise their power to compensate for the loss of a neighbor AP, reshaping cells while the line runs.
If the plant would not let you reboot a PLC mid-shift, do not let the wireless platform reboot an access point.
How to confirm it
- Pull the management platform's audit log and upgrade schedule, and line them up with the drop timestamps.
- Check access point uptime and reboot reasons in the affected area.
- Check whether automatic or vendor-scheduled upgrades are enabled, and who receives the notices.
- List the configuration changes pushed around the drop, and check which of them restart radios or require the wireless network to be shut down.
The fix
- Turn off automatic upgrades, and schedule every upgrade for planned downtime.
- Pre-load images on the access points, so the reboot is the only outage.
- Hold configuration changes that restart radios for maintenance windows.
- Bring the wireless platform into the plant's change control, with the same approvals as a PLC change.
Prevent it at design time
- Test every firmware release in a lab or pilot area with your real clients before rollout.
- Keep a rollback path, and record the running version of every access point.
- Agree maintenance windows with production, and configure the platform to respect them.
About this page
Built from 5 sources: 1 standards body or lab and 4 vendor documents. Researched and drafted with AI assistance, then reviewed and approved by Ben Rutter on . How pages are made
- First published
- Last updated
Change history (1)
- First published
Cite this page
Plain
Ben Rutter. "Firmware upgrades and config pushes during production." OT Wireless, published October 5, 2026. https://otwireless.com/causes/firmware-upgrades-and-config-pushes/
APA 7
Rutter, B. (2026, October 5). Firmware upgrades and config pushes during production. OT Wireless. https://otwireless.com/causes/firmware-upgrades-and-config-pushes/
BibTeX
@misc{rutter2026firmwareupgradesandconfigpushes,
author = {Rutter, Ben},
title = {{Firmware upgrades and config pushes during production}},
year = {2026},
howpublished = {\url{https://otwireless.com/causes/firmware-upgrades-and-config-pushes/}},
organization = {OT Wireless},
}