When to replace that aging firewall

A firewall does not become unsafe because it celebrated a particular birthday. It becomes a replacement problem when you cannot patch it, cannot run the controls the business depends on, cannot recover it predictably, or cannot carry real traffic with those controls enabled.

Age is a clue. Supportability and measured behavior are the decision.

End of security support is the hard line

Find the exact model, hardware revision, operating-system branch, support contract, and vendor lifecycle dates. “The dashboard still opens” is not evidence of support.

If the vendor no longer publishes security fixes for the device or the firmware branch it can run, schedule replacement. CISA’s internet exposure reduction guidance tells operators to replace software and devices that no longer receive security support. Its network infrastructure hardening guidance likewise recommends monitoring end-of-life announcements, using vendor-recommended software, and applying patches in a tested change process.

This matters more at the perimeter. A firewall terminates internet traffic, remote access, and often site-to-site trust. Compensating controls can buy planning time, but they do not create future firmware for abandoned hardware.

Replace when current firmware no longer fits

A supported model can still be the wrong model. Watch for these operational signals:

Security features overload it. Measure CPU, memory, session usage, latency, and throughput with the controls you actually intend to run: VPN, intrusion prevention, malware inspection, logging, and filtering. Do not size from the vendor’s plain-firewall headline while disabling everything useful to hit it.

The required crypto or identity integration is missing. A business may need supported VPN protocols, modern authentication, MFA integration, certificate management, or current logging formats. If the appliance cannot meet the requirement on a supported release, configuration cleverness is not a roadmap.

Capacity has no safe headroom. Growth in users, cloud traffic, encrypted sessions, site tunnels, or internet speed can turn every patch window into a performance incident. Base the decision on trend data and peak business periods, not one speed test after hours.

Reliability is degrading. Unexpected reboots, failing storage, damaged ports, noisy power supplies, and unavailable replacement units make recovery uncertain. A cold spare with an unknown configuration is not reassuring.

The architecture has outgrown it. New segmentation, dual-WAN failover, additional sites, or separate management networks may require more interfaces, routing capability, or policy scale than the current platform handles cleanly.

Do not use replacement to hide a configuration problem

Buying a faster box will not fix an any-any rule, shared administrator account, undocumented vendor VPN, or expired certificate process. Review the existing environment before choosing hardware:

• Internet circuits, public IPs, and ISP handoffs
• VLANs, subnets, DHCP scopes, and routed networks
• NAT and published inbound services
• Site-to-site and remote-access VPNs
• Address objects, groups, schedules, and policy rules
• DNS, NTP, directory, RADIUS, and identity dependencies
• Logging, alerting, monitoring, and configuration backups
• Licensing or subscriptions required for security functions

Use a one-page network diagram to show paths and dependencies. Then review rules for owner, purpose, source, destination, service, and expiration. A migration is a good time to remove proven dead policy, but do not silently combine cleanup and cutover into one unreviewable change.

Size the replacement from evidence

Start with observed peak throughput and session counts. Add expected growth, VPN use, inspection overhead, interface requirements, and failure mode. If high availability matters, price the pair, support, optics, licenses, rack power, and spare connectivity—not one appliance in isolation.

Ask vendors for performance figures with the same features enabled that you will deploy. Confirm:

• Published end-of-sale and support policy
• Firmware support and update process
• Configuration export and restore options
• Log export and API support
• MFA and role-based administration
• Dual power, high availability, and failover behavior where required
• Replacement-unit availability and support response

Subscriptions deserve scrutiny. Understand which functions continue when a license expires and which signatures, cloud lookups, updates, or management features stop. Put renewal ownership and dates in documentation before the appliance reaches production.

Build a cutover you can reverse

Export and securely store the current configuration, but do not assume an old backup is a clean design specification. Create a reviewed target configuration and map old policy to new policy.

A practical cutover plan includes:

1. Baseline: capture current routes, external addresses, VPN status, key application tests, and monitoring state.
2. Stage: update the new appliance, configure administration securely, load policy, and validate offline where possible.
3. Change record: document every cable move, ISP dependency, responsible operator, test, and rollback trigger using a format like our one-page firewall change record.
4. Recovery access: keep local console access and known-good configuration copies available. Do not make cloud reachability the only way to repair a failed internet cutover.
5. Validation: test DNS, web access, inbound services, business applications, site tunnels, remote access, voice, guest isolation, logging, and alerts.
6. Rollback: define how long you will troubleshoot before restoring the old path, and preserve the cables, addressing information, and configuration required to do it.

After the cutover, monitor denies and application failures, back up the final configuration, and remove the old device’s credentials and management access. Dispose of or retain it according to your asset and data-handling policy; do not put an unpatched former perimeter device on a shelf as an emergency plan.

Patch urgency still applies before replacement

Do not defer available fixes because a refresh is planned next quarter. Recent advisories such as Ubiquiti Bulletin 067 show why supported network platforms need both inventory and prompt patch verification. Replace unsupported gear; patch supported gear; document both.

Bottom line: replace a firewall when security support ends, measured load exceeds safe capability, required controls are unavailable, or recovery becomes unreliable. Inventory and clean the policy before migration, size with real features enabled, and rehearse rollback. The best refresh is boring because every dependency was written down before the cables moved.