AI-driven exploitation has turned slow patching from a safety measure into an exposure problem. And IT now has to manage every connected device as part of the service.
The patch window is collapsing, and that means the old services model for patching is collapsing with it. What’s been missing from that news is how you’re supposed to change your service model to deal with this reality.
For years, patching followed a familiar ritual: Patch Tuesday arrives, IT reviews the updates, a pilot group gets them “soon,” and production deployment happens after a cautious delay. Often next week, or next month. That’s how we did it.
That model is no longer defensible as the default.
Then, one day I realized that we had not had a patch failure in months. I didn’t take that as success. I took it as a time to change. Patches got more reliable so we could dial back the babysitting of them. We shifted into letting non-server devices update themselves upon release. Patch failures became rare.
Microsoft’s updated Windows guidance calls for quality-update deferrals of less than three days, installation deadlines of zero or one day, and no more than two days of grace time. The driver is simple: attackers are using AI to identify and exploit weaknesses faster.
Given the speed of AI, I’m surprised to see any delay recommended at all. I expect guidance will continue moving toward shorter and shorter deployment timelines.
If that’s too hard to swallow, then volume alone should make us reconsider who owns patching. Petri reported 208 vulnerabilities addressed in Microsoft’s June 2026 Patch Tuesday release and July’s release included 621 vulnerabilities, 63 rated critical, and two under active exploitation. No technician can responsibly absorb that volume as one task among many.
I am not suggesting that every update should be sent to every production device at the same time. That is not mature patch management. But a slow rollout isn’t automatically mature either. The goal is not reckless speed but to stop treating delay as safety.
If you let Microsoft patch your Windows devices then the rollout is already staggered.
What about that old temperamental application? Sure, handle that one carefully, but don’t set your whole patch policy by what-ifs. AI has made it so that we don’t have the time. Make that one thing the exception to your free-flowing patch process.
Windows patching is only the beginning. The same urgency now applies to every connected device on the network. The endpoint patch report is not the whole attack surface and hackers know it.
Walk through most offices and you will find devices with IP addresses, web interfaces, firmware, administrative credentials, and direct or indirect access to business systems, like printers, scanners, cameras, video recorders, VoIP phones, and many more devices.
They may not run a Remote Monitoring and Management (RMM) agent or appear in Intune. They may not have a convenient patch button. That does not make them less important. In many environments, these devices may now represent the least-managed and most exposed part of the attack surface.
Microsoft does offer Defender for IoT but even that product will only take you so far, because non-PC manufacturers never settled on a standard process for updates.
If this sounds like a theoretical concern, look at the recent U.S. government warning on Iranian-affiliated cyber activity.
In 2026, U.S. agencies warned that Iranian-affiliated actors were exploiting internet-connected programmable logic controllers, or PLCs, across U.S. critical infrastructure. The affected organizations included government facilities and water, wastewater, and energy sectors. The actors manipulated PLC project files and altered data displayed in HMI and SCADA environments, causing operational disruption and, in some cases, financial loss.
CISA’s recommendations are remarkably basic because the basic work is still often undone: remove PLCs from direct internet exposure, change default passwords, use unique and complex credentials, disable unused services and authentication methods, restrict remote access, and apply vendor-provided patches.
That sounds like security 101 but these devices have been typically ignored by IT, because it’s hard if not impossible to automate. Criminals running AI know it and that is exactly why it’s become such a big target now. Your non-PC devices are the low-hanging fruit.
Since the beginning of the PC era, IT has sold its services to management based on downtime for an individual user, application or even an entire network. But it was all patchable until IoT. Now, not every connected device can be patched automatically. Some vendors do not provide updates. “Unpatchable” is not a resolution. It is a risk classification.
For every network-connected device, IT should know the model, firmware level, location, owner, support status, administrative-access method, and replacement plan. Change factory credentials before deployment. Store unique administrative passwords in a managed vault. Rotate them when staff or vendors change. Subscribe to vendor advisories. Apply supported firmware updates through a defined process. Segment devices that cannot be patched, and put an end-of-life date on the risk.
The service offering has to evolve from “we patch the computers” to “we manage the lifecycle and exposure of connected technology.”
Attackers are not waiting for the next maintenance window. Neither should we.
To do:
Management may not be excited about putting HVAC controllers, cameras, printers, and door-access systems on a lifecycle schedule. But attackers do not care whether a device is convenient to manage. If it is connected, exposed, and ignored, it is part of the risk. The patch window is collapsing. The lifecycle window has to expand and your service model has to be updated ASAP.