This week on The Register: suspected Chinese state-sponsored actors ran a phishing campaign that spoofed an Anthropic executive and a former White House official, baiting targets with invitations to a fake AI policy advisory committee. The lure was polished — credible names, a believable subject line, the kind of thing that survives a first glance from a busy executive.
Here is the uncomfortable truth for those of us who run IT: this campaign makes the news, but it probably is not the thing that breaches anyone. Phishing gets the click. What turns a click into persistent access is almost always the same boring thing — an endpoint or server that never got the patch. A known vulnerability, fix published months ago, still sitting on a laptop because the deployment failed silently, the device was offline during the maintenance window, or it has been "pending reboot" since March.
And most IT teams cannot answer "are we actually patched?" with confidence. Ask for a real-time compliance number and watch your sysadmin open WSUS, an Excel tracker, a ConnectWise report, and three RMM tabs. That is not visibility. That is archaeology.
The Problem: Your Patch Status Data Is a Point-in-Time Guess
Most environments are running some combination of these, and all of them share the same disease — stale, siloed patch data:
WSUS still runs in thousands of environments. Approvals live in one console, but the reporting is notoriously unreliable. "100% approved" tells you nothing about what actually installed. Client-side Windows Update agent failures are silent. The machine shows compliant in WSUS and is not compliant in reality.
SCCM/MECM is powerful and heavy, and its compliance dashboards are only as fresh as the last hardware inventory cycle — frequently 7 days or more behind. An executive laptop that missed three cumulative updates will not show up as an exception until the next sync, if anyone is watching the right report.
RMM patch modules (ConnectWise Automate, NinjaOne, N-able, Datto RMM) treat patching as a feature bolted onto an agent. Failures get logged into a report nobody opens. Per-client patch status means clicking into each client individually if you are an MSP. And the patch engine has no idea what your monitoring or helpdesk is doing.
Why These Gaps Exist
- Siloed architecture. The patch module writes to its own database. Monitoring does not know a reboot was scheduled. The helpdesk has no link between an outage ticket and a patch deployment that caused it. Every tool has a partial, contradictory picture.
- Scan-based staleness. "Last scan: 9 days ago" is a 9-day-old answer to a question attackers ask in real time.
- Failures are logged, not surfaced. A patch that fails on 14 machines with error 0x800f0922 does not page anyone. It waits patiently for the quarterly compliance spreadsheet — or for an incident.
- Blind reboots. The patch tool reboots a production server at 2am. Monitoring sees an "unexpected" reboot and either ignores it (no context) or fires a useless alert with no explanation attached.
What It Actually Costs You
Scenario 1 — the phish lands on the wrong laptop. An exec clicks the fake AI advisory committee invite. The credential-harvesting payload executes. That laptop missed the March, April, and May cumulative updates because its deployment failed silently and nobody was notified. The attacker's second-stage tooling now has months of known N-days to escalate with. The phishing training worked on 199 of 200 employees. It did not matter.
Scenario 2 — the blind 2am reboot. A patch window reboots SRV-FILE01 at 2:14am. Users discover it at 8:30. The on-call tech burns 90 minutes cross-referencing the monitoring console, the patch tool, and backup logs because none of them talk to each other. Twenty duplicate tickets hit the helpdesk. One SLA breach. The helpdesk lead spends another hour reconstructing what happened for the incident report.
Scenario 3 — the MSP QBR scramble. Pulling patch compliance for 12 clients from an RMM takes half a day of CSV exports and a spreadsheet with formulas nobody trusts. The number you present at the QBR is two weeks stale by the time you present it.
Anyone who has run patching at scale knows the pattern: 5–15% of machines fail or miss every deployment cycle, those machines are almost never re-tried because nothing flags them, and the "pending reboot" fleet thinks it is patched while running pre-patch code in memory.
How AlertMonitor Closes the Gap
One agent, one console, one live truth about patch state. AlertMonitor's patch management module tracks the patch status of every managed Windows device in real time — which machines are missing updates, which have failed patches, and which are pending a reboot. Not a last-scan snapshot. Live state that updates the moment a device checks in.
Scheduled, staged deployments. Build rings: pilot group, then department, then fleet-wide. Schedule maintenance windows per group — Finance workstations reboot Saturday 22:00, servers follow their own ring with their own window. If a patch breaks a line-of-business app, roll it back from the console instead of remoting into machines at midnight.
Patch status fused with monitoring. This is the part that changes your 2am experience. A server that reboots after an update fires an alert with full context: which deployment, which device group, install succeeded, reboot expected. Not a mystery outage your users discover at 8am and escalate through 20 tickets. And when a machine reboots outside its scheduled window, that anomaly is immediately visible because the baseline is known.
Failed patches become work items, not footnotes. When a deployment fails on a device, the failure surfaces in the console and can flow into the integrated helpdesk with the KB number, the error, and the device history attached. The tech sees it the same day, not at the next quarterly report.
For MSPs: cross-client queries in seconds — every machine in every client missing the October cumulative, one filter. Per-client compliance dashboards you can screenshot straight into the QBR deck.
The old workflow: WSUS console, CSV export, Excel lookups, RMM report, manually chasing offline devices, reboot roulette, hope. The AlertMonitor workflow: dashboard, filter, staged deployment, contextual alerts, live compliance number. A half-day-per-client quarterly scramble becomes a glance at a screen.
What You Can Do Today
Step 1: Find every machine sitting on a pending reboot. These machines think they are patched but are not running the patched code:
$servers = Get-Content C:\Temp\servers.txt
Invoke-Command -ComputerName $servers -ScriptBlock {
[PSCustomObject]@{
Server = $env:COMPUTERNAME
CBSRebootPending = Test-Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending'
WURebootPending = Test-Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired'
PendingFileRename = (Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager' -Name PendingFileRenameOperations -ErrorAction SilentlyContinue) -ne $null
LastBoot = (Get-CimInstance Win32_OperatingSystem).LastBootUpTime
}
} | Export-Csv C:\Temp\RebootStatus.csv -NoTypeInformation
Step 2: Flag the stragglers — machines that have not installed anything in 45+ days:
$stale = Invoke-Command -ComputerName $servers -ScriptBlock {
$last = Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 1
[PSCustomObject]@{
Server = $env:COMPUTERNAME
LastPatchKB = $last.HotFixID
LastPatchDate = $last.InstalledOn
DaysSince = if ($last.InstalledOn) { (New-TimeSpan -Start $last.InstalledOn -End (Get-Date)).Days } else { 999 }
}
}
$stale | Where-Object { $_.DaysSince -gt 45 } | Sort-Object DaysSince -Descending
Step 3: See exactly what is missing on a specific problem box:
Install-Module PSWindowsUpdate -Force
Get-WindowsUpdate -ComputerName SRV-DB01 | Format-Table KB, Title, Size -AutoSize
Step 4: Same visibility for your Linux servers:
# Count pending upgrades without installing (Debian/Ubuntu)
apt-get -s upgrade | grep -c '^Inst'
# List pending security updates
apt list --upgradable 2>/dev/null | grep -i security
Step 5: Stop doing this by hand. In AlertMonitor, create your device groups, define ring deployments with per-group maintenance windows, enable failed-patch ticketing so failures create helpdesk tickets automatically, and turn on context-aware reboot alerts so a post-update reboot arrives as "expected, deployment succeeded" — while an unexpected reboot arrives as exactly that.
The Bottom Line
The phishing campaigns aimed at your organization will get more convincing, not less. AI-generated lures spoofing your vendors, your executives, and the policy committees your leadership actually cares about are the new baseline. You cannot train your way out of every click.
What you can control is the blast radius. The distance between "patch released" and "patch installed, rebooted, and verified" is the single most compressible number in your security posture. When patch status is live, failures create tickets automatically, and reboots carry context instead of chaos, a successful phish stays an incident report instead of becoming a breach story on The Register.
Related Resources
AlertMonitor Patch Management & Software Updates AlertMonitor Platform Overview Book a Demo Patch Management & Software Updates Resources
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.