SSL VPNs, firewalls, load balancers, routers and remote access gateways are the front door of a corporate network: they have to be reachable from the internet, they sit on the boundary between inside and outside, and they are usually wired into authentication. That makes them the first thing many attackers try to take. In February 2025, CISA and partner agencies from Australia, Canada, the UK and elsewhere jointly released guidance on edge devices, warning that foreign adversaries routinely exploit software vulnerabilities in network edge devices to infiltrate critical infrastructure networks and systems[1]. Verizon's 2026 Data Breach Investigations Report (DBIR) likewise finds that 31% of breaches now start with the exploitation of software vulnerabilities, overtaking stolen credentials as the most common way in[2].

This checklist is for network administrators, security staff and IT managers responsible for edge devices. For how to read the vulnerabilities themselves, pair it with zero-day and n-day vulnerabilities and patch prioritization.

Why edge devices are especially exposed

  • Anyone can reach them: edge devices have public IP addresses that can be scanned and contacted from anywhere, and because they broker traffic between internal and external networks, attackers invest heavily in finding ways around them[3].
  • Broad reach and privilege: edge devices typically have wide network reach and integrate with identity management systems, so compromising one affects far more than a single box[4].
  • A long record of exploitation: the multinational list of the most routinely exploited vulnerabilities of 2023 includes edge device flaws in Citrix NetScaler ADC/Gateway, Cisco IOS XE and Fortinet FortiOS SSL-VPN, and most of the top vulnerabilities on that list were first exploited as zero-days[5]. The same advisory notes that attackers have the most success with vulnerabilities in the two years after disclosure[5], so old, unpatched flaws remain dangerous.
  • Hard to prove clean: these are mostly closed appliances, and attackers can overwrite files and alter timestamps to cover their tracks; in the Ivanti cases, CISA confirmed that the vendor's own integrity checking tool failed to detect compromise[6].

1. Shrink the attack surface: keep management interfaces off the internet

CISA's Binding Operational Directive 23-02 requires US federal agencies to act within 14 days of finding a management interface for a router, switch, firewall, VPN concentrator, proxy, load balancer, or out-of-band server management such as iLO or iDRAC that is reachable from the public internet: either remove it from the internet or protect it with zero trust access controls enforced separately from the interface itself[7]. The directive binds only federal agencies, but it is a sound baseline for any company. The Canadian Centre for Cyber Security (CCCS) likewise advises that management interfaces should not be directly exposed to the internet and that management should take place only from an out-of-band network[3].

In practice:

  • Scan all of your public IP ranges from the outside and confirm that HTTPS, SSH, SNMP and other management services are not exposed.
  • Bind management interfaces to an internal management network only, or require access through a jump host or zero trust access gateway.
  • Disable services and ports you do not need, and change every default account and password[3].
  • Restrict outbound connections from SSL VPN appliances to the services they actually need, which limits an attacker's ability to download tools or reach command-and-control servers[6].

2. Patch cadence and intelligence sources

  • Keep an inventory: vendor, model, firmware version, exposed services, owner and end-of-support date for every device.
  • Subscribe to vendor PSIRT advisories: every major network vendor publishes security advisories with email notification; make sure someone subscribes to, and reads, the feed for every brand you run. In Taiwan, also follow TWCERT/CC's vulnerability alerts, which cover firewall and VPN products among others[8].
  • Use KEV to judge urgency: CISA's Known Exploited Vulnerabilities (KEV) catalog is the authoritative list of vulnerabilities exploited in the wild, and CISA recommends using it as an input to vulnerability prioritization[9]. Once an edge device vulnerability is on it, treat it as urgent. See CVE, CVSS, EPSS and KEV for reading beyond the score.
  • Test, then apply quickly: CCCS recommends applying security patches promptly after testing, through a scheduled or monitored patching process[3]. For edge device flaws known to be exploited, measure the timeline in days; if you cannot patch yet, apply the vendor's mitigations or temporarily disable the affected feature.

3. Strong authentication and off-device logging

MFA on VPN and every admin account

  • Require MFA for all VPN users and administrative accounts, and use phishing-resistant MFA for administrative access[3]. See the MFA implementation guide for how the options compare.
  • Centralize admin authentication with role-based access, and avoid shared admin accounts[3].
  • Give service accounts configured on the device, such as LDAP bind accounts into Active Directory, the least privilege possible. After an incident, CISA advises assuming that user and service account credentials stored on the appliance are likely compromised[6].

Send logs somewhere other than the device

A compromised device's local logs cannot be trusted and may be wiped. CCCS recommends centralized, off-device logging with detailed log levels, and alerts on administrative logons, configuration changes and hardware changes[3]. At a minimum, collect VPN sign-in successes and failures with source IPs, admin logons, configuration changes, firmware updates, reboots, and outbound connections initiated by the device itself. Synchronize device clocks with NTP, and keep logs long enough, ideally several months, to check later whether anything unusual happened before a vulnerability was disclosed.

4. End-of-support devices: replace, don't postpone

End-of-support (EOS) devices no longer receive security updates, so any vulnerability found from then on stays open for good. In February 2026 CISA issued BOD 26-02, citing widespread exploitation campaigns by advanced threat actors targeting EOS edge devices; it requires federal agencies to decommission listed EOS devices within 12 months, remove all identified EOS edge devices within 18 months, and within 24 months set up a continuous process to find devices approaching end of support[4]. CCCS also recommends maintaining an inventory, reviewing upcoming end-of-support dates, and replacing devices before support ends or applying compensating controls[3].

For a company, that translates into adding an "end of support" column to the inventory and budgeting replacements a full budget year ahead. Devices that cannot be replaced on time should at least lose any internet-facing services, get closer monitoring, and be recorded as a risk that management has formally accepted.

5. After a disclosure: patching is not the end, check for earlier compromise

Edge device vulnerabilities are often exploited before they are public. Patching stops future exploitation, but it says nothing about what happened before. Two cases worth remembering:

  • Fortinet symlink persistence: in April 2025 Fortinet disclosed that, after exploiting known FortiGate vulnerabilities, a threat actor created a symbolic link in the folder that serves SSL-VPN language files, giving read access to files including configuration, and that the link could survive an upgrade to a patched version. Fortinet recommended upgrading to specific fixed versions, reviewing the configuration of all devices, and treating all configuration as potentially compromised[10].
  • Ivanti integrity checks that missed compromise: in February 2024 CISA and partners reported that Ivanti's integrity checking tool failed to detect compromise in multiple Ivanti Connect Secure incidents, and CISA's lab research showed an attacker might keep root-level persistence even after factory resets and upgrades[6].

So when a vendor says your device model is being actively exploited:

  1. Run the vendor's integrity check or IoC scan, but do not treat a clean result as proof of a clean device[6].
  2. Use your external logs to look back for unusual logins, configuration changes and outbound connections before and after disclosure; see using IoCs.
  3. Reset credentials, certificates and service account passwords stored on or handled by the device[6].
  4. If you find signs of compromise, follow the first 24 hours, and rebuild from a clean image or replace the device if necessary.

Action checklist

  • Build an edge device inventory, including firmware versions and end-of-support dates, with a named owner for each device.
  • Scan your public IPs from outside and close any exposed management interfaces and unneeded services.
  • Subscribe to PSIRT advisories for every brand you run, TWCERT/CC vulnerability alerts, and this site's alerts.
  • Set a rule: edge device vulnerabilities listed in KEV or flagged by the vendor as exploited are patched or mitigated within days.
  • Enforce MFA on all VPN and admin accounts, with phishing-resistant MFA for administrators first.
  • Forward logs to an external system and alert on admin logons and configuration changes.
  • Budget replacements for devices that are already end-of-support or will be within a year.
  • Write the "edge device actively exploited" procedure in advance (integrity check, log review, credential resets, rebuild decision) and rehearse it against recent cases in advisories.