Why Small-Business Switches Are the Forgotten Tier of Firmware Patching

Zyxel published fixed firmwareFirmware🏠Permanent software programmed into a device's hardware that controls its basic functions. for the GS1900 series on 16 June 2026. Around 17 August, an opportunistic actor exploited the unpatched web interface on 996 of those switches across 48 countries and walked away with their configurations and root credential hashes. CISA added the vulnerabilityVulnerability🛡️A weakness in software, hardware, or processes that can be exploited by attackers to gain unauthorized access or cause harm., CVE-2026-7273, to its Known Exploited Vulnerabilities catalog on 21 September. Two months between fix and mass exploitation is not a fast turnaround by 2026 standards. The switches were not compromised because the attacker was quick. They were compromised because nobody was ever going to patch them.

That is the defining property of the device tier the GS1900 belongs to, and it is worth understanding why before trying to fix it.

The Tier Between Managed and Unmanaged

Enterprise switches get change control, firmware baselines, a vendor support contract and a person whose job includes reading the vendor's security advisories. Unmanaged switches get nothing, and need nothing: they have no management interface, no credentials and no software worth attacking.

Smart managed switches sit between the two and inherit the worst of both. They have a full web management interface, a Linux-based operating system, SNMP, VLAN configuration and an administrative credential, which means they have every attack surfaceAttack Surface🛡️The sum of all points where an unauthorized user could attempt to enter or extract data from a system: exposed services, interfaces, accounts, and integrations. Reducing attack surface means removing reachability, not just patching. an enterprise switch has. They are also priced and marketed as set-and-forget hardware for offices with no network team. They are typically installed by an integrator or an MSP, configured once through a browser, and never logged into again unless something breaks.

Nobody in that arrangement owns the firmware. The integrator finished the job. The customer does not know the device has firmware. The MSP, if there is one, is monitoring servers and endpoints and may not have the switch in its RMM inventory at all. The vendor publishes an advisory to a page nobody in the chain is subscribed to.

Why Standard Patch Programs Miss Them

Most vulnerability management programs are built around three inputs: an asset inventory, an authenticated or agent-based scanner, and a vendor notification feed. Smart managed switches defeat all three.

They are missing from inventory because they were installed as infrastructure, not as assets. The invoice says "network install," not "GS1900-24, serial number, firmware 2.80." A network discovery scan will find an address that answers on port 80, and a web fingerprint might identify the vendor, but the firmware version usually requires logging in.

Scanners do not assess them meaningfully. There is no agent to install, and authenticated scanning of a switch web interface is rarely configured even where it is supported. The result is a scanner finding of "web server detected" at a severity that never triggers a ticket.

Vendor advisories do not reach the right person. Zyxel's advisory for CVE-2026-7273 was published on its security advisory page and credited to external researchers; the revision history still shows only the initial release with no mention of exploitation. An organization that did not already subscribe to Zyxel advisories had no notification. An organization that did subscribe may have had the notification land with someone who did not know the company owned any Zyxel hardware.

The consequence is a device population that is effectively unpatched forever, or until it is replaced. The 564 out of 996 compromised switches still on factory default credentialsDefault Credentials🛡️Passwords, keys, or secrets that ship with software or are silently generated when an operator does not set them. Deployments that never replace these values are open to anyone who reads the documentation or derives the fallback — one of the oldest persistent authentication failure classes. are the clearest evidence: those devices were never administered after installation, so no patching process could have reached them.

What a Working Process Looks Like

Fixing this is less about tooling than about assigning ownership to a device class that has never had any.

Inventory by walking the network, not the spreadsheet. Enumerate every device that answers on a management port, identify the vendor and model, and record the firmware version by logging in. For the devices nobody can log in to because the credential is unknown, that is itself a finding: it means the credential is either a factory default or lost, and either way the device needs a reset and rebuild. This exercise usually finds hardware nobody knew existed.

Assign an owner per vendor. One person or team is responsible for knowing which advisories a given vendor has published and whether any apply. For a small organization, that is a single mailbox subscribed to each vendor's security page plus the CISA KEVCISA KEV🛡️The Known Exploited Vulnerabilities catalog maintained by CISA, listing vulnerabilities actively exploited in attacks that federal agencies must patch by specific deadlines. feed, reviewed weekly. For an MSP, it is a vendor-to-customer mapping so that a Zyxel advisory produces a list of the customers who have Zyxel gear.

Set a patch cadence the hardware can actually meet. These devices need a firmware file downloaded and applied one at a time, and a reboot that takes the segment down for a minute or two. Quarterly is realistic for routine updates. Anything in KEV, anything pre-authentication in the management interface, or anything with public exploitation gets pulled forward to the next available window, which for a branch switch can usually be the same week.

Make exposure a prerequisite, not an afterthought. A device on this tier should never have its management interface reachable from user segments or the internet. Why a "LAN-only" CVSS rating does not mean the internet cannot reach it explains why this control matters more than the patch schedule: a switch on an isolated management VLAN with two-month-old firmware was not in the Zyxel campaign, and a fully patched one that was still exposed will be in the next one.

Plan for end of support. Cheap switches outlive their firmware support by years. Record the vendor's end-of-support date at inventory time and treat any device past it as a replacement item rather than a patch item. The alternative is a device with known, unfixable vulnerabilities on the management planeManagement Plane🌐The interfaces and services used to configure and administer a device, as distinct from the data plane that carries user traffic. On a remote-access appliance the management plane is the admin console; exposing it to the internet or to the user-facing portal is a common root cause of privileged compromise. forever.

Bringing MSPs and Integrators Into the Loop

Where an outside party installed the equipment, the contract usually says nothing about firmware. That is the gap to close. The MSP or integrator should either own firmware for the devices they installed, with a defined cadence and a defined response time for exploited vulnerabilities, or explicitly hand that responsibility to the customer with a device list and credentials. What does not work is the current default, where each party assumes the other is handling it and the answer turns out to be nobody.

For MSPs specifically, network devices belong in the same inventory and alerting pipeline as servers and endpoints. The GS1900 campaign is a case where a single advisory review would have generated a work order for every customer with the affected model, ten weeks before the exploitation started.

After an Incident, the Process Starts With Recovery

If any device on this tier was exposed and unpatched during a known exploitation window, the first step is not to add it to a patch schedule but to treat it as compromised. How to recover a managed switch after its config and root hash were stolen covers the rotation, reflash and rebuild sequence. Only once the device is clean does it enter the cadence described above.

The forgotten tier is forgotten because it works. Switches that pass traffic for five years without anyone logging in feel like a success story right up until a threat intelligence firm publishes a country-by-country count of the ones that were harvested. The fix is unglamorous: know what you own, know who is reading the vendor's advisories, keep the management plane off any network you do not control, and give these devices a maintenance window at least as often as you replace the printer toner.