1.56 Million Routers, One Missing Patch: Why 'Update Available' Doesn't Mean 'Patched' — and How to Close the Gap

On October 15, security researcher Quentin Kaiser re-tested the Belgian gateways affected by Broadcom's WPSplinter Wi-Fi flaws — vulnerabilities that let an attacker within Wi-Fi range execute code without knowing the network password. The result: despite Broadcom stating a patch was available, the gateways he tested from Proximus, VOO, and Orange Belgium were still unpatched. Kaiser estimates around 1.56 million gateways could be affected.

Sit with that for a second. The fix existed. The vendor said so publicly. And 1.56 million devices stayed exposed anyway.

If you manage infrastructure for a living, you already know this is not just a Broadcom or ISP story. It is the story of every patch pipeline where 'the update is released' quietly became everyone's working definition of 'done.' You live the internal version of this every Patch Tuesday: the WSUS console showing green because it has not synced properly in a month, the twelve servers stuck at pending reboot since spring, the workstations that silently fell out of a patch group, the firewalls and switches whose firmware nobody has checked since onboarding.

And when security comes asking 'are we affected by the CVE of the week?', the honest answer in too many shops is: 'Give me a few hours — I need to pull exports from three tools and hope they agree.'

The Problem in Depth: The Gap Between 'Released' and 'Actually Patched'

The WPSplinter situation is a textbook case of a failure mode that exists in every IT environment: patch availability is not patch deployment, and patch deployment is not patch effectiveness. Three separate states — and most tooling collapses them into one misleadingly green checkbox.

Your Current Tooling Doesn't Actually Know What's Patched

• WSUS tells you what you approved, not what machines installed. Stalled syncs, corrupted datastores, clients that stopped checking in months ago — the compliance view decays quietly. A console showing 98% compliant because its data is stale looks identical to one showing 98% compliant because it is true.
• SCCM and Intune compliance lags reality. Devices drift out of collections, check-ins fail silently, and a machine can vanish from your non-compliant report for weeks without anyone noticing. You find out during an audit — the worst possible time.
• MSP stacks make it worse, not better. Patching runs in one tool (Ninja, ConnectWise, Syncro), monitoring in another, tickets in a third. So a failed patch does not create a ticket. A 2am reboot after a deployment is never correlated with the deployment that caused it. And when a machine silently drops out of a patch group, no alert fires — because the tool that knows the patch state is not the tool doing the alerting.

The Pending Reboot Trap

'Installed' is a lie until the kernel reloads. Windows can report an update as installed while the vulnerable binary is still running in memory because the restart never happened.

Every sysadmin has seen this version: a server patched during the March maintenance window, restart cancelled because a director was working late that night, nobody ever circled back. It is now October. Every compliance report since has shown green. The server is still running pre-patch code — and it will be until someone actually checks, or until an incident report explains it in past tense.

The WPSplinter gateways are the same failure at ISP scale: end users were told a fix existed, so the problem was considered handled. Nobody verified. 1.56 million devices.

The Devices Nobody Patches At All

Then there is the class of device that never appears in your patch reporting at all: the branch-office ISP modem, the consumer access point under a desk in accounting, the printer running 2019 firmware, the access switch nobody has logged into since the office opened. No agent, no row in the report, presumed fine. The WPSplinter story is a reminder that 'not visible in the patch console' and 'not vulnerable' are very different statements.

What This Costs You in Practice

• The exposure-report scramble. A disclosure lands Tuesday morning; security wants an impact list by end of day. With fragmented tooling that means an export from the RMM, a WSUS report nobody trusts, and an afternoon in Excel — six hours of work producing a number you cannot fully stand behind.
• Pen-test embarrassments. The tester finds 40 workstations missing a 90-day-old update. Root cause: the machines were moved between patch groups during a re-org and never re-added. The tool had the data; nothing watched the data.
• Reboot roulette. Uncoordinated reboots mean users walk in Monday to logged-off machines and lost work. The helpdesk eats a ticket wave, SLAs slip, patching gets blamed — so next month people delay updates, making everything worse.
• Burnout. The worst part is manual verification: a tech RDPing into 200 machines one by one because, deep down, nobody trusts the compliance report.

None of this is a discipline problem. It is an architecture problem: patch state, monitoring, and ticketing live in systems that do not talk to each other, so verification is manual and failures are invisible.

How AlertMonitor Closes the Gap

AlertMonitor was built on a simple premise: patching is only real when the platform can see the outcome. Because patch management, RMM, infrastructure monitoring, and the helpdesk share one data core, the entire loop — deploy, verify, detect, respond — happens in one place.

One Live Source of Truth for Patch State

Every managed Windows device reports patch status in real time, split into the three states that actually matter: missing, failed, and pending reboot. That last one is a first-class state, not a footnote. Because AlertMonitor treats 'installed but not rebooted' as unpatched, your compliance number finally means what it says.

Deployments That Respect the Business — and Can Be Undone

Deployments are scheduled and staged by department, site, or device group: pilot ring Tuesday at 22:00, wave one Thursday, wave two the following Monday, each window matched to that group's working hours. If a patch breaks an application, you roll the deployment back instead of hand-uninstalling across 40 machines at midnight.

For MSPs this scales across clients: per-client compliance dashboards, cross-client views of who is missing what, and one place to answer 'which of my 30 clients still has unpatched domain controllers?'

Patch State Wired Into Monitoring and Helpdesk

This is where unified architecture changes the outcome, not just the reporting:

• A device that reboots unexpectedly at 2am after an update fires an alert with full context — the device, the deployment, the patch. You know within minutes, not at 8am when the first user calls.
• A failed patch can open a helpdesk ticket automatically, with the device, error code, and deployment already attached. Nothing dies in a log file.
• Monitoring keeps watching machines that just got patched, so a service that fails to come back after a reboot is caught by an alert, not by an end user.

The Same Workflow, Before and After

Teams running this workflow typically go from 'verify patch state across the fleet' being an all-hands afternoon to a ten-minute Monday review — and from learning about patch-related outages from users to getting the alert before the coffee finishes brewing.

Practical Steps You Can Take Today

1. Find every machine sitting on a pending reboot

This is the fastest compliance lie to catch. The following script checks the Windows Update and Component Based Servicing registry markers on each server and exports a hit list:

# List every server with a patch installed that is still waiting on a reboot
$servers = Get-Content '.\servers.txt'

$results = foreach ($server in $servers) {
    $keys = Invoke-Command -ComputerName $server -ScriptBlock {
        @(
            'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired',
            'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending'
        ) | Where-Object { Test-Path $_ }
    }
    [PSCustomObject]@{
        Server        = $server
        PendingReboot = ($keys.Count -gt 0)
        Detail        = ($keys -join '; ')
    }
}

$results | Sort-Object PendingReboot -Descending |
    Export-Csv '.\pending-reboots.csv' -NoTypeInformation

Every row where PendingReboot is True is a machine whose compliance status is currently fiction. Fix those first.

2. Flag machines that have not installed anything in 60+ days

Long patch gaps usually mean a broken update channel, a device that fell out of its group, or a machine someone quietly took off the domain:

# Flag Windows machines with no update installed in the last 60 days
$cutoff = (Get-Date).AddDays(-60)

Get-Content '.\servers.txt' | ForEach-Object {
    $lastPatch = Invoke-Command -ComputerName $_ -ScriptBlock {
        (Get-HotFix | Sort-Object InstalledOn -Descending |
            Select-Object -First 1).InstalledOn
    }
    if (-not $lastPatch -or $lastPatch -lt $cutoff) {
        [PSCustomObject]@{
            Computer  = $_
            LastPatch = $lastPatch
            Status    = 'STALE - VERIFY PATCH CHANNEL'
        }
    }
} | Export-Csv '.\stale-patch-devices.csv' -NoTypeInformation

3. Do not forget the Linux boxes in the estate

Routers are not the only unpatched devices hiding in plain sight — Linux servers that were patched but never rebooted are the exact same trap:

# Check which Linux servers need a reboot to finish applying patches
for host in $(cat server-list.txt); do
  if ssh "$host" test -f /var/run/reboot-required; then
    echo "$host: REBOOT REQUIRED"
  fi
done

4. Turn the cleanup into a managed process in AlertMonitor

Once you know where you stand:

1. Inventory — every managed Windows device shows up in the patch module with live status. No agent-less guesswork, no stale exports.
2. Group — build rings like 'Servers-Pilot', 'Finance-Workstations', or per-client groups if you are an MSP.
3. Schedule — assign each ring a maintenance window that matches its working hours, pilot first, waves after.
4. Roll back when needed — if a wave causes issues, revert the deployment and let monitoring confirm recovery automatically.
5. Let the integrations chase the failures — failed patches become tickets, unexpected post-update reboots become context-rich alerts, and the compliance dashboard becomes the one report you actually trust.

5. Make it a 10-minute Monday ritual

Open the compliance dashboard, filter to missing / failed / pending reboot, and clear the list. A list that shrinks week over week is the only patch metric that matters — and it is the one you will be asked for the next time a WPSplinter-style story makes headlines.

The Takeaway

The Broadcom WPSplinter story is not exotic. One million five hundred sixty thousand devices stayed exposed not because a patch was impossible, but because nobody closed the loop between 'a fix exists' and 'this device is running it.' That loop is exactly what a modern patch pipeline has to close: deploy in controlled stages, verify the true state including reboots, watch the outcome, and prove it on demand. If your current stack cannot do all four in one place, the gap is not theoretical. It is measurable — and it is probably already open somewhere in your estate.

Related Resources

AlertMonitor Patch Management & Software Updates AlertMonitor Platform Overview Book a Demo Patch Management & Software Updates Resources