Patching and Vulnerability Monitoring: How Fast Did You Patch Last Week, and Who Knows?

Here is one ordinary week in September 2026.

On Tuesday the 8th, Microsoft released fixes for more than 960 security flaws in one day, the largest single release in its history, and two of them were already being used in attacks. On Wednesday, the federal government’s list of actively exploited products added a Cisco firewall manager, a Citrix remote-access appliance, and a Fortinet product. Thursday added two flaws in MikroTik routers that together hand an attacker full control of the box. Friday added GitLab. The week before, a print-server product called PaperCut had been patched three times in six days, because attackers kept finding a way around each fix.

Nobody at a 30-person company read any of that. Somebody at a 30-person company owns at least three of those products, and probably could not say who is responsible for updating them.

That is the gap this guide is about. It is not a product gap. It is a “who is watching” gap.

Patching and monitoring are two different jobs

Patching is applying the fixes a vendor releases. Every company does some of it, usually by letting Windows update itself.

Vulnerability monitoring is everything around that: knowing what you own, knowing when a fix exists or an attack is under way for one of the things you own, deciding how fast each one needs to go out, and confirming afterward that it actually took. It is the job of noticing.

Most small companies do the first job on autopilot and nobody does the second. The result is a business where the laptops are current and the firewall is running software from the year it was installed.

Why “we patched” was not enough this month

The PaperCut story is worth telling in full, because it is the clearest example of the difference between the two jobs we have seen in a while.

PaperCut makes print-management software that sits on a server in thousands of offices and schools. In late August 2026 two flaws were found in it that, chained together, let an attacker on the internet run code on the server without a password. Security firm Huntress later found evidence of attackers using them from August 26, before any fix existed. PaperCut shipped an emergency patch on August 27. Within about two days attackers had found a way around it, and PaperCut shipped a second. On September 1 it shipped a third. On August 31 the Cybersecurity and Infrastructure Security Agency added both flaws to its list of actively exploited vulnerabilities and gave federal agencies until September 14 to fix them. On September 5, Arctic Wolf reported attackers using the pair against school districts and universities in the United States and Europe, pulling stored passwords off the servers and creating their own administrator accounts.

Now put yourself in the position of a company that did the right thing. Someone saw the August 27 notice, applied the patch that day, and moved on. By the weekend they were exposed again, and nothing told them so. The fix for that is not a better patch. It is someone whose job is to keep watching for a week after the first one.

The boxes nobody inventories

Look at the list from the ordinary week again: a firewall manager, a remote-access gateway, a Fortinet appliance, two router flaws, a print server. Not one of them is a Windows PC.

Every small company owns two or three devices like this. The firewall the previous IT person installed. The Wi-Fi controller. The router from the internet provider. The print server. The network storage box holding the old file share. The phone system. The door controller. They share three properties: they face the internet or sit between it and everything else, Windows Update never touches them, and the vendor publishes security notices that nobody at the company has subscribed to.

They also age out. A maker eventually stops supporting a model, and after that there are no patches to apply, which is the same problem with no fix. Our guide on Windows 10 and Server 2016 end of support covers the version of this that most companies already know about; the appliance version is quieter and usually worse.

Websites have a version of this too. In October 2026 the PHP2Shell flaws hit the software underneath most small business websites, and the oldest versions got no official fix; our PHP2Shell guide covers who has to apply that one.

What good looks like

Six parts, none of which is a purchase.

1. An inventory that includes the boxes. Every PC, server, and network device, with its model, software version, who owns it, and whether it faces the internet. If the list lives in someone’s head, it is not a list.
2. Someone subscribed to the notices. Each vendor on the inventory publishes security advisories. A named person or provider receives them and reads them.
3. Two speeds. A monthly cycle for routine updates, staged to a small pilot group before the whole company so a bad update does not cost a Monday morning. An emergency lane, measured in days, for anything on the exploited list.
4. Verification, not delivery. “We sent the update” and “the update installed and the device rebooted” are different facts. The report you want shows the second.
5. A second look after an emergency patch. As PaperCut showed, the first fix is sometimes not the last. Anything patched in a hurry gets checked again a week later.
6. End-of-life tracking. A date on the inventory for when each product stops getting fixes, and a plan that starts before the date, not after.

This is what “patch management and proactive maintenance” means when it is done properly. It is also why the useful measure is not “do we patch” but “how long between the notice and the fix, and how do we know.”

Five questions for whoever runs your IT

You do not need to understand the answers in detail. You need to notice when nobody has them.

1. What do we own that faces the internet? A good answer is a short list with model numbers. A bad answer is “the firewall, I think.”
2. Who receives the security notices from the makers of those things? A name, or a provider’s process. “They update automatically” is a guess unless someone has checked.
3. How fast did we apply Microsoft’s September 8 release, and how do you know? The answer should be a date and a report, not a feeling.
4. What happens when a maker stops supporting one of our boxes? The answer should include a date for each one and what replaces it.
5. How would we know if one of them had already been hit? This is the hardest question and the most useful. The honest answer for many small companies is “we would not,” which is where the conversation about monitoring starts.

What a well-run patching program looks like

1. A current inventory of every device and program, including the network appliances and the print server, with owner and version.
2. Vendor notices arriving somewhere someone reads them, for every product on that list.
3. A monthly cycle with a pilot group, and a documented emergency lane measured in days.
4. A report after each cycle that shows installs confirmed, not updates sent, and names the machines that missed.
5. A re-check after any emergency fix, one week later.
6. An end-of-support date on every product, and the ones inside twelve months already have a plan.

Where this leaves you

Two questions for this week. “Could someone at our company hand me the list of what we own that faces the internet?” and “When was our firewall last updated, and who did it?” If either answer takes more than a day to find, that is the finding, and it is a common one.

Everything above is process, not equipment. Running that process for companies that do not have someone to run it is most of what our managed IT support is, and the monitoring that answers question five sits in our cybersecurity service. Get in touch and we will start with the inventory.