Ask your infrastructure team three questions. How many internet-facing appliances does the organization run — firewalls, VPN concentrators, load balancers, mail gateways, the serial-to-IP converter someone racked in 2019? What firmware or software build is each one running? And which of those builds has a vulnerability being exploited in the wild this week?
Most teams can produce a rough answer to the first question, a partial answer to the second, and no answer at all to the third. That third question is the only one that matters, and it is the one nobody owns.
Attackers can answer all three. They have been answering them at internet scale since at least 2023, and the results are not subtle: Mandiant’s M-Trends data put edge and VPN devices at twenty-two percent of all observed exploit paths in 2025 — close to eight times the prior year’s share. On this site we have made the case twice already, once on the Q1 2026 edge-device exploitation epidemic and once on the ransomware dwell-time collapse, that the network edge is where modern intrusions begin. This piece is the other half of that argument: the audit. Not the philosophy of why the edge is dangerous — the actual procedure for measuring how exposed yours is, this quarter, with tools you already have.
The Three Questions Nobody Can Answer
The reason the third question goes unanswered is not laziness. It is that answering it requires three separate datasets to be correct at the same time: a complete inventory of edge devices, an accurate version number for each, and a current cross-reference against what is actually being exploited. Most vulnerability management programs maintain exactly one of those — the cross-reference — and feed it an inventory that is months stale and version data that is whatever the last authenticated scan happened to catch.
The gap is structural. Edge appliances are the assets least likely to have an agent on them, because you cannot install one. They are the assets most likely to be managed by the networking team while the security team owns the vulnerability program, which means the inventory and the triage live in different orgs and reconcile roughly never. And they are the assets most likely to have been bought, racked, and forgotten — the appliance that does one job, does it quietly, and never enters a conversation again until its management interface is on the front page.
That forgetting is the whole vulnerability. Mandiant’s 2025 figures are worth sitting with: the single most-exploited bugs of the year were CVE-2024-3400 in Palo Alto’s GlobalProtect, and CVE-2023-46805 and CVE-2024-21887 in Ivanti Connect Secure. Not a browser, not an email client — VPN gateways. The 2026 numbers describe initial-access handoffs measured in seconds, not days. An appliance you have not looked at since installation is not a low-risk asset because it is quiet. It is a high-risk asset that is quiet.
BOD 26-02 Is the Best Free Audit You’ll Get This Year
In February 2026, CISA issued Binding Operational Directive 26-02, “Mitigating Risk From End-of-Support Edge Devices.” It is legally binding only on federal civilian agencies. Ignore the legal scope and read it as what it actually is: a free, government-funded specification for an audit your organization should already be running.
The directive is useful precisely because it refuses to be vague. It defines an edge device as any technology device that sits on the boundary of the network and is reachable from the public internet — load balancers, firewalls, routers, switches, wireless access points, network security appliances. It sets a clock: inventory unsupported devices within three months, decommission anything reaching end-of-service inside the next twelve months within a year, and — the part most people skip past — stand up a continuous discovery process within twenty-four months. CISA did not invent a new methodology. It wrote down the one good methodology and attached deadlines to it.
The phased structure is the part worth stealing. Inventory first. Exposure second. End-of-support triage third. Continuous discovery as the permanent end state. That ordering is correct, and it is the opposite of how most private-sector programs operate — those start with a vulnerability scan and back into an inventory from whatever the scanner happened to touch. A scan-first audit can only ever find what it can already reach. An inventory-first audit finds the appliance the scanner never had a route to. The rest of this piece walks the BOD 26-02 ordering as a playbook any infrastructure team can run, federal mandate or not.
Step One: Inventory Before You Scan Anything
Start with the data you already own, because it is faster than scanning and it finds devices a scan would miss. Pull every device with a management IP out of your configuration management database, your DHCP reservations, your DNS zone files, your switch ARP and MAC tables, your RADIUS and TACACS logs, and your vendor support portals — Cisco, Fortinet, Palo Alto and the rest will happily list every serial number registered to your account, which is often a more honest inventory than anything internal. Each of those sources is incomplete. The union of them is close to complete, and the disagreements between them are themselves findings: a device in the vendor portal that appears in no internal source is either decommissioned-but-not-cancelled or racked-but-not-tracked, and you need to know which.
Then, and only then, scan — to confirm and enrich, not to discover from zero. Active discovery with an asset platform such as runZero, or unauthenticated nmap sweeps of your routable ranges, will fingerprint device types and catch the hosts your paper records lost. Run the scan from multiple network vantage points; an appliance invisible from the corporate LAN is often plainly visible from a DMZ segment or a partner link.
The deliverable for Step One is a single list with one row per physical or virtual appliance: make, model, role, management IP, network location, and the team that owns it. If you cannot name an owner for a row, that is the most important row in the spreadsheet. Unowned edge devices are the ones that never get patched, because patching is somebody’s job and nobody has it.
Step Two: Get to a Version Number, Then a CVE
An inventory without versions cannot be triaged. For every device on the list, record the exact running firmware or software build — not the major release, the build. “FortiOS 7.4” is not a version; “FortiOS 7.4.3 build 2573” is. The distinction is the entire game, because vendor advisories and the exploited-vulnerability catalogs are precise to the build, and a major-version approximation will mislabel a vulnerable box as safe.
With real version strings in hand, the cross-reference becomes mechanical. Pull the CISA Known Exploited Vulnerabilities catalog as a feed rather than reading it as a webpage:
| |
The KEV catalog crossed roughly 1,480 entries at the end of 2025, with 245 added during the year alone, and a disproportionate share of the recent additions are network and edge appliances. Match your version list against it. Anything that hits is not a “high” finding to be scheduled — it is an active incident-prevention task. Then layer vendor PSIRT feeds on top, because the KEV catalog trails real exploitation by days to weeks, and finish with a templated scanner such as Nuclei, whose community templates fingerprint exposed appliance interfaces and known-vulnerable builds directly.
One opinion, stated plainly: edge appliances do not belong on your normal thirty-day patch cycle. An internet-facing device with a KEV-listed vulnerability should be on a seventy-two-hour clock, full stop. The dwell-time math we laid out earlier on this site — ransomware crews encrypting domains inside an hour of a VPN login — makes “we’ll get it next maintenance window” a sentence with a body count.
Step Three: See Your Edge the Way the Internet Does
Your internal inventory tells you what you own. It does not tell you what is exposed, and exposure is the variable attackers actually query. Close that gap by looking at your own perimeter from the outside.
Run your public IP ranges and your known hostnames through Shodan and Censys. Both index the internet continuously, and both will show you the banner, the certificate, and frequently the product and version of everything you have facing outward — including the things you did not intend to face outward. The findings that matter most here are rarely the data-plane services. They are management-plane interfaces: an SSH daemon, an HTTPS admin portal, an SNMP service, a vendor-specific management port answering from the public internet. A VPN that terminates user traffic on the internet is doing its job. A firewall whose administrative web UI completes a TLS handshake with the internet is a breach with a countdown attached.
Reconcile that external view against the inventory from Step One. Every internet-reachable device should map to a deliberate, documented decision with a named owner. Anything reachable that is not on the list is the highest-priority item in the entire audit — it is, by definition, an asset your attackers have enumerated and you have not. While you are here, pair the outside-in scan with an outbound check: confirm your edge devices cannot themselves initiate arbitrary connections to the internet, because a compromised appliance’s first move is to call home, and a default-permit egress rule is what lets it.
Step Four: Hunt the Devices That Will Never Get Another Patch
BOD 26-02’s specific obsession is end-of-support hardware, and the obsession is earned. A device past end-of-support is not merely behind on patches — it is a device for which the next patch will never exist. When its next vulnerability is disclosed, and it will be, the remediation column in your tracker reads “not possible” on day zero.
Take the version inventory from Step Two and enrich every row with two dates: end-of-sale and, the one that matters, end-of-support or end-of-vulnerability-coverage. Vendor lifecycle pages carry these, and a community resource such as endoflife.date aggregates them across most major appliance vendors for a fast first pass. Sort by the end-of-support date. Everything already past it is a finding today. Everything crossing it inside twelve months is a budget line you need to open now, because procurement, change windows, and migration testing for an edge appliance routinely consume two or three quarters — far longer than the gap between a disclosure and its mass exploitation.
This is the step that turns an audit into a planning document. An end-of-support firewall is not a vulnerability you remediate; it is an asset you replace, and replacement has a lead time. The teams that get breached through end-of-life edge gear are almost never surprised that the device was old. They are surprised that “we knew it was old” turned out to be the entire plan.
Hardening the Edge You Decide to Keep
For every device staying in service, run a short, non-negotiable hardening pass. Get the management plane off the internet entirely — administration belongs on a dedicated management network or behind the VPN, never on a public interface, with no exceptions you have not personally signed off on. Enforce phishing-resistant multi-factor authentication on every VPN and every administrative login; stolen credentials sit as the second-leading initial-access vector in the M-Trends data for a reason, and a password-only VPN portal is a credential-stuffing target with your network behind it.
Turn off the features you do not use. Edge appliances ship with SSL-VPN web portals, legacy management protocols, and convenience services enabled by default, and a wildly disproportionate share of appliance CVEs land in exactly those default-on components. If the box does not need its web VPN, disable the web VPN — and you have pre-emptively closed the next three advisories written against it.
Finally, fix the logging, because the audit you just ran is worthless if you cannot tell when its conclusions stop being true. Ship every edge device’s logs off-box to a SIEM in real time — a compromised appliance’s local logs are attacker-writable and therefore evidence of nothing. Back up device configurations to version control and diff them on a schedule; an unexplained configuration change on a firewall is one of the highest-fidelity intrusion signals you will ever get, and almost nobody watches for it.
When the Audit Finds Something: A Triage Order
You will find things. The audit is not useful because it might come back clean — it is useful because of the order in which you work the list it returns.
Work it in this sequence. First, anything internet-reachable with a KEV-listed vulnerability: this is an active-incident-prevention task, measured in hours, and it outranks every scheduled project you have. Second, internet-exposed management interfaces: pull them behind the VPN today, because this is a configuration change rather than a procurement and there is no honest excuse for latency. Third, end-of-support devices that are internet-facing: if you cannot replace them this week, isolate them — restrict source IPs, force all access through a hardened jump host, shrink the blast radius while the replacement is sourced. Fourth, everything else, on the seventy-two-hour edge patch SLA.
The instinct to fold all of this into the normal vulnerability backlog is the instinct to resist. A KEV-listed bug on an internet-facing VPN and a medium-severity finding on an internal print server are not the same kind of object, and a tracker that sorts them together by CVSS will quietly schedule the one that gets you breached. Edge findings get their own swim lane and their own clock.
The Forty-Five-Minute Version
If you have a single block of time before the next appliance CVE lands, spend it like this:
- Inventory from records, not scans. Union your CMDB, DHCP, DNS, ARP tables, and vendor support portals into one row-per-appliance list. Flag every row with no named owner.
- Pin exact versions. Build number, not major release. No version, no triage.
- Cross-reference the KEV catalog. Pull the JSON feed, match your versions, treat every hit as an incident-prevention task on a 72-hour clock.
- Scan yourself from outside. Run your ranges through Shodan and Censys. Any exposed management interface, or any reachable device not on your list, jumps to the top.
- Date every device. Add end-of-support dates. Anything past it is a finding today; anything within twelve months is a budget line now.
- Harden what stays. Management plane off the public internet, phishing-resistant MFA on every login, unused features disabled, logs shipped off-box, configs diffed.
CISA gave federal agencies three months to inventory, a year to decommission, and twenty-four months to make discovery continuous. You do not have a directive and you do not have those deadlines — which means the only schedule your edge runs on is the one you set this quarter. The appliances are already enumerated. The only open question is whether you are the one holding the list, or whether you are reading it back off someone else’s.