Google’s Threat Intelligence Group tracked 90 zero-days exploited in the wild during 2025. The number that matters most for network engineers is this one: 43 of them, nearly half, targeted enterprise infrastructure like firewalls, VPN gateways, and other security or networking appliances.
That should change how we think about the edge.
For a long time, teams treated firewalls, VPN concentrators, and SD-WAN controllers as hardened infrastructure that mostly needed change control and occasional maintenance windows. Attackers are treating them differently. They are high-value control points with privileged access, broad visibility, and, in many environments, slower patch cycles than endpoints or SaaS.
If you own network or security infrastructure, the lesson from Google’s report is simple: your appliances now need endpoint-style urgency for monitoring, patching, and isolation.
The shift is real
According to Google’s 2025 zero-day review, exploitation stayed at an elevated baseline and continued moving toward enterprise technology.
| Year | Zero-days exploited | Enterprise-targeted | Enterprise share |
|---|---|---|---|
| 2022 | 63 | ~25 | ~40% |
| 2023 | 100 | ~40 | ~40% |
| 2024 | 78 | 34 | 44% |
| 2025 | 90 | 43 | 48% |
This is not just “more vulnerabilities.” It is a targeting preference.
Attackers like enterprise appliances because they sit at trust boundaries and often provide a path to:
- initial access without phishing an employee
- persistence outside the normal EDR view
- visibility into high-value traffic flows
- lateral movement across internal segments
That is a brutal combination. A compromised laptop is bad. A compromised edge device can quietly become a platform for visibility, credential theft, and policy manipulation across the network.
Why appliances are such attractive targets
From an attacker’s perspective, a firewall or VPN appliance is almost perfect:
- It is trusted by design. These systems already broker sensitive traffic and enforce access decisions.
- It often runs with elevated privileges. Exploiting it means landing on something already close to the control plane.
- It is harder for defenders to patch quickly. Maintenance windows, HA concerns, and business-critical traffic all slow response.
- It is frequently under-monitored. Many environments still send richer telemetry from endpoints than from network appliances.
That gap matters. If your SIEM, detections, and operational playbooks are centered on servers and laptops, attackers will keep looking for the blind spots at the edge.
Who is burning these zero-days
Google attributed 42 of the 90 zero-days to known actors. Two groups stood out:
- Commercial surveillance vendors, which burned through 15 zero-days
- China-linked espionage groups, which used 12 zero-days and continued focusing on edge and security infrastructure
That should tell us something important. This is not only opportunistic cybercrime. A meaningful share of activity is coming from sophisticated actors willing to invest in infrastructure-focused exploitation because the payoff is high.
What Cisco-heavy environments should take from this
Cisco accounted for several of the zero-days in Google’s tracking, but the bigger story is how often enterprise edge platforms kept showing up in major advisories and active exploitation.
A few examples from the same period:
- critical ASA and FTD issues with remote code execution or auth bypass impact
- large patch bundles across ASA, FMC, and FTD
- actively exploited SD-WAN flaws affecting Catalyst SD-WAN infrastructure
The pattern is bigger than any single vendor, but Cisco shops are a useful example because many enterprises still depend on Cisco for the firewall, branch, and WAN control plane.
If you run Cisco edge infrastructure, the takeaway is not “Cisco is uniquely bad.” The takeaway is that security and network control platforms are now premium targets, and patch latency is part of your exposure.
Four operational changes worth making now
1. Treat network appliances like endpoints
Management-plane activity should be logged centrally and reviewed with the same seriousness you apply to server admin actions.
logging host 10.1.1.100 transport tcp port 6514
logging trap informational
logging source-interface Loopback0
access-list 99 permit 10.0.0.0 0.0.0.255
line vty 0 15
access-class 99 in
transport input ssh
The exact syntax will vary by platform, but the principle is stable:
- ship logs off-box
- reduce management exposure
- monitor admin access and config changes
- assume local logs may be modified during compromise
2. Shorten your patch clock for edge systems
If an exploited vulnerability affects an internet-adjacent appliance, “next quarter” is not a plan.
A useful practical rule:
- CVSS 9.0+ with active exploitation: patch in 24 to 48 hours
- Critical edge-device vulnerabilities without confirmed exploitation: patch as soon as change windows allow
- Anything in CISA KEV: treat as urgent until remediated
Most teams already know this in theory. The harder part is building the operating model that makes it possible.
That usually means:
- predefined emergency maintenance workflows
- tested rollback plans
- inventory of externally reachable control-plane assets
- clear ownership between network and security teams
3. Separate the management plane from the data plane
This is still one of the highest-leverage architectural decisions you can make.
vrf definition MGMT
address-family ipv4
exit-address-family
interface GigabitEthernet0/0
vrf forwarding MGMT
ip address 10.255.0.1 255.255.255.0
no shutdown
If administrative interfaces are reachable from production networks or, worse, from the internet, the blast radius of a single control-plane flaw grows fast.
Dedicated management VRFs, isolated jump paths, and strict source restrictions are not glamorous work. They are still some of the best defenses you can buy with architecture instead of tooling.
4. Don’t let the perimeter inspect itself alone
Inline devices are important, but they should not be your only source of truth.
If a firewall, VPN gateway, or SD-WAN controller is compromised, you want independent visibility through:
- SIEM ingestion from external collectors
- network detection and response where available
- config integrity monitoring
- out-of-band alerting on software version changes or suspicious admin events
When attackers land on infrastructure, one of their first advantages is that defenders tend to trust the box too much.
A practical checklist for this quarter
If you want to turn the report into action, this is a reasonable short list:
- inventory every internet-facing security and networking platform
- verify software versions and maintenance ownership
- review whether management access is isolated and source-restricted
- confirm logs are exported off-device and retained centrally
- add alerting for admin logins, privilege changes, and unexpected config drift
- review emergency patch process for edge infrastructure
- track CISA KEV and vendor advisories as part of normal operations, not ad hoc response
None of this is especially novel. That is what makes the report uncomfortable. The problem is less about inventing new defenses and more about finally treating network infrastructure as a primary security surface.
The bigger takeaway
The most important lesson from Google’s 2025 data is not the exact count of zero-days. It is the direction of travel.
Attackers are increasingly targeting the systems that sit between users and services, between branches and data centers, and between public networks and private ones. Those systems are often run by network and infrastructure teams, not just security teams.
So the job is changing a bit. Running reliable infrastructure is no longer enough. We also need to run it as if it is part of the front line, because it is.
If your patching, monitoring, and segmentation strategy still assumes endpoints are the center of the threat model, Google’s report is a good reason to update that assumption.
Disclosure: This article was adapted with AI assistance from the original FirstPassLab article. AI helped with editing and formatting, and a human reviewed the final version before publication.
Top comments (0)