The VPN appliance on your perimeter is now the target

An edge appliance concentrates most of what an attacker wants into one box. It is reachable from the whole internet by design, so there is no user to deceive first. It authenticates your workforce, so it holds credentials and session tokens. And once compromised, the attacker's traffic rides the device whose job is to carry remote access, which makes the intrusion look like ordinary remote work.

The economics compound the problem. These products ship as identical units to thousands of organisations, and each unit announces itself: a VPN portal answers unauthenticated requests, and the response usually identifies the product and often the version. One working exploit arrives with a ready-made target list anyone can assemble by scanning. Mass exploitation of a newly published appliance flaw now tends to begin within days, and in several of the campaigns above the exploitation came first and the advisory second.

Your servers run endpoint detection agents that watch for exactly this kind of compromise. The appliance runs a closed operating system that will not accept an agent, produces thin logs, and offers no practical way to capture memory when something looks wrong. Whatever happens inside it stays largely invisible to the tools that would normally tell you.

Appliance patching is structurally slower than server patching. The update is a firmware image rather than a package. It usually needs a reboot, and on a high-availability pair it needs a failover that everyone quietly fears. The device being upgraded also carries every remote worker's connection, so upgrade windows are scarce. The common result is perimeter firmware moving on a monthly or quarterly cycle while the servers behind it patch weekly or continuously.

Visibility is worse too. A scanner that authenticates to your servers and enumerates installed packages often cannot log in to an appliance at all; it infers the version from a banner and is regularly wrong in both directions. Appliances also outlive their support quietly. A firewall that still forwards packets does not announce that its vendor stopped writing patches for it two years ago, and end-of-life edge hardware accumulates at branch offices and behind acquisitions.

Set that against the clock the threat runs on. From its first maturity level, the Essential Eight sets a 48-hour patch window for vulnerabilities in internet-facing servers and network devices when the vendor rates the flaw critical or a working exploit exists. A quarterly firmware cycle against a 48-hour clock is a structural loss. Closing the gap means giving internet-facing devices their own patch schedule and pre-agreed authority to act out of cycle.

None of this can be managed for a device you do not know you have, and most perimeter maps are years old. Rebuild yours from the outside, the way an attacker builds it, then reconcile against what the inside believes.

Even on a 48-hour clock there will be exposed days: the flaw is a zero-day, the fix breaks a client, the reboot window is genuinely impossible. Compensating controls decide what those days cost.

If a device of yours was internet-facing and unpatched during a window of known mass exploitation, treat the patch as the beginning of the response. Check the device for unfamiliar configuration and accounts, rotate every credential that passed through it, revoke active sessions, and hunt behind it. Patching removes the vulnerability. It does not tell you whether someone already used it to get in.

This is where the outside view earns its keep. Mapping the perimeter from outside is the first pass we run in an external exposure review, and the most common finding is a device nobody remembers deploying.

Some appliances should be patched and some should be removed, and that decision deserves to be made explicitly. Hardware past its vendor support date has no patch path and belongs off the perimeter, however well it still performs. A vendor with a sustained record of exploited-in-the-wild flaws is telling you something about the years ahead. A device you cannot patch within days, cannot collect logs from, and cannot restrict carries its full risk every time an advisory ships.

The stronger question is whether the job still needs an appliance at all. Many VPN concentrators exist to give staff access to a handful of internal web applications, and that job is now done better by identity-aware access: publish each application behind an authenticating proxy, enforce device compliance and conditional access in front of it, and remove the always-listening network service from the perimeter. On a Microsoft stack, Entra ID application proxy with conditional access covers much of this without new hardware. Managed file transfer boxes often survive on one partner integration that could move to cloud storage with identity-based sharing. Each move removes a whole class of future advisory.

The Barracuda episode is the precedent worth keeping in mind: some compromises end with the vendor concluding the hardware cannot be trusted again. Retiring an appliance on your own schedule is a far better project than retiring it during an incident. The test to apply this month is short: can you name every device on your perimeter with its firmware version and support status, would you know within a day that a critical advisory affects one of them, and could you patch or disconnect it within 48 hours without convening a meeting? Each no marks a genuine gap, and closing it now costs less, in time and disruption, than closing it once an advisory has already forced the question.