Cyber resilience often fails at the places leaders rarely discuss.
Not the flagship cloud platform. Not the main customer application. Not the security dashboard that appears in the board pack.
It fails at the edge: the firewall, VPN gateway, SD-WAN controller, router, branch appliance, serial-to-IP converter, remote-access portal or supplier-managed device that connects the organisation to the outside world.
This includes devices owned and operated by external suppliers or managed service providers, not only those managed in-house.
Those devices used to be treated as network infrastructure. They now need to be treated as critical resilience control points.
The reason is simple. If an attacker can compromise the edge, they may not need to break every internal system. They may be able to steal configurations, reuse credentials, create persistence, observe traffic, move laterally, impersonate trusted devices or disrupt the connectivity that keeps branches, cloud services, operational sites and suppliers working.
That makes the edge a board issue, not just a network operations task.
Why this matters now
The NCSC alert on Fortinet firewalls and VPN gateways is a useful starting point. Published on 18 June and still prominent on the NCSC homepage today, it warned that Fortinet firewalls and VPN gateways had been targeted globally, with indications of potential impact in the UK.
The alert said a database of credentials had been leaked by a threat actor after brute-force, dictionary and credential-stuffing attempts against internet-facing FortiGate and VPN portals. Its recommended actions are not cosmetic. Organisations are told to investigate potentially malicious activity, check affected domains, look for unauthorised account creation, isolate compromised devices, preserve useful artefacts, factory reset where needed, investigate connected devices and harden the rebuilt system.
That is recovery language, not routine maintenance language.
A second signal came from Google Cloud's Mandiant team on 24 June. Mandiant described a threat actor targeting Cisco Catalyst SD-WAN infrastructure at a service provider in early 2026. The actor gained initial access, manipulated administrative credentials, exploited CVE-2026-20245 to escalate to root-level access and used anti-forensic techniques to reduce the chance of detection.
The commercial point is not the CVE number. It is that SD-WAN managers are control points for distributed organisations. Banks, retailers, healthcare providers, technology services firms and other multi-site organisations use SD-WAN to connect branches and cloud services. If that control plane is compromised, the impact can reach far beyond one appliance.
Forescout added a third signal on 25 June with research into active exploitation of Lantronix and OpenWRT LuCI devices. Its researchers identified exploitation of CVE-2025-67038 against Lantronix serial-to-IP converters and observed more than 4,100 brute-force login attempts against OpenWRT devices between 28 January and 6 June. They also estimated that around 32,000 internet-exposed devices were running OpenWRT LuCI.
Those are different technologies, but the resilience lesson is the same: exposed edge devices are being found, tested and abused at speed.
The Five Eyes cyber security agencies made the broader context clear on 22 June. They warned that AI is increasing the speed, scale and sophistication of cyber threats, shrinking the window between vulnerability discovery and exploitation. Their practical advice included reducing attack surface, accelerating patching, addressing legacy systems, strengthening access controls and preparing for incidents before they happen.
That guidance applies directly at the edge.
The edge is where exposure becomes reach
An internet-facing edge device is not just another asset in the inventory.
It is a pathway.
It may terminate remote access. It may manage encrypted tunnels. It may hold configurations, certificates, routing rules, administrator accounts, service credentials, supplier access and logs. It may connect offices, data centres, cloud environments, operational sites and third-party networks.
That means the risk is not only that the device itself goes down.
The larger risk is that the device gives an attacker reach. A compromised gateway can become a vantage point. A stolen configuration can show how the network is built. A reused administrator password can open another system. A trusted peering relationship can make malicious access look normal. A device with weak logging can let the attacker clean up before anyone understands the blast radius.
This is why edge resilience has to start with critical services, not asset lists.
Leaders should know which edge devices support customer journeys, payment flows, logistics, plants, branches, identity infrastructure, call centres, cloud administration, supplier operations and crisis communications. They should also know who owns those devices, who can change them, how quickly they can be patched, which suppliers manage them and what evidence will exist after a suspected compromise.
Without that context, organisations may patch devices in priority order by severity score while missing the systems that matter most to business continuity.
Patching matters, but it is not the whole answer
The obvious response to an exploited edge-device vulnerability is to patch faster.
That is necessary. It is also incomplete.
The NCSC's patch-wave guidance, published in May, anticipated this problem. It advised organisations to identify and minimise internet-facing attack surfaces and to prioritise perimeter technologies before moving inward. It also warned that patching alone may not be enough where legacy or end-of-life technology cannot receive updates.
The Fortinet alert illustrates the same point in operational terms. If a device may have been compromised, changing credentials may not be sufficient. Organisations may need to isolate it, collect logs and configurations, factory reset it, investigate reachable systems and harden the rebuilt system before returning it to service.
That sequence matters because an edge compromise can outlive the original vulnerability.
Attackers may have copied configurations, collected credentials, created accounts, changed trust relationships, planted persistence, or learned enough about the environment to try another path later. A patch can close the door that was used today. It does not automatically prove that nobody is still inside, that no credentials were reused elsewhere, or that the device can be trusted again.
That is why the executive question should change from "are we patched?" to "are we clean, contained and resilient?"
The answer requires asset visibility, ownership, vulnerability intelligence, logging, credential rotation, supplier coordination, segmentation, recovery evidence and a decision process that can move at incident speed.
Edge devices often have an evidence problem
Mandiant's Cisco SD-WAN analysis is especially important because it highlights the evidence challenge.
The actor it described used anti-forensic cleanup: deleting files, restoring modified configurations and checking whether indicators had been removed. Mandiant also noted that network appliances often lack the telemetry needed for deep forensic analysis, while their role can provide persistent visibility into internal traffic.
That creates a difficult leadership problem.
During an incident, boards and executives need answers. Which device was affected? What did the attacker reach? Were credentials or certificates copied? Which branches, suppliers or critical services are exposed? What evidence supports the containment decision? Is the device safe to return to service?
If logs are thin, overwritten, unavailable or destroyed during a reset, those answers become harder to prove.
The NCSC Fortinet advice recognises this tension by telling organisations to obtain logs, configurations and other useful artefacts before a factory reset, because the reset process may destroy them.
This is where edge resilience becomes an operating model. Organisations need to know in advance how they will preserve evidence, who can authorise disruptive action, what telemetry is collected centrally, when a supplier must hand over logs, how compromised configurations are reviewed and how assurance will be reported after containment.
Evidence should not be improvised while an attacker may still be inside the device.
Supplier management changes the clock
Many edge devices are not managed entirely by the organisation that depends on them.
A managed service provider may operate the firewall. A network provider may manage SD-WAN. A vendor may hold support access. A facilities or operational technology supplier may own a gateway that connects physical systems. A cloud or telecoms partner may be needed to change routing, certificates or access rules.
That creates a clock problem.
When an edge compromise is suspected, the organisation may need answers and action in minutes or hours: isolate the device, preserve evidence, revoke access, rotate credentials, disable supplier sessions, identify reachable systems, approve downtime, communicate with regulators or customers and recover minimum viable connectivity.
If the contract only says that a supplier will provide "reasonable assistance", the clock is already against the organisation.
Supplier assurance needs to be more precise. It should define named contacts, emergency authority, logging obligations, evidence handover, patch and upgrade commitments, credential ownership, configuration backup, recovery responsibilities, incident notification routes and the circumstances in which the organisation can demand isolation or rebuild.
The UK Cyber Security and Resilience Bill policy direction points towards stronger supply-chain expectations and managed-service-provider duties. Edge-device resilience is exactly the kind of dependency that will make those obligations real in practice.
The board-level edge resilience test
Boards do not need to review firewall rules. They do need assurance that edge-device risk is governed as part of cyber resilience.
There are seven practical tests.
First, can the organisation identify every internet-facing device, including assets managed by suppliers, subsidiaries, operational sites and branch locations?
Second, can it link those devices to critical services, so the most important gateways and controllers are obvious before an incident?
Third, are externally exposed devices patched, supported, hardened and monitored with priority over lower-impact internal systems?
Fourth, does the organisation know which credentials, certificates, administrator accounts and supplier access paths exist on those devices?
Fifth, can it detect suspicious behaviour that looks like administration, such as unusual logins, configuration exports, credential changes, rogue peering, unexpected routes or new accounts?
Sixth, can it preserve enough evidence to make defensible containment and recovery decisions?
Seventh, has it rehearsed the disruption of isolating, resetting, rebuilding or replacing a device that critical services depend on?
If the answer to any of those questions is unclear, the board should assume that the edge is not yet a resilience control point. It is still a technical dependency.
The Antares perspective
Antares sees edge-device resilience as a practical test of cyber leadership.
The issue is not whether the organisation owns firewalls, VPN gateways, SD-WAN controllers, routers and IoT gateways. It almost certainly does. The issue is whether leaders can explain how those devices are owned, protected, monitored, recovered and governed in relation to the services that keep the organisation running.
That starts with exposure mapping. Which devices are visible from the internet? Which are in scope for critical services? Which are managed by suppliers? Which are unsupported, hard to patch or poorly logged? Which can affect customers, revenue, safety, regulated operations or crisis communications?
It then moves to operating discipline. Each important device needs a clear owner, a patch and hardening route, credential and certificate governance, centralised logging, supplier obligations, response authority and a tested recovery path.
The important phrase is "tested recovery path".
Leaders should not wait for an active compromise to discover that a factory reset destroys evidence, that configuration backups are incomplete, that the supplier cannot respond out of hours, that the only engineer with device knowledge is unavailable, or that isolating one gateway breaks a critical business process.
Edge-device compromise is not a niche network scenario. It is an increasingly common way for attackers to gain reach, hide from conventional endpoint tooling and turn technical exposure into operational risk.
The edge is where the organisation meets the threat. It should also be where resilience is deliberately designed, evidenced and rehearsed.
The edge is where attackers try to turn external exposure into internal reach.
Antares recommended actions
These are Antares's recommended first actions for organisations turning the issues in this article into practical governance and delivery.
- Create an authoritative edge inventory that includes firewalls, VPNs, SD-WAN controllers, routers, remote-access gateways, branch appliances, operational technology gateways, IoT gateways and supplier-managed devices.
- Map edge devices to critical services, prioritising the devices that support customer delivery, payments, operations, plants, logistics, cloud access, supplier integration and crisis communications.
- Reduce unnecessary exposure by removing unused remote-access services, closing internet-facing management interfaces, retiring unsupported devices and challenging whether each exposed service still needs to be exposed.
- Patch and harden by business impact, applying urgent updates first to externally exposed devices that support critical services and confirming secure configuration after the update.
- Govern credentials and certificates by rotating default, reused and shared administrator credentials, enforcing strong MFA where supported and tracking certificates and service accounts.
- Improve edge telemetry by centralising logs, preserving configuration history, monitoring unusual administration and making sure the SOC knows which edge signals matter.
- Prepare evidence before reset by defining which logs, configurations, artefacts and supplier records must be captured before a device is isolated, reset or rebuilt.
- Test recovery under pressure by rehearsing isolation, reset, rebuild, replacement and failover scenarios for the edge devices that matter most.
- Tighten supplier obligations so managed network and device suppliers have clear patching, logging, notification, evidence handover and emergency action commitments.
- Report edge resilience to the board, showing exposure reduced, priority devices patched, unsupported assets removed, supplier dependencies clarified, monitoring improved and recovery tested.
