How to Decommission Firewalls Securely: Cisco, Juniper and Enterprise Firewall Retirement

A firewall is one of the most security-sensitive devices an organisation can retire. It can contain routing information, security policies, network objects, VPN configuration, certificates, private keys, authentication settings, logging destinations and management credentials. Even after it stops forwarding production traffic, those relationships can remain relevant to the security of the wider environment.

Secure firewall retirement therefore has two separate goals: remove the device from service without causing an outage, and remove the device's ability to expose information or participate in trusted relationships after retirement.

Engineering principle: migration, trust revocation, configuration sanitisation and physical disposition are separate stages. A factory reset should not be treated as the whole decommissioning process.

1. Start with the firewall's role, not its rack position

Document what the firewall actually protects and connects. Record interfaces and zones, routing adjacencies, NAT, security policies, VPNs, high-availability relationships, management systems, logging destinations, AAA services, certificates, licences and downstream dependencies.

Identify the business and technical owners for the services traversing it. A firewall with low throughput can still protect a critical management, partner or disaster-recovery path.

2. Build a dependency map before migration

Map inbound and outbound dependencies including static and dynamic routing, VLANs, VRFs or virtual routers, NAT pools, published services, site-to-site VPNs, remote-access VPNs, DNS references, load balancers, cloud tunnels, monitoring and SIEM integrations.

Also identify dependencies that may not appear in the main security policy: NTP, DNS, syslog, SNMP, TACACS+, RADIUS, LDAP, Active Directory, PKI, licensing, update services and orchestration platforms.

3. Preserve the configuration before irreversible work

Take an approved configuration backup before retirement where retention policy permits. Preserve enough evidence to support rollback, audit or future troubleshooting, while storing that configuration securely because it may contain sensitive topology, addresses, objects and secrets.

Do not leave exported configurations in engineer laptops, temporary shares or unsecured project folders after the retention requirement ends.

4. Understand HA pairs and clusters

Firewalls are frequently deployed as active/standby pairs, chassis clusters or other HA designs. Determine the active member, synchronisation state, failover links, monitored interfaces and any shared addressing before touching either appliance.

A device that appears passive can still be essential to resilience. If the migration requires deliberate failover, validate the resulting traffic path and application health before proceeding to the next stage.

5. Validate the replacement firewall first

NCSC decommissioning guidance recommends ensuring replacement assets are working as expected before irreversible actions are performed. For a firewall migration, this means testing the replacement policy, routing, NAT, VPNs, logging and management paths before sanitising the old appliance.

Keep a defined rollback point. Once configuration and keys are erased, returning the old device to service becomes substantially harder.

6. Security policy and object migration

Do not blindly migrate years of accumulated rules. Establish which policies are required by the target design and which are obsolete. Validate address objects, service objects, groups, zones, rule order, application controls and implicit/default behaviour.

Retirement is an opportunity to remove rules that belonged only to systems that have themselves been decommissioned, but those removals should still be authorised and evidenced.

7. NAT can hide critical dependencies

Static NAT, dynamic NAT and port translation can make a service appear to use an address that does not exist on the application host itself. Inventory public and private mappings and confirm that DNS, upstream routing and replacement-firewall configuration align.

After cutover, test externally published services from an appropriate test point rather than assuming a successful internal test proves NAT is correct.

8. Routing must be migrated deliberately

Review static routes, default routes, BGP, OSPF or other routing relationships. Confirm route redistribution, metrics, preferences, filtering and failure behaviour. A replacement firewall can pass policy validation while still advertising or learning the wrong routes.

9. Site-to-site VPNs

Inventory peers, tunnel interfaces, encryption domains, pre-shared keys or certificates, IKE/IPsec settings, routing dependencies and monitoring. Coordinate changes with external organisations where their configuration must also change.

After migration, verify both tunnel establishment and application traffic. An established security association alone does not prove that routes, selectors, NAT exemptions and policies are correct.

10. Remote-access VPNs

Remote-access services can depend on identity providers, MFA, certificates, address pools, split-tunnelling policies, DNS, posture services and client profiles. Plan user communication and rollback if the retirement forms part of a VPN migration.

Remove the retired gateway from published configuration and management systems once the replacement service is validated.

11. Revoke certificates, not just files

The UK NCSC specifically recommends revoking certificates associated with a network device before disposal, including operational, management and maintenance certificates. Other credentials associated with the device should be changed or revoked as appropriate.

This matters because deleting a private key from the appliance does not by itself revoke the trust represented by the certificate elsewhere in the environment.

12. Credentials and trust relationships

Review local administrator accounts, API keys, SNMP communities, RADIUS/TACACS+ shared secrets, LDAP bind credentials, IPsec pre-shared keys, SSH keys and automation credentials. Remove the retired firewall from AAA, monitoring, configuration-management and privileged-access systems.

Where a secret was shared with other systems, determine whether it needs rotation rather than simply deleting it from the retired device.

13. Logging, SIEM and monitoring

Before retirement, preserve logs required by organisational retention policy. After cutover, confirm that the replacement firewall is sending the expected security and operational telemetry to the SIEM or logging platform.

Remove obsolete monitoring objects after final validation so that stale alarms do not hide real operational issues.

14. Licences, subscriptions and cloud management

Enterprise firewalls can be linked to vendor accounts, cloud managers, subscriptions, support contracts or central policy systems. Record the required transfer, deregistration or termination actions. Do not assume wiping the physical appliance removes its cloud-side registration.

15. Why factory reset is not the whole process

NCSC guidance for network-device disposal recommends revoking certificates, changing or revoking other credentials, following secure media sanitisation guidance where relevant, and using factory reset or device wiping as a general precaution. For VPN gateways, it notes that decommissioning will generally involve wiping stored configuration followed by a factory reset.

In other words, the reset is one technical action inside a broader security process. Trust relationships, external credentials, retained data and evidence still need attention.

16. Cisco Secure Firewall and ASA considerations

Cisco's current ASA documentation distinguishes between startup and running configuration removal. It also documents platform-specific differences: for example, restoring factory defaults on Firepower 4100/9300 running ASA erases the configuration, after which ASA must be redeployed from the supervisor.

The exact procedure therefore depends on platform, operating mode and software release. Confirm the supported Cisco procedure for the specific appliance rather than applying a generic command sequence to every ASA or Secure Firewall platform.

17. Juniper SRX zeroisation considerations

Juniper documents request system zeroize as removing configuration information and resetting key values. Current Junos documentation states that it removes user-created files including configuration/log files and secrets or private keys associated with SSH, local authentication, IPsec, RADIUS, TACACS+ and SNMP, then reboots to factory defaults.

Juniper also documents important platform differences. On certain Virtual Chassis or VCF configurations the operation is local to the member on which it is run, while dual Routing Engine behaviour can differ. The optional media capability is not supported identically across all platforms and releases.

That is why a decommissioning runbook should identify the exact SRX model, Junos release, clustering state and storage implementation before zeroisation.

18. Remove an SRX from a chassis cluster correctly

Where an SRX participates in a chassis cluster, treat cluster removal as a controlled engineering action. Juniper's recovery guidance explicitly includes removing the device from the chassis cluster and disabling clustering before a standard zeroize workflow in the documented scenario.

Validate traffic and cluster state before making the retired node irreversible.

19. Identify storage inside the firewall

NCSC notes that routers, switches and connected devices contain electronic storage media and advises sanitising devices that may contain such media. Firewalls may store configuration, logs, crash information, certificates, keys, packages and other data on internal flash, SSDs or removable media.

Inventory removable USB, SD or other storage and ensure it follows the approved sanitisation or destruction process rather than leaving it attached or untracked.

20. Secure erasure versus destruction

If the appliance is suitable for reuse or resale, use the vendor-supported sanitisation process and verify the result. If storage is failed, inaccessible or governed by a destruction requirement, follow the organisation's approved destruction pathway.

For the wider decision, see Secure Data Erasure vs Physical Destruction and HDD, SSD and NVMe Destruction.

21. Suggested firewall retirement sequence

1. Confirm scope, owner and approved change.
2. Inventory interfaces, zones, routes, NAT, policy and VPNs.
3. Identify HA/cluster state and dependencies.
4. Back up required configuration securely.
5. Build and validate the replacement firewall.
6. Migrate traffic under controlled change.
7. Validate applications, routing, NAT, VPN and logging.
8. Maintain rollback until the migration is accepted.
9. Remove the old firewall from routing and production paths.
10. Revoke certificates and address associated credentials.
11. Deregister cloud/licensing/management relationships where required.
12. Identify all data-bearing storage.
13. Perform the supported wipe/zeroize/reset procedure.
14. Verify the sanitisation outcome.
15. Record serial number and final disposition.
16. Update CMDB, diagrams, monitoring and asset records.

22. Firewall retirement risk table

23. Engineer's pre-decommission checklist

• Approved change and owner confirmed
• HA/cluster state documented
• Interfaces and zones mapped
• Routing dependencies documented
• NAT rules inventoried
• Security policies reviewed
• Site-to-site VPNs inventoried
• Remote-access VPN dependencies reviewed
• Certificates and PKI relationships identified
• AAA and management credentials identified
• SIEM/logging requirements confirmed
• Configuration backup secured
• Replacement firewall tested
• Rollback plan approved
• Storage/media identified
• Vendor sanitisation procedure confirmed

24. Post-decommission checklist

• Production traffic validated on replacement
• Old routing adjacencies removed
• Old VPN endpoints removed
• Certificates revoked
• Credentials rotated/revoked where required
• Monitoring and SIEM updated
• Cloud/vendor registration addressed
• Device sanitisation verified
• Removable media reconciled
• CMDB and diagrams updated
• Asset disposition recorded
• Required evidence retained

25. Common firewall decommissioning mistakes

• Erasing the old firewall before the replacement has been fully validated.
• Treating a standby HA member as non-critical.
• Forgetting NAT and external published-service dependencies.
• Testing VPN establishment but not real application traffic.
• Factory-resetting the appliance without revoking certificates.
• Leaving shared secrets valid in AAA or VPN systems.
• Ignoring cloud-management and licensing registrations.
• Assuming all Cisco or Juniper models use identical reset procedures.
• Ignoring removable or embedded storage.
• Failing to update network diagrams, monitoring and asset records.

26. How Compritech approaches firewall retirement

Compritech combines network and security engineering with IT asset disposition. Firewall retirement can therefore be treated as an infrastructure change first: identify dependencies, protect availability, migrate services, address credentials and trust, then sanitise and reconcile the physical asset.

For the wider network workflow, see How to Decommission Cisco and Juniper Infrastructure Safely, Network Decommissioning Checklist for UK Businesses and How to Decommission a Data Centre Rack Safely.

27. Final takeaway

A firewall should not be considered securely decommissioned simply because it has stopped forwarding traffic or has been reset to factory defaults. The complete process covers service migration, dependency removal, certificate revocation, credential management, sanitisation, verification, asset reconciliation and final disposition.

For Cisco, Juniper and other enterprise platforms, always match destructive commands and sanitisation procedures to the exact hardware, software release and deployment architecture.

Authoritative guidance and further reading

• UK NCSC — Acquiring, managing and disposing of network devices
• UK NCSC — Decommissioning assets
• UK NCSC — Secure sanitisation and disposal of storage media
• Juniper Networks — request system zeroize
• Cisco — Secure Firewall ASA factory-default configuration guidance