Securing edge devices: ASD's seven mitigation strategies for firewalls, VPNs and routers

Why edge devices matter. ASD's ACSC reports a concerning increase in incidents that start with a compromised edge device. These are the internet-facing network appliances that sit between the internet and your internal network: enterprise routers, firewalls and VPN concentrators. They are exposed to everyone, hard to monitor, and usually able to reach other systems inside. In an ASD research project across the Australian internet over two months, 17.9 million devices were visible publicly, and about 212,000 of them were edge devices. Fast exploitation of newly published flaws is now standard practice for attackers, skilled and unskilled alike. Zero trust lowers how much you rely on the perimeter, but ASD is clear that it never removes the need for a secure edge.

The guidance. ASD's 'Mitigation strategies for edge devices: Practitioner guidance' (February 2025) was published with international partners. It expands on an executive version and is written for three groups: operations staff who keep the devices running, security staff who handle detection, response and vulnerability management, and procurement staff who choose and buy them. It lists seven strategies in no order of priority, and maps each one to controls in the ISM and partner frameworks. The ASD Essentials for enterprise IT, released on 15 October 2026, also puts boundary services, alongside identity services, in its first priority phase.

1. Know the edge. Find where your network boundary actually is and list every device on it. ASD warns that edge devices often sit outside asset-management tools, play minor roles nobody fully understands, and offer more services to the internet than anyone realises. A common example is a converged firewall that leaves its VPN interface exposed even though the VPN isn't used. Keep an inventory with each device's vendor support dates. Replace end-of-life (EOL) devices before support ends, because they get no more patches, and scan for undocumented devices. If an EOL device can't be replaced straight away, record the risk, add compensating controls and set a replacement date. Even so, ASD strongly recommends replacing internet-facing EOL devices immediately. Organisations enrolled in ASD's Cyber Hygiene Improvement Program (CHIPs) can use its reports to see their edge from the outside.

2. Procure secure-by-design devices. When choosing vendors, look at their patch history, how fast they respond to new vulnerabilities and how openly they disclose them. Prefer products that make you create credentials rather than shipping with defaults. Consider geographic and supply-chain risk, and whether a second source would reduce dependence on one vendor. Check deliveries for tampering. Before first use, flash devices with trusted firmware obtained from the vendor through a trusted channel (ISM-1800), and change all default and pre-configured credentials (ISM-1304).

3. Apply hardening guidance, updates and patches. Harden devices using ASD and vendor guidance; where the two conflict, follow the more restrictive (ISM-1858). Stay on the latest supported release even when no security fix is advertised. Vendors don't always say when an update fixes a vulnerability they found themselves, and they ship fixes and advice for current releases first. Subscribe to vendor advisories by RSS or email. Use the vendor's interim mitigations while you wait for a patch. Consider automatic updates where the device supports them, after weighing the availability risk, because ASD has seen missed patches leave devices exposed for weeks, months and even years. Run a vulnerability scanner at least daily against internet-facing network devices (ISM-1701). The most important step is easy to skip: check for compromise before and after patching, especially when a flaw is already being exploited. A patch closes the hole but does not remove an attacker who is already inside. ASD's own example is Fortinet CVE-2018-13379. ASD warned about it in April 2021, and in September 2021 it was exploited against an Australian organisation whose device had been unpatched for more than two years.

4. Implement strong authentication. Use phishing-resistant MFA on any login interface that faces the internet, such as a VPN gateway (ISM-1682). If a device can't do MFA, use the longest and most complex password it supports and never reuse it (ISM-0417). Store any credentials on the device in salted, hashed and stretched form (ISM-1402), not MD5 or custom encodings. Manage local accounts through a PAM system or secrets manager that can rotate them. Pay particular attention to links into your central identity store. ASD has seen APT40 and Volt Typhoon move from edge devices into networks through central authentication, including through a device service account that could run LDAP lookups against the corporate directory. ASD advises segregating edge devices from the corporate Active Directory forest or equivalent AAA system, or at least weighing that risk carefully against the benefits of central authentication.

5. Disable unneeded features and ports. Audit regularly and turn off what you don't use. ASD's list includes an unused VPN service, APIs that are on by default, older SNMP versions (if you need SNMP, use SNMPv3 from approved hosts only), and whichever IP version you don't run. Disable unused physical ports (ISM-0534).

6. Secure management interfaces. Never expose management interfaces directly to the internet (ISM-1863). That covers web admin pages on standard and non-standard ports, SSH, telnet, SNMP and API endpoints. ASD notes that critical vulnerabilities turn up in management interfaces far more often than in interfaces built to face the internet. Use dedicated management interfaces that keep the control plane separate from the data plane. Restrict who can reach them with ACLs (ISM-0520), and terminate management traffic on a firewall, using private VLANs so that one management network doesn't become a lateral-movement highway.

7. Centralise monitoring for threat detection. Send logs from edge devices in real time to a central logging facility or SIEM (ISM-1405), and use a separate control such as another firewall to limit what the device can send there. The device itself should have no way to modify or delete logs once they leave it. Attackers wipe local logs, and recent appliance campaigns have also evaded built-in integrity checkers, so off-box logs may be the only evidence left. Build a baseline of normal traffic. Investigate unexpected outbound web or FTP connections, large uploads to the internet, connections to internal hosts the device doesn't normally talk to, and any use of the device's directory service account against hosts other than the one it is configured for. Report suspected compromise to the vendor and to ASD through ReportCyber.

Practitioner checklist. Keep an edge inventory with owner, firmware version and EOL date. Run daily external vulnerability scans. Confirm that no management interface answers from the internet, and test from outside. Use phishing-resistant MFA on VPN logins. Give each device's directory service account a single allowed target and alert on anything else. Forward logs off-box in real time and confirm the device can't delete them. Before patching an actively exploited edge flaw, look for indicators of compromise and plan to rebuild if needed rather than just patch. Recent desk examples: Ivanti Connect Secure CVE-2026-104935 (the attacker used the appliance's AD service account and evaded the Integrity Checker), PAN-OS and GlobalProtect, and BeyondTrust Remote Support. Cross-links: vulnerability-management, critical-advisory-intake, cisa-kev, asd-essentials-enterprise-it, logging, pam, active-directory, network-segmentation, vpn, firewall.