Petri’s Amy Babinchak argues that the old model has become indefensible because vulnerability volume and exploitation speed have reduced the safety margin created by waiting. The underlying conclusion holds up, but the operational change should be framed more precisely: the answer is not an uncontrolled same-day deployment to every Windows machine. It is policy-driven automatic deployment with tightly managed exceptions, combined with an asset-lifecycle program for the systems that ordinary endpoint tools cannot patch.
The bigger problem is not whether an administrator can shorten a Windows Update for Business deferral. It is whether the organization can identify, own, isolate, and replace the devices that will remain outside that process.
Microsoft’s guidance has moved the baseline
Microsoft has long supported staged Windows deployments through update rings, and a cautious pilot remains useful. What has changed is the recommended timing. Its current Windows deployment documentation calls for a one-day quality-update deadline and a two-day grace period by default, while advising administrators not to allow more than seven total days from quality-update publication to completion.
That does not mean every organization must select zero days everywhere. Microsoft explicitly says quality-update deferral can be used to evaluate an update in a different ring, but describes two to three days as the outer range worth considering if the goal is to minimize exposure. A business that runs a small pilot ring on day zero, expands to ordinary user devices within a few days, and completes deployment inside a week is still staging deployment. It has simply stopped using delay as its principal control.
The distinction matters for Windows administrators because the policy mechanics are already there. The “Specify deadlines for automatic updates and restarts” policy starts its clock from publication plus any configured deferral, rather than waiting for a machine to reach a restart-pending state. The deadline and grace period are therefore not cosmetic user-experience settings; together they determine how long a known vulnerability may remain unfixed on a managed device.
Microsoft’s Autopatch documentation also supports a split model: automatically approve monthly security updates while retaining manual approval for optional and non-security releases. That is a better fit than treating all Windows updates as equally urgent or equally risky. The monthly security cumulative update is the default automated flow. Preview updates, drivers, feature updates, and exceptional business applications are separate change decisions.
A team still using lengthy quality-update deferrals should not confuse that configuration with a mature deployment process. It is a decision to leave machines exposed longer, and it needs a documented business reason rather than inertia.
July’s vulnerability count proves volume is no longer a triage plan
Petri cited 208 vulnerabilities in Microsoft’s June 2026 security release and 621 in July, including 63 rated Critical and two under active exploitation. The broad point is sound: June and July were unusually large Patch Tuesday cycles, and July included flaws Microsoft marked as exploited.
But the raw total needs care. BleepingComputer counted 570 flaws in Microsoft’s July release, while other security reporting and vendor analyses reported 621 or 622. That discrepancy does not mean one outlet necessarily found a different patch event. It reflects different counting methods: some tallies focus on Microsoft’s own CVEs released that day, while others incorporate the wider set of advisories, product coverage, or Security Update Guide entries.
For operations teams, the useful conclusion is not whether July’s exact number was 570, 621, or 622. It is that a monthly release can now contain hundreds of security issues across Windows, identity infrastructure, collaboration services, cloud components, developer tools, and management products. No technician can reasonably assess every CVE from scratch before patching ordinary user endpoints.
The July release also illustrates why severity alone is not a workable queue. The actively exploited vulnerabilities reportedly affected Active Directory Federation Services and on-premises SharePoint Server—systems that have a very different blast radius from a standard Windows laptop. A patch program needs automatic baseline deployment for broadly managed endpoints, then a separate high-priority route for internet-facing, identity, server, and actively exploited issues.
That requires asset context. Administrators need to know which devices run AD FS, which SharePoint farms are externally reachable, whether a server is a domain controller, whether an application is business-critical, and which owner can authorize emergency maintenance. Without that information, an organization has neither a patching strategy nor a reliable exception process; it has a list of updates and a hope that the right person notices.
The right exception is narrow, owned, and temporary
The temptation after a disruptive update is to slow everything down. That response makes one unstable application the governing condition for thousands of ordinary Windows PCs. It is the opposite of proportional risk management.
A legitimate exception should name the exact application, device group, business owner, technical owner, reason for delayed deployment, compensating controls, and expiry date. “We have legacy software” is not an exception. “Thirty warehouse terminals running Application X cannot accept the September cumulative update until the vendor validates Version Y; the terminals are segmented, have no internet access, and will be remediated by September 22” is an exception that can be managed.
This approach also forces an uncomfortable but necessary decision: some systems cannot be treated as permanent exceptions. If the vendor never validates current Windows servicing, the application may require an isolated virtual desktop, a dedicated subnet, a modernization project, or retirement. A frozen endpoint is not protected because it is important to the business. Its importance is often the reason attackers will value it.
For ordinary knowledge-worker PCs, automatic quality updates should be the default. Use a small production-like pilot ring with no deferral or a very short deferral, monitor installation and restart failures, then allow broader rings to proceed on a fixed schedule. Reserve manual intervention for an identified issue, not a generalized expectation that every Patch Tuesday will break something.
The service desk also has a role, but it changes. Rather than approving every patch manually, staff should investigate failed deployments, repeated reboot deferrals, low-storage devices, incompatible software, and machines that have stopped checking in. Those are the endpoints most likely to remain vulnerable after a supposedly successful rollout.
Endpoint compliance is not an attack-surface inventory
Petri’s most important point is not actually about Windows Update. A clean Intune, RMM, or endpoint-management dashboard does not prove that the network is well patched. It proves that the devices enrolled in that dashboard are reporting.
Printers, multifunction scanners, cameras, network video recorders, conference-room appliances, badge readers, VoIP phones, HVAC controllers, industrial controllers, wireless controllers, and building-management systems often have their own web interfaces, firmware, administrative credentials, and vendor support lifecycles. Many are absent from standard endpoint reporting. Some cannot run an agent. Some have firmware update processes that require downtime or a field technician. Some are still running factory credentials years after installation.
Those devices should not be treated as “non-IT” simply because facilities, operations, physical security, or a third-party installer bought them. If they have an IP address, remote management interface, or a path to business systems, they are an organizational security responsibility. Ownership can be shared, but accountability cannot be absent.
Microsoft Defender for IoT can help organizations discover and monitor operational-technology and IoT exposure, but it does not create firmware packages for vendors that do not publish them, nor can it make an unsupported camera or controller patchable. Discovery is the beginning of remediation, not the remediation itself.
The practical deliverable is a connected-device register that includes the device model, serial or asset identifier, firmware version, location, network segment, business owner, technical owner, administrative-access method, support status, vendor advisory contact, and replacement date. That is more detailed than a generic CMDB entry because firmware and end-of-support status directly determine the risk decision.
The PLC example is real, but it is not a 2026 alert
Petri invokes a U.S. government warning involving Iranian-affiliated actors and programmable logic controllers as evidence that unmanaged devices are an easy target. The example is valid, but the article’s timing is wrong.
CISA’s relevant joint advisory, AA23-335A, was originally published on December 1, 2023 and revised on December 18, 2024—not issued in 2026. It documented Iranian Revolutionary Guard Corps-affiliated actors using the CyberAv3ngers persona to compromise internet-exposed Unitronics Vision-series PLCs, including devices at U.S. water and wastewater facilities. CISA said the actors likely accessed affected devices using default or no passwords, then replaced ladder-logic files, altered remote-management settings, changed ports, and obstructed operators’ ability to restore normal control.
CISA’s recommendations remain directly relevant: remove PLCs from public internet exposure, replace default credentials, put remote access behind appropriate controls, keep supported firmware current, segment operational technology, and maintain an accurate inventory of exposed assets. The advisory is not proof that every office printer or surveillance camera faces the same nation-state threat. It is proof that operational devices with internet exposure and poor credential hygiene can become real-world targets, with consequences beyond a compromised workstation.
That correction strengthens rather than weakens the argument. The lesson is not that a brand-new PLC campaign makes every connected device urgent. The lesson is that known, basic failures—default passwords, exposed administration, unknown firmware, and absent ownership—can persist for years until somebody exploits them.
Patching has to become lifecycle management
The service promise “we patch computers” is too narrow for a network full of connected equipment. The replacement should be: we manage the security lifecycle of connected technology.
That service model has several concrete implications:
- Windows client quality updates should move to automated, ring-based deployment that ordinarily completes within Microsoft’s recommended seven-day exposure window.
- Exceptions should be recorded against named systems, assigned to accountable owners, protected with compensating controls, and reviewed against a firm end date.
- Network discovery and procurement processes should feed a single register for connected devices that do not appear in endpoint-management reports.
- Unsupported or unpatchable equipment should receive a risk classification, segmentation plan, restricted administrative access, and replacement target rather than being marked “accepted” indefinitely.
- Vendor contracts and purchasing standards should require secure initial configuration, firmware support expectations, unique credentials, and a defined end-of-life process.
This is a service-design change, not a scripting exercise. It may require IT to work with facilities, security, operations, manufacturing, and outside installers who historically managed their own equipment. It may also require management to fund replacements for devices that still function physically but no longer have a defensible security posture.
Attackers do not organize their target lists around an IT department’s maintenance calendar or its endpoint-management license count. Windows administrators can shorten routine patch exposure now with update rings, deadlines, and automated approvals. The harder work is making sure the devices outside that flow are visible, owned, segmented, supported, and replaced before their neglected lifecycle becomes the next incident.