HAM for Network Equipment

Why Network Equipment Needs Its Own Treatment

Most HAM guidance is implicitly written about laptops. Asset tags, user assignments, refresh cycles, separation recovery — the model assumes a device with a user, a desk, and a three-year refresh. Network equipment breaks every part of that assumption.

A core switch has no user. It lives in a rack for seven to ten years. Its identity to the network is its management IP and MAC address, not its asset tag. When it is decommissioned, "wipe the drive" is not the right concept; what matters is that its configuration — which often contains credentials and topology details — does not survive the disposal.

Treating network gear with the laptop playbook produces predictable failures: out-of-warranty surprises, configuration leaks at end-of-life, and audit findings about devices that show up on network discovery but never on the HAM register. This guide covers the network-specific adjustments to the model.

Asset Classes and What's in Each

Layer-2 / Layer-3 Network Devices

The core HAM-tracked population:

• Switches — access, distribution, and core. Stackable units share a logical identity but each chassis is a separate physical asset.
• Routers — branch routers, WAN edge, internet gateways.
• Wireless access points — usually managed in fleets through a controller. Each AP is a physical asset; the controller is itself an asset.
• Firewalls and UTM appliances — high-value, security-relevant; tracked individually with extra rigor on configuration backup.
• Load balancers, WAN optimizers — same treatment as firewalls.

Power and Environmental Equipment

Often forgotten in HAM because nobody calls them "IT" until they fail:

• UPS units — rack-mount and standalone. The batteries inside have a separate, shorter useful life than the chassis; some organizations track battery replacements as their own records.
• PDUs (power distribution units) — managed (network-connected, tracked individually) and unmanaged (often treated as fixtures of the rack).
• Environmental sensors — temperature, humidity, leak detectors. Low value individually, but collectively useful in the data center HAM picture.

Out-of-Band and Console Access

• KVM switches — physical and IP-based. Often the only path to recover a misconfigured device.
• Console servers / serial concentrators — out-of-band management spine.
• Jump hosts and management appliances — sometimes physical, sometimes virtual; only the physical ones belong in HAM.

Cabling, Modules, and Optics

Most organizations stop tracking individual cables. SFP+ optics, line cards, and supervisor modules are the borderline cases — high enough value individually to want a record, but components rather than independent devices. Two practical rules:

• Treat optics as consumables below a threshold (typically a few hundred dollars), and as tracked components above it.
• Track line cards and supervisors as child records linked to the chassis they live in. Their lifecycle follows the chassis but their own warranty and replacement history matters.

Identifiers That Actually Identify the Device

The endpoint HAM model leans on serial number plus asset tag. Network equipment needs more.

The bridge from HAM to network monitoring tools, the configuration management database, and the wider IT operations stack runs through these identifiers. The HAM vs CMDB guide covers the integration patterns; for network equipment specifically, the management IP is usually the key the discovery tools use.

Lifecycles That Are Longer Than Laptops

Network equipment refresh cycles are driven less by hardware aging and more by software-support windows, port density, and protocol obsolescence. Useful-life ranges that hold up in most organizations:

The implication for HAM: a switch you bought today is going to outlast multiple refresh cycles of the laptops connected to it. The data quality has to survive that long. Records that depend on tribal knowledge of "the Cisco guy who set this up" are a liability when the network team turns over before the equipment does.

Status States Specific to Network Gear

The standard status state machine in the data model guide mostly works for network equipment, with a couple of additions worth being explicit about:

• Pre-staged. Configured at a staging bench, ready to ship to a remote site. Distinct from "In Storage" because it has a target site assigned.
• In Service. Network equipment doesn't have a single user, so "Deployed" feels off. Many organizations adopt "In Service" with location and (where relevant) the operating team as the assignment.
• Cold Spare. A pre-configured device sitting in a rack, powered off, ready to be cabled in when its production counterpart fails. Tracked as a deployed asset (it's at a specific location and committed) but with a different sub-status.
• Awaiting Sanitization. Decommissioned but still has configuration on it. The interim state before final disposal where extra care is needed (see below).

Decommission: Configuration Wipe Is the Real Sanitization

For laptops and servers, sanitization is about the storage medium. For network equipment, the disk (or flash) is small and the data on it is mostly the device's own software. The sensitive part is the configuration: it typically contains hostnames, IP addresses, VLANs, routing relationships, sometimes shared secrets and pre-shared keys, occasionally embedded credentials, and a topology map of the network's interior.

A network device disposed of with its config intact is a different category of risk than a wiped laptop sold on a resale market. The configuration alone may be enough for an attacker to plan an attack on the network it came from, even though the device itself is not on that network anymore.

The Decommission Checklist

• Backup the configuration. Before anything else, save the running and startup configuration somewhere durable. Disposal is not the moment to discover that nobody has the working config saved.
• Remove from monitoring and management. Delete the device from the network management system, monitoring platform, and the CMDB. Stale CIs in monitoring create false alerts and false confidence.
• Erase the configuration. Most vendors provide a sanitize / zeroize / write-erase command that overwrites the configuration storage. Run it. If the device supports a "secure" or NIST-aligned variant of this command, prefer it.
• Remove or zeroize cryptographic material. Certificates, private keys, RADIUS shared secrets, IKE pre-shared keys, TACACS keys. The sanitize command usually handles these; verify rather than assume.
• Power-cycle and verify. Reboot the device and confirm it comes up to factory defaults. A device that boots back into the old configuration was not actually wiped.
• Physical labels. Remove any labels that identify the device as belonging to your organization, especially network labels with internal names or IP addresses.
• HAM record. Status moves from Awaiting Sanitization to Disposed with a config-wipe attestation, the operator who performed it, and the date. The ITAD guide covers the wider disposal evidence; for network gear this attestation is the equivalent of the data sanitization certificate.

When Configuration Wipe Is Not Enough

For high-sensitivity equipment — firewalls in regulated environments, devices that handled classified or top-secret traffic — physical destruction of the storage medium follows the same logic as for storage devices on regulated endpoints. The threshold is determined by the classification of the data the device handled, not by the device class itself.

Common Mistakes

• Treating stackable switches as one asset. Three stack members are three physical chassis with three serial numbers and three warranties. Stack identity is a logical attribute, not the asset.
• Using "Datacenter" as the location. When something fails at 3am, "Datacenter A, Rack 12, U24" is actionable. "Datacenter A" sends someone hunting through 200 racks.
• Tagging the bottom of rack-mounted equipment. Asset tags on the bottom face are invisible once the device is racked. Tag the front bezel or a side accessible without unracking.
• Letting warranty expire silently. Network gear refresh cycles are long enough that warranty-expiration alerts have to actually exist as a workflow, not as a quarterly mental check.
• Trusting "no auto-discovery" for the inventory. Network equipment is precisely what auto-discovery finds easily; using HAM as the source of truth without ever cross-checking against discovery is how shadow gear stays hidden.
• Forgetting UPS batteries are not the UPS. Tracking the chassis as a single asset with no record of battery replacements means nobody knows when the batteries are due, until the next outage proves they were due last year.
• Skipping configuration backup before decommission. The most common, most painful mistake. Once the config is wiped, recovering it is sometimes impossible. Backup is a precondition for disposal, not a nice-to-have.

Audit Considerations Specific to Network Equipment

The audit methodology in the audit guide applies, with two adjustments:

• Reverse test from network discovery. The most productive audit step for network gear is pulling the list of devices the network management system can reach and reconciling it against HAM. Devices on the network with no HAM record are usually shadow gear or migration artifacts.
• Sample by location, not by class. Network gear concentrates physically — a single rack might hold 15-20 devices. Sampling by location verifies cabling and physical layout simultaneously with the HAM-record check, which a class-based sample misses.

Compliance regimes that scope by data flow — PCI DSS in particular — care intensely about which network devices are in the cardholder data environment. The HAM record's location and class fields, plus a tag for in-scope-or-out, are what auditors review against the network diagram.

Sparing and Rapid Replacement

A failed switch in a closet does not wait for procurement. The HAM model has to support sparing strategies that the laptop world doesn't need:

• Cold spare per site. A pre-configured replacement sitting in the same closet, tracked as Cold Spare, with the configuration backup of the unit it would replace already loaded.
• Centralized hot spare pool. A small set of generic devices at a central site, configured at the moment of failure and shipped overnight.
• Vendor advance replacement. Tracked in HAM as a placeholder "Advance Replacement Pending" record so the failed device's record can move to In Repair without losing track of the obligation.

Sparing strategy lives at the boundary between HAM and network operations; HAM's job is to keep the records honest while the network team executes the strategy.

Next Steps