# Retiring Network Equipment: A Field Guide to Switches, Routers, Firewalls & Wireless

Source: https://promo.ccrcyber.com/guides/network-equipment-decommissioning-field-guide
Author: Brian Boynton
Published: November 9, 2026
Publisher: CyberCrunch (https://ccrcyber.com)

> How to retire switches, routers, firewalls and Wi-Fi gear: what they store, NIST 800-88 Rev. 2, vendor secure-erase commands, licensing, and the record to keep.

Section 01

## What a retired network device still knows

A switch or firewall rarely holds a spreadsheet or a patient record. It holds something more useful to an attacker: the credentials, keys, and map of the network it served.

Juniper’s own documentation lists what its zeroize command removes: “all plain-text passwords, secrets, and private keys for SSH, local encryption, local authentication, IPsec, RADIUS, TACACS+, and SNMP.” That list is a fair inventory of what any managed network device carries in its configuration, alongside addressing, VLAN and routing design, VPN endpoints, and user and identity mappings on firewalls. The passwords are often stored as hashes of uneven strength: CISA, NSA, the FBI and partner agencies advised in December 2024 to “avoid use of deprecated hashing or password types when storing passwords, such as Type-5 or Type-7,” which is a reminder that a configuration file from an older device can be cracked offline.

Beyond the configuration, devices keep logs and sometimes packet captures (Cisco documents exporting Catalyst 9000 captures to on-board flash or a USB drive), and many carry real storage: SSDs, log disks, USB and SD slots, and hardware security modules.

| Device class | What it holds | Where it lives |
| --- | --- | --- |
| Managed switches | Admin and local-user password hashes, SNMP communities, RADIUS and TACACS+ secrets, 802.1X settings, VLAN and port design, logs | Flash and NVRAM; Cisco Catalyst 9000 also supports SATA, SSD, and USB storage |
| Routers and SD-WAN edges | VPN pre-shared keys, certificates and private keys, routing and topology, a device certificate the SD-WAN manager trusts | Bootflash and NVRAM, plus USB or SSD on many models |
| Firewalls, NGFWs, VPN concentrators | Security policy, VPN keys and certificates, identity mappings, traffic and threat logs | Palo Alto hardware has a system disk and a log disk; Cisco Firepower 1000 has one SSD and the 2100 and Secure Firewall 3100 have two; some FortiGate models have a hard disk |
| Wireless controllers and access points | SSID keys, RADIUS secrets, licenses, wireless-management and internal databases | Controller flash; cloud-managed APs also pull their configuration from the vendor dashboard |
| Load balancers and ADCs | Configuration, certificates and private keys, logs | F5 lists the HDD or SSD, the AOM flash chip, and the FIPS card, which holds the FIPS security domain and private keys |
| Out-of-band and cellular routers | Generated keys and certificates, carrier APNs, logs, cloud registration | Flash, a SIM card, and a registration that Digi says survives a factory reset |

Bottom line

Treat a retired network device as a credential store with a storage device attached. The risk is not that someone reads your files; it is that someone reads your network.

Section 02

## What NIST SP 800-88 Rev. 2 expects

NIST SP 800-88 is the sanitization standard most frameworks point to, and its 2025 revision changed how it treats network devices.

NIST published [SP 800-88 Rev. 2](https://promo.ccrcyber.com/guides/nist-sp-800-88-rev-2-field-guide) on September 26, 2025, and withdrew Rev. 1 “in its entirety.” Rev. 1 had a one-line rule for routers and switches in Table A-2: “Perform a full manufacturer’s reset to reset the router or switch back to its factory default settings,” with a note that removable media “must be removed and sanitized using media-specific techniques.” Rev. 2 removed the media-specific appendices “to improve the document’s longevity” and points instead to [IEEE 2883](https://promo.ccrcyber.com/guides/ieee-2883-2022-field-guide), NSA specifications, or an organizationally approved standard. No replacement table for network gear was published, and NIST’s July 2026 FAQ confirms that Rev. 2 does not prescribe techniques per media type.

Four Rev. 2 rules decide how you treat network equipment:

- **A manufacturer reset is Clear, at best.** Rev. 2 says that when rewriting isn’t supported, manufacturer resets “may be the only clear sanitization technique options” and still meet Clear “as long as the device interface available to the user does not facilitate retrieval of the original data.” Clear protects against simple recovery, not a laboratory.
- **Purge is preferred.** “When possible, the purge sanitization method should be used instead of the clear sanitization method.” For gear leaving your control with sensitive configurations, that means a verified secure erase of the device’s storage, or destroying the storage.
- **Trust, then verify the vendor’s command.** Rev. 2 says dedicated sanitize commands “require trust and assurance from the ISM vendor,” and that users should verify them because “the command name might imply a certain capability but not actually meet minimum requirements.” Multi-pass overwriting is no longer needed for Clear.
- **Ask for a Statement of Volatility.** Rev. 2 suggests asking vendors for a statement listing every volatile and non-volatile memory component, the data each holds, and how to sanitize it. For firewalls and controllers with several storage devices, it is the fastest way to find them all.

Bottom line

“We factory reset it” is a Clear claim, not a Purge claim. For network gear leaving your control, use the vendor’s secure erase where it exists, keep its output, and destroy any storage you can’t erase and verify.

Section 03

## Before you power it down

The most expensive mistakes in network decommissioning happen before the erase: a license left attached, a device still claimed in a cloud dashboard, or a shared secret nobody rotated.

1. **Back up the configuration and images.** Cisco’s Nexus guidance is to “back up software images, configurations, and personal data” before a secure erase, and HPE Aruba gives the same advice. Store the backup as carefully as the device: it holds the same secrets.
2. **Return the licenses.** Cisco is explicit: “before you perform a factory reset, remove the authorization code and return the license to your license pool in CSSM.” On Catalyst SD-WAN edges, Cisco also lists releasing the HSEC license before the reset.
3. **Unclaim it from every management plane.** For SD-WAN, Cisco lists invalidating the device certificate in SD-WAN Manager and sending the change to the controllers. For Cisco Meraki, remove the device from its network and then from the organization; Meraki notes that “if a device is still in a network after being factory reset, it will re-download its previous configuration,” and that a second-hand buyer can’t claim a device still tied to your account. FortiCloud’s “Decommission This Unit” removes a unit from its cloud services, and Digi says a reset router “will still be registered in Digi Remote Manager” until you remove it.
4. **Rotate what the device knew.** Our recommendation: change any VPN pre-shared key, RADIUS or TACACS+ shared secret, SNMP community, and API token the device held, and revoke its certificates at your certificate authority. Erasing the device doesn’t un-share a secret that also lives on its peers.
5. **Delete keys on hardware security modules.** On F5 platforms with a FIPS card, delete the key and certificate pairs and initialize the module; F5 says `fips-util -f init` “deletes all keys and makes any previously exported keys unusable.”
6. **Close the records.** Remove the device from monitoring, IPAM and DNS, and mark it retired in the asset register by serial number, so the certificate you get back has something to reconcile against.

Bottom line

Do the paperwork and the unclaiming while the device still boots. Once it is erased and boxed, a stuck license or a cloud claim becomes someone else’s support ticket and your resale loss.

Section 04

## Vendor secure-erase commands, and what they miss

Most enterprise platforms now ship a secure-erase or zeroize command that goes beyond a configuration reset. The commands differ in scope, and several have gaps worth knowing before you rely on them.

| Platform | Command | What it covers | Check and caveats |
| --- | --- | --- | --- |
| Cisco IOS XE (Catalyst 9000, ISR, ASR, Catalyst 8000) | `factory-reset all secure` or `factory-reset all secure 3-pass` | NVRAM, startup and running configuration, logs, licenses, user PKI keys and certificates, and user data on removable SATA, SSD, and USB storage (added to the Catalyst 9000 scope in 16.12.1) | Keeps the SUDI certificate. Run it from the console on a standalone device; `show platform software factory-reset secure log` prints a data sanitization report |
| Cisco NX-OS (Nexus 9000, 10.2(2)F and later) | `factory-reset` (or `factory-reset module <mod>` on a modular chassis) | All persistent storage on the module, including configuration, logs, flash, and SSDs | Cisco: “Secure erase feature does not erase content in external storage” |
| Cisco ASA on Firepower 1000, 2100 and Secure Firewall 3100 (FXOS) | `erase secure all` | All data on the SSDs | Cisco: perform a secure erase when decommissioning. `erase configuration` only restores defaults |
| Juniper Junos OS | `request system zeroize media` | With `media`, every attached storage device, including disks, flash drives, and removable USB | Without `media` it only unlinks files. The `media` option is unavailable on non-QFX platforms running Junos 17.2 or later with upgraded FreeBSD, and on SRX5000 firewalls |
| Juniper Junos OS Evolved | `request system zeroize` | Disks sanitized at NIST 800-88 Clear or Purge levels by disk type (ATA, SATA, NVMe) | eMMC and other disks fall back to unlinking files; the console log shows the level used |
| Palo Alto Networks PAN-OS (hardware) | Enhanced Factory Reset (USB boot; PAN-OS 12.2.2 and 12.1.11 or later) | Wipes the system disk and formats the log disk | Not for VM-Series. `request system private-data-reset` “will not erase the system disks”; Palo Alto says data can still be recovered at bit level |
| Fortinet FortiOS | `execute factoryreset`, then `execute erase-disk <disk>` | Configuration, then a low-level format and random overwrite of each disk on models with one | `execute factoryreset2` keeps some settings and is not a decommissioning command; Fortinet’s full sanitize procedure also formats the boot device and reloads firmware |
| HPE Aruba | AOS-CX `erase all zeroize`; AOS 8 controllers `wipe out flash`; Instant AP `write erase all` | AOS-CX overwrites the entire flash with zeroes; `wipe out flash` erases configuration, logs, and license keys | Unavailable on AOS-CX in enhanced secure mode; back up first |
| Cisco Meraki | Reset button, then remove from the network and the organization | Local configuration | The configuration and history stay in your dashboard organization, and MV camera video persists through a reset until the camera is removed from its network |
| F5 BIG-IP, VIPRION, rSeries | F5 Disk Erase Utility (BIG-IP 11.6 and later, serial console) | A single-pass zero write of the disk | The FIPS card needs `fips-util -f init` separately |

Two cautions apply across the table. First, vendor documentation lags the standard: Cisco’s current Catalyst 9300 guide still says its secure reset follows NIST SP 800-88 Rev. 1, which NIST has withdrawn. Second, Rev. 2 asks you to verify a command rather than trust its name. Prefer commands that print a completion log, keep that output with the device record, and confirm the command and its options are supported on the exact model and release in front of you before scheduling a fleet.

Bottom line

The right command is the vendor’s secure erase, run on the right release, with its log kept. Where a platform only offers a configuration reset, plan to remove and destroy the storage instead.

Section 05

## The storage that gets missed

The configuration is the obvious target. The storage around it is where decommissioning programs leave data behind.

- **Removable and external media.** USB sticks and SD cards in console ports and expansion slots, and external storage that a module-level erase doesn’t touch. Rev. 1’s note still describes good practice: remove the media and sanitize it with media-specific techniques.
- **Log disks.** Firewalls and security appliances keep months of traffic and threat logs on a separate disk. On Palo Alto hardware, a configuration reset alone leaves both disks recoverable.
- **Hardware security modules.** FIPS cards on load balancers hold the private keys behind your public services.
- **SIM cards.** Cellular failover and out-of-band routers carry a SIM tied to your carrier account; pull it and close the line.
- **Copies elsewhere.** Configuration backups on TFTP servers, engineers’ laptops, and cloud dashboards outlive the device. Retire them on the same schedule.

Internal SSDs in firewalls, controllers, and application delivery controllers are flash media, so the [SSD, SED and NVMe field guide](https://promo.ccrcyber.com/guides/ssd-sed-nvme-sanitization-field-guide) applies to them once they are out of the chassis.

Bottom line

Before an erase, open the chassis inventory or the vendor’s Statement of Volatility and list every storage device by serial. Anything the erase doesn’t cover gets pulled and handled on its own.

Section 06

## Decision table: device and condition to method

Match the device and its condition to a method. The final call depends on the security category of the data and whether the equipment leaves your control, which is the Rev. 2 framework.

| Device and condition | Method | Fallback |
| --- | --- | --- |
| Working device with a documented secure erase, going to resale | Vendor secure erase with its completion log; removable media pulled and sanitized separately | Remove and destroy the storage; the chassis can still be recycled |
| Working device with only a configuration reset | Manufacturer reset (Clear) for internal reuse or low-sensitivity configurations | For equipment leaving your control with sensitive configurations, destroy the flash or the board |
| Firewall or ADC with internal SSD or HDD | Vendor disk erase, or sanitize the removed drive by its media type | Destroy the drive |
| Device that won’t boot | No logical method is possible | Destroy the storage |
| USB, SD, or SIM | Remove; sanitize or destroy separately | Destroy |
| HSM or FIPS card | Zeroize keys per the vendor procedure | Destroy the card if it leaves your control |

The [Method Picker](https://promo.ccrcyber.com/tools/method-picker) gives the NIST method for each media type and destination, and the [Does It Store Data?](https://promo.ccrcyber.com/tools/does-it-store-data) lookup covers routers, switches, firewalls, access points, and dozens of other network and office devices model by model.

Section 07

## Resale: the hardware moves, the license doesn’t

Used network equipment has a real secondary market, but the major vendors are clear that software rights stay with the original buyer.

- **Cisco.** Cisco software “is not transferable unless specifically allowed under the Cisco Software License Transfer and Re-Use Policy.” That policy allows transfers in listed scenarios (affiliates, mergers and divestitures, lease buyouts, and others) or with Cisco’s consent and a transfer fee, and says Cisco may require the buyer to pay inspection or reinstatement fees. Equipment bought outside authorized channels “cannot be placed under a service contract without being reinspected and possibly relicensed.”
- **Juniper.** “Juniper Networks software is only licensed to the original purchaser and the license is non-transferable or assignable without written permission from Juniper.” Gray-market units need inspection and re-registration, and units past end of life or end of support are not reinstated.
- **Palo Alto Networks.** For second-hand buyers, “any licenses or subscriptions that come with the device are not transferrable to you and are considered expired,” and devices that are end-of-sale or decommissioned can’t be re-certified.
- **Cisco Meraki.** “Cloud Controller licenses are non-transferable,” and only authorized Meraki vendors can resell Meraki devices.

For remarketing, that means the value is in the hardware, and it depends on two things you control: whether the unit was unclaimed and its licenses returned before it left, and where it sits in the vendor’s lifecycle. Cisco’s end-of-life policy, for example, provides five years of replacement parts from the end-of-sale date. CyberCrunch’s [Value-Share program](https://promo.ccrcyber.com/the-value-share-program) remarkets eligible equipment after sanitization and shares the proceeds.

Bottom line

Sell the hardware, not the license. Unclaim and return licenses before the device leaves, and expect the next owner to license it fresh.

Section 08

## The record to keep per device

An erase you can’t show is an erase an auditor won’t accept.

NIST SP 800-88 Rev. 2 says a certificate of sanitization should record at least the manufacturer, model, serial number, sanitization method (Clear, Purge, or Destroy), technique, tool and version, and verification method; its sample form also records the final disposition. For network gear, attach the vendor’s output: the Cisco data sanitization report from `show platform software factory-reset secure log`, the Junos OS Evolved console lines showing the sanitization level, or the Palo Alto Enhanced Factory Reset log. Record every pulled SSD, USB stick, and SIM as its own line, with the chassis serial it came from.

The [Certificate Checker](https://promo.ccrcyber.com/tools/certificate-checker) grades a vendor’s certificate against the Rev. 2 fields, and the [Asset Disposition Tracker](https://promo.ccrcyber.com/vault/request?doc=tracker) template keeps retired serials and their certificates in one place.

Bottom line

One line per serial, with the method, the tool, the verification, and the log attached. If an assessor picks one switch from your inventory, you should be able to produce its record in a minute.

Section 09

## Recycling, batteries, and export

Once the data is handled, network equipment follows the electronics-recycling path, with a few rules that catch businesses out.

- **Business equipment is usually outside state take-back programs.** Pennsylvania’s Covered Device Recycling Act covers computers and televisions “marketed and intended for use by a consumer” and excludes servers and equipment intended for commercial, industrial, governmental, or medical settings. PA DEP says businesses with 50 or more employees must make their own recycling arrangements, and that broken devices may be hazardous waste. The [state compliance patchwork](https://promo.ccrcyber.com/articles/state-itad-compliance-patchwork) brief covers other states.
- **Batteries are their own stream.** EPA says most lithium batteries are likely hazardous waste when discarded and recommends businesses manage them under the federal universal waste rules (40 CFR Part 273). That includes UPS battery packs in network closets and the coin cells on boards. The [Battery and UPS Disposition Field Guide](https://promo.ccrcyber.com/guides/battery-ups-disposition-field-guide) covers storage and shipping.
- **Exports need consent.** Since January 1, 2025, EPA says international shipments of electronic waste covered by the Basel amendments are allowed only with the prior written consent of the importing country, so ask any recycler where your equipment goes.

Section 10

## How CyberCrunch retires network equipment

Network closets and data center rows retire in waves, and the work is the same each time: find every storage device, prove the erase, and recover the value that’s left.

CyberCrunch inventories network equipment by serial at pickup, works from your unclaiming and license checklist, and runs the vendor secure erase where it exists and can be verified, or removes and destroys the storage where it can’t. Removable media, SIMs, and HSM cards are handled as separate line items, every unit gets a serialized certificate, and eligible equipment is remarketed through [Value-Share](https://promo.ccrcyber.com/the-value-share-program). The service is described on the [IT asset disposition page](https://ccrcyber.com/services/itad-it-asset-disposition?utm_source=hub&utm_medium=related_link&utm_campaign=network-equipment-decommissioning-field-guide) on ccrcyber.com, and data center projects on the [data center decommissioning page](https://ccrcyber.com/services/data-center-decommissioning?utm_source=hub&utm_medium=related_link&utm_campaign=network-equipment-decommissioning-field-guide); the [data center decommissioning checklist](https://promo.ccrcyber.com/articles/data-center-decommissioning-checklist) covers the rest of the rack.

Retiring a closet, a site, or a data center row? We’ll scope the gear, the erase method for each platform, and what it can be resold for.

[Talk through your network gear](https://ccrcyber.com/contact?utm_source=guides&utm_medium=cta&utm_campaign=network-equipment-decommissioning-field-guide)
[Look up a device](https://promo.ccrcyber.com/tools/does-it-store-data)

R2v3 NAID AAA RIOS PA DEP NIST 800-88 Rev. 2

Section 11

## Frequently asked questions

### Is a factory reset enough to retire a switch or router?

It depends on where the device is going. Under NIST SP 800-88 Rev. 2, a manufacturer reset counts as Clear when the device offers nothing stronger, which can be acceptable for internal reuse. For equipment leaving your control with sensitive configurations, NIST prefers Purge: use the vendor’s secure-erase command, such as Cisco IOS XE `factory-reset all secure` or Junos `request system zeroize media`, keep its log, and destroy any storage it doesn’t cover.

### Do routers and switches have hard drives?

Many have storage beyond their configuration flash. Cisco Catalyst 9000 switches support SATA, SSD, and USB storage; Palo Alto firewalls have a system disk and a log disk; Cisco Firepower appliances have one or two SSDs; some FortiGate models have a hard disk; and F5 load balancers have an HDD or SSD plus a FIPS card. Check the chassis inventory or ask the vendor for a Statement of Volatility.

### Can we resell used Cisco or Juniper equipment with its licenses?

Generally not. Cisco software is not transferable unless its Software License Transfer and Re-Use Policy allows it, and Cisco may require inspection or reinstatement fees. Juniper licenses its software only to the original purchaser, and Palo Alto and Meraki say licenses don’t transfer to second-hand buyers. The hardware can be resold; return the licenses and unclaim the device first, and expect the buyer to relicense it.

### What should we do with the configuration backup?

Keep it only as long as you need it and protect it like the device. A configuration backup holds the same password hashes, shared secrets, and keys, so store it encrypted with restricted access, delete copies on TFTP servers and engineers’ laptops when the project closes, and rotate the secrets it contains if the device is leaving your control.

### What happens to a Meraki device that is factory reset but still in our dashboard?

It comes back. Cisco Meraki notes that a device still in a network after a factory reset will re-download its previous configuration. Remove it from its network and then from your organization before it ships; a buyer can’t claim a device still tied to another account, and Meraki MV camera video persists through a reset until the camera is removed from its network.

### Does NIST SP 800-88 have a specific procedure for network devices?

Not anymore. Rev. 1 told readers to perform a full manufacturer’s reset on routers and switches; Rev. 2 removed the media-specific tables and points to IEEE 2883, NSA specifications, or an organizational standard. It still lists networking devices as storage media, treats a manufacturer reset as Clear, prefers Purge where possible, and asks you to verify vendor commands.

This guide is provided for general informational purposes and summarizes vendor documentation and NIST SP 800-88 Rev. 2 as published on November 9, 2026. Vendor commands, options, and supported platforms change between releases: confirm each command against the documentation for your exact model and software version before running it, and validate method selection against your data’s security category and your organization’s policy. Vendor licensing terms are summarized from each vendor’s published policy and are not legal advice. For the standard itself, see [NIST 800-88, explained](https://promo.ccrcyber.com/articles/nist-800-88-explained).