How to replace or lock down exposed VPN portals and other edge devices

VPN gateways, firewalls and other edge devices sit on the boundary of the network, accept connections from anyone on the internet and often run with limited logging. That combination has made them a favourite entry point for ransomware groups and state-sponsored actors. In February 2025, the Canadian Centre for Cyber Security (Cyber Centre) and its Five Eyes partners published a series of joint publications on the problem, including the Cyber Centre's Security considerations for edge devices (ITSM.80.101). In February 2026, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) went further for federal agencies, ordering them under BOD 26-02 to remove edge devices that are past end of support.

This guide applies that guidance to a typical Canadian organization in two phases: secure what you have now, then shrink what is exposed.

Phase 1: Secure what you have

Step 1: Build an edge device inventory

1. List every device and service reachable from the internet: VPN concentrators, SSL VPN portals, firewalls, routers, load balancers, remote-desktop gateways, file-transfer appliances and wireless controllers.
2. Confirm the list from the outside. Scan your own public IP ranges and review your DNS records; forgotten test appliances and old branch-office gateways turn up this way.
3. Record vendor, model, firmware version, who manages it and the vendor's end-of-support date.

Step 2: Retire or isolate anything past end of support

The Cyber Centre advises tracking support timelines and replacing devices before end of life, because flaws found afterwards will never be fixed. CISA's directive defines end of support as no longer receiving timely, supported updates from the manufacturer, including CVE patches and hotfixes. If a device cannot be removed right away, put compensating controls around it and set a firm replacement date.

Step 3: Patch fast and check for compromise

1. Subscribe to vendor advisories and the Cyber Centre's alerts. Edge products appear frequently in CISA's Known Exploited Vulnerabilities catalogue.
2. Test patches on a standby device where you can, then install them as quickly as possible.
3. Run a vulnerability scanner regularly against internet-facing devices.
4. When a vendor discloses an exploited flaw, apply its integrity-check or hunting instructions as well as the patch. Several recent campaigns planted persistence that survived upgrades.

Step 4: Harden access to the device itself

1. Never expose management interfaces to the internet. Manage devices from a separate out-of-band network or a dedicated, hardened administrative workstation.
2. Require strong, phishing-resistant MFA for all administrative access.
3. Use centralized authentication with role-based access, and keep edge device administration separate from your everyday corporate identity store so one compromised account does not unlock both.
4. Follow the vendor's hardening guide, turn off features you do not use, and require two reviewers for security configuration changes.

Step 5: Harden VPN user access

1. Require MFA for every VPN user. Prefer phishing-resistant methods such as FIDO2 keys or certificates over SMS codes or push approvals.
2. Restrict which users and groups can connect, and what each can reach once connected. A flat network behind the VPN turns one stolen password into full access.
3. Remove local accounts on the appliance that bypass your identity provider.

Step 6: Log off the device

The Cyber Centre recommends sending detailed logs to a central location off the device, and alerting on successful administrator logons, configuration changes and hardware changes. Logs kept only on a compromised appliance can be wiped. Also alert on VPN logins from unusual countries, impossible travel and repeated failures across many accounts, which points to password spraying.

Phase 2: Shrink the attack surface

The Cyber Centre's guidance says boundary devices alone are not adequate and recommends moving policy enforcement closer to the resources being protected, assessing whether a zero trust architecture is feasible. In practice, the goal is to stop publishing a login portal to the whole internet.

Step 7: Decide what actually needs network-level access

1. List the applications people reach through the VPN today.
2. Many will already be SaaS (email, file sharing, HR, CRM) and need no VPN at all once protected by your identity provider and conditional access rules.
3. For internal web apps, consider an identity-aware application proxy or a zero trust network access (ZTNA) service, which connects users to specific applications after checking identity and device health, without placing them on the network.
4. Keep a small, tightly controlled path for the remaining cases, such as administrators and legacy thick-client applications.

Step 8: Migrate in stages and decommission

1. Pilot with one team and a few applications, then move groups in waves.
2. Measure VPN usage as you go. When it drops to the remaining exceptions, reduce the portal's exposure, for example by limiting it to known IP ranges.
3. When the old gateway is no longer needed, remove its public DNS records and firewall rules, and wipe and dispose of it properly.

Questions to ask before choosing a replacement

• Does the service integrate with our identity provider and enforce phishing-resistant MFA and device checks on every session?
• Does it expose any portal or listener to the internet on our side, or do connectors make outbound connections only?
• Which logs does it produce, how long are they kept, and can we export them to our SIEM?
• Where is the service hosted and where are logs stored? This matters for privacy impact assessments under Quebec's Law 25 and for client contracts.
• How does the vendor disclose and patch its own vulnerabilities?

What to do this week

• Check every edge device's firmware against the vendor's latest advisory and the KEV catalogue.
• Confirm no management interface answers from the internet.
• Confirm logs from each device reach your central log store.
• Put end-of-support dates in your budget plan for the next 12 months.

Sources

• Canadian Centre for Cyber Security: Security considerations for edge devices (ITSM.80.101)
• Canadian Centre for Cyber Security: Five Eyes publish series to sound alarm on cyber security threats to edge devices
• CISA: BOD 26-02, Mitigating Risk From End-of-Support Edge Devices
• ASD's ACSC: Mitigation strategies for edge devices, practitioner guidance
• CISA: Known Exploited Vulnerabilities Catalog