There is a reasonable assumption baked into most enterprise security strategies: the firewall is the defender. It sits at the edge, it inspects traffic, it keeps the bad stuff out. Organizations spend real money on these devices specifically because of that assumption.
Data suggests the assumption needs revisiting. According to the 2025 Verizon Data Breach Investigation Report, exploitation of vulnerabilities against network edge devices such as firewalls, VPNs, and similar equipment increased 8x in a single year. That same report found that the median time from vulnerability disclosure to active exploitation of these devices was zero days. The median time to patch them was 30 days.
Those two numbers, sitting next to each other, tell you most of what you need to know about who currently has the advantage.
How Firewalls Became a High-Value Target
Firewalls, as targets themselves, were not always this interesting to attackers. For most of their history, they did relatively simple things: inspect packets, enforce rules, and block traffic that didn’t belong. That was a narrow enough scope of requirements that the attack surface stayed manageable.
Over time, the firewall absorbed more functionality. SSL VPN termination became a standard feature. Single sign-on, remote access and web filtering all gradually got folded into the same box sitting at the network edge. That expansion had a meaningful consequence: to provide those services, the device now has to be directly exposed to the internet. A firewall that handles VPN connections cannot hide behind another layer of protection. It has to be reachable, by design.
Threat actors noticed. The 8x spike in exploitation documented by Verizon reflects years of accumulated attacker investment in understanding exactly how these devices work and where they break.
The Layer You Cannot See
Here is what makes this problem structurally difficult, beyond the usual vulnerability management challenges.
Modern firewalls from major vendors run Linux underneath their vendor operating systems. Fortinet runs FortiOS on top of Linux. Palo Alto runs PAN-OS on top of Linux. Cisco IOS-XE operates as a separate process on top of a Linux kernel. Sophos too. The vendor OS is what administrators interact with: the management interfaces, the configuration tools, and the dashboards. But the underlying Linux layer is where the actual services live, including the SSL VPN daemon that listens on its port and handles incoming connections.
Vendors do not give customers access to that underlying Linux layer. For customers, gaining that access through other means would essentially require jailbreaking the device, which would void support agreements and likely violate the terms of the vendor relationship. So, as an administrator, your visibility stops at the vendor OS. You can see what the management interface shows you, and not much else.
When an attacker successfully exploits a remote code execution vulnerability in one of these devices, they get root access to the Linux layer that you cannot reach. From that position, they can do things that are effectively invisible to standard monitoring. They can hook the authentication process so that, as legitimate users log in through the VPN, their Active Directory credentials are written to a file in plain text that the attacker can retrieve later. They can create their own local VPN accounts for persistent access. They can install malware that survives reboots. In documented Fortinet campaigns, attackers used symlink attacks to maintain access that persisted even through firmware updates. Palo Alto GlobalProtect VPN systems were among most commonly exploited technologies in incidents covered in Mandiant’s 2025 m-Trends report. In late 2025, Cisco Firewall Threat Defense (FTD) devices were also targeted with numerous actively exploited vulnerabilities enabling root level remote code execution. Sophos firewalls were pivotal in the massive Pacific Rim APT threat campaign disclosed in 2024.
There is a shared responsibility gap embedded in all of this. When an enterprise buys a firewall appliance, the reasonable expectation is that the vendor has hardened the device better than the customer could do themselves. The customer is, in a meaningful sense, delegating part of their security posture to the vendor. But the customer has no way to verify that the underlying system is actually in the state they need it to be, and virtually no tools to monitor it if anything changes. The vendor controls that layer, and it is not providing the visibility needed to verify and mitigate risk.
What Attackers Do With That Access
The firewall itself is rarely the adversary’s end goal. It is the starting point.
Once an attacker has root access to a compromised firewall, the natural next moves are lateral. Active Directory is a common first pivot: with harvested credentials and VPN access already in hand, moving into the broader network is straightforward. VMware ESXi and vCenter environments are another documented target, with multiple threat actor campaigns showing specific tooling built to exploit those systems once access through the firewall is established.
The incident in Poland disclosed in January 2026 illustrates how far that chain can extend. More than 30 renewable energy facilities were compromised in a coordinated attack that used firewalls as the initial entry point. From there, attackers attempted to deploy malware targeting remote terminal units and human-machine interfaces (the physical control systems that operate energy infrastructure). The malware was designed to cause damage to physical equipment. The attack was caught before that damage occurred, but only barely.
In that scenario, the line between a network intrusion and physical infrastructure damage ran directly through a compromised firewall.
Eclypsium researchers put together a complete attack chain that illustrates, using real vulnerabilities, how an attacker can use a firewall as an initial intrusion point and a base for persistence and lateral movement. Below is a condensed illustration of how attackers compromise firewalls, move laterally, and escalate privileges inside the target network. For a complete walkthrough of the attack chain with real CVEs and TTPs, check out our recent webinar: Firewalls Under Fire: How To Secure The Edge Against Cyberattacks
Why Patching Alone Falls Short
Patching is necessary. It is not sufficient on its own, for a few reasons worth spelling out.
Attackers are already scanning for your devices before any vulnerability is disclosed. Security researchers at GreyNoise and others have documented patterns in which scanning activity targeting specific device types spikes significantly in the days or weeks before a new vulnerability is announced. This suggests that threat actors often know what they are looking for before defenders do. By the time a CVE is published and an organization begins its patching cycle, exploits may already be in active use.
The math gets worse from there. Once a patch is released, attackers reverse-engineer it to understand exactly what was fixed. That process moves quickly, and the result is that newly disclosed vulnerabilities often see exploitation attempts within hours of the patch being made available. The 30-day median patching window in the Verizon data represents a substantial period of exposure even for organizations with functional patch management programs.
And patching does not clean a device that is already compromised. Documented attacker techniques are specifically designed to survive reboots and firmware updates. If a device has been implanted, applying a patch closes the vulnerability that was initially exploited but leaves the attacker’s foothold intact. In February 2026, CISA issued a warning about RESURGE malware that targets Ivanti Connect Secure devices. BleepingComputer noted that the latest RESURGE malware can “decrypt, modify, and re-encrypt coreboot firmware images and manipulate filesystem contents for boot-level persistence.”
There is also a large population of devices that are not getting patched at all. A basic Shodan query returns roughly 575,000 internet-facing Fortinet devices. Many of those are running older FortiOS firmware, either because the organization has not prioritized the update, because the device is approaching end-of-life, or because it is not covered by an active support contract. Without a valid support agreement, firmware updates from most major vendors are not available. Some of these devices are purchased secondhand for a few hundred dollars and put into production without the license required to receive security updates.
What Actually Needs to Change
None of this means organizations should rip out their firewalls. It means the mental model around them needs to be updated.
The first shift is treating the firewall as an attack surface that requires monitoring, not just a control that provides monitoring for everything else. The device needs the same level of scrutiny applied to it as to network traffic. That means tracking firmware integrity over time, monitoring for configuration changes like the creation of unexpected local user accounts, and having visibility into what the device is doing rather than only what it is blocking.
The second is holding vendors accountable for the shared responsibility gap. The current arrangement, where defenders are locked out of the underlying OS while attackers are not, is a structural problem that vendor policy is creating, and vendors could change. Customers should be pushing for better telemetry access, eBPF monitoring capabilities, and clearer documentation of what the vendor is actually responsible for securing. These conversations are easier to have when backed by specific incidents and specific asks.
The third is not treating the firewall as the final line of defense. Defense in-depth applies to the edge device itself: host-based controls, monitoring for lateral movement from the perimeter inward, and integrity checking that can catch early signs of compromise before an attacker has had time to establish a durable foothold.
CISA issued a binding operational directive (CISA BOD 26-2) in early 2026 requiring federal civilian agencies to inventory their end-of-support edge devices, decommission them within defined timeframes, and establish continuous discovery processes. The directive is aimed at federal agencies, but the underlying concern applies broadly. The organizations ahead of this problem are not waiting for a compliance deadline to determine what they have and whether it can be trusted.
The firewall is not going away. The on-premises firewall market continues to grow, which means this attack surface is expanding, not contracting. Treating these devices as the perimeter of your security posture rather than part of the attack surface you need to defend is a gap that threat actors are already exploiting at scale.
For a deep dive into firewall cyber risk, check out our webinar: Firewalls Under Fire: How To Secure The Edge Against Cyberattacks
