Firewall and VPN Flaws: A Three-Day Patch Plan for Mid-Sized IT

If you run IT for a mid-sized company, the devices that face the internet are probably the ones you touch least. The firewall, the VPN or remote access gateway, the SD-WAN controller and the remote-management tool your managed service provider uses were set up once, they work, and nobody wants to schedule downtime for them.

Last month showed why that habit is now the riskiest one in most environments.

What happened in September

Between September 1 and October 4, 2026, CISA added 47 vulnerabilities to its Known Exploited Vulnerabilities (KEV) catalog, the list of flaws it has evidence attackers are actively using. A large share sat in exactly the equipment described above:

• Remote access and VPN gateways. SonicWall disclosed on September 1 that two flaws in its SMA1000 remote access appliances were being actively exploited; CISA added both the next day. Citrix NetScaler flaws were added on September 9, September 27 and October 4, and an F5 BIG-IP APM flaw on September 22.
• Firewalls and their management consoles. Fortinet and Cisco Firewall Management Center flaws were added on September 9, and two Check Point flaws on September 22.
• SD-WAN controllers. Arista said on September 22 that a flaw in on-premises VeloCloud Orchestrator was known to be actively exploited. On September 30, Cisco published a critical advisory for Catalyst SD-WAN Manager that could let an unauthenticated attacker gain admin privileges, and CISA added it the same day.
• Remote-management tools that MSPs use. N-able N-central was added on September 8 and ConnectWise ScreenConnect on September 11.

Two details matter more than the list itself.

First, the gap between a patch and exploitation varies. Citrix published its fix for one of those NetScaler flaws on August 19, three weeks before it reached the KEV catalog. Teams that patched promptly were ahead. In other cases, such as SonicWall and Cisco SD-WAN, the vendor advisory and the KEV listing arrived within a day of each other.

Second, the vendor’s own wording can lag. On September 6, N-able said it had no confirmation the N-central flaw had been exploited, while urging on-premises customers to upgrade immediately. CISA listed it as exploited two days later. “No known exploitation” in an advisory is not a reason to wait.

What federal agencies now have to do, and why it is a useful model

In June 2026, CISA issued Binding Operational Directive 26-04, which sets federal agencies’ patch deadlines by four questions: is the asset publicly exposed, is the flaw on the KEV list, can an attacker automate the exploit, and does it give partial or total control? For the worst combination, agencies must fix the flaw within three days and carry out a forensic triage to check whether the device was already compromised. Of the 47 KEV additions above, 39 were listed with a due date three days after they were added.

The directive binds federal agencies, not private companies. But its logic fits a mid-sized business well, because it focuses scarce effort on the small number of devices that matter most. Two parts are worth borrowing:

• Exposure changes the clock. The directive says that removing a system from the internet is a valid mitigation that pushes the deadline back. If a management console does not need to be reachable from the internet, closing that access is often the fastest fix available.
• Patching is not the end. CISA’s implementation guidance tells agencies not to alter or remediate systems before collecting evidence, when possible, because patching can destroy the traces of an earlier break-in. Vendors say the same: SonicWall’s advisory tells customers who find indicators of compromise to re-image or re-deploy the appliance, change all user and administrator passwords and reset TOTP tokens.

Building a three-day process without a security team

Most mid-sized IT teams cannot run full forensics on every alert. They can still build a short, repeatable process.

1. Keep an edge inventory. List every device and service reachable from the internet: firewalls, VPN and remote access gateways, load balancers, SD-WAN controllers, email gateways, and any self-hosted remote-management server. Record the vendor, model, software version, who manages it, and whether its management interface is exposed.
2. Subscribe to the right feeds. Sign up for the KEV catalog’s update emails and each edge vendor’s security advisory feed. Assign a named person to read them every business day, with a backup.
3. Pre-approve emergency changes. Agree in advance with leadership that a KEV-listed flaw on an internet-facing device can be patched outside the normal change window. Most of the delay in patching is waiting for permission, not the patch itself.
4. Use the redundancy you paid for. If your firewalls or gateways run as a high-availability pair, practice patching one unit at a time so an update does not mean an outage.
5. Capture before you patch. At a minimum, export the device’s logs and configuration before updating, and check the vendor’s indicators of compromise. Cisco’s SD-WAN advisory, for example, lists specific log files and entries to review.
6. Lock down management interfaces. Restrict administrative access to known addresses or a separate management network. Arista notes that limiting VeloCloud Orchestrator’s web interface to trusted administrative networks can reduce exposure.
7. Know who to call. Decide now which outside firm would investigate if you find signs of compromise, and check what your cyber insurance policy requires you to report and when. Talk to your insurer or attorney about those obligations.

Your MSP’s tools are your attack surface

If an MSP manages your environment, its remote-management platform has a direct path into your systems. Several of the September flaws were in exactly those tools. Hosted versions are often patched by the vendor: N-able said its hosted N-central instances had already been patched, while self-hosted servers needed an upgrade. Find out which kind your MSP runs, and ask for evidence rather than assurances.

Questions to ask this week

• Do we have a current list of every internet-facing device, with its software version?
• Which of those appear in the KEV catalog’s September and October additions, and are they patched?
• Are any management consoles reachable from the internet that do not need to be?
• Who reads vendor advisories and KEV updates each day, and who covers when they are out?
• Can we patch an edge device within three days without waiting for a change board?
• Did we check for signs of compromise, not just apply the update?
• Which remote-management tool does our MSP use, is it hosted or self-hosted, and when was it last patched?
• If we found evidence of a break-in tomorrow, who would we call first?

If you would like an independent review of your edge devices and patching process, get in touch.