Home/Handbook/Beyond the drives
Chapter 04 · 8 min read
The data that survives a drive wipe
Forty servers, 320 drives, every one sanitised and certificated by serial number. The paperwork is immaculate. And every one of those forty machines still has an iDRAC holding your Active Directory bind account, sitting on a pallet in someone else’s warehouse.
This is the failure mode nobody catches, because everything about it looks correct. The drives were the thing with serial numbers, so the drives were the thing that got certificated. The rest of the rack went out as “hardware”.
A modern server is full of small amounts of persistent storage that never appear in a drive inventory. Network kit is worse. Here’s where it hides, roughly in order of how often it gets missed.
04.1The management controller
iDRAC on Dell. iLO on HPE. XCC on Lenovo. IPMI on Supermicro. Whatever it’s called, it is a small independent computer with its own processor, its own network port and its own flash storage — and it keeps running when the server is powered off.
Open one up and you will typically find:
- Local administrator accounts and password hashes
- Active Directory or LDAP settings, often including a bind account
- SNMP community strings
- SMTP server details for alerting
- TLS certificates and their private keys
- Network configuration — addresses, VLANs, DNS
- Licence keys, and a log of who connected and when
Wiping the OS drives does nothing to any of it. A factory reset from the controller takes about two minutes per machine.
The one that actually bites: the AD bind account. It’s a real domain credential, it’s often over-privileged because someone was in a hurry during the build, and it’s frequently still valid years later because nobody remembers it exists. That’s not a disposal problem, it’s a live network credential leaving your building.
04.2Boot modules and internal flash
Dell BOSS cards. HPE NS204i modules. Internal SD cards, USB headers soldered to the board, M.2 slots hidden behind a riser. These usually hold the hypervisor — and an ESXi install carries host configuration, vCenter registration and sometimes cached credentials.
They get missed for a boring reason: they aren’t in the front bays. If your asset register was built by walking the racks and counting caddies, these were never on it in the first place.
04.3RAID controller cache
A battery- or flash-backed write cache exists specifically to hold data through a power loss. That is its entire job. It also stores the array configuration, and on some controllers recently written data can sit there until the controller is properly cleared.
Pulling the drives out and running them through a wiping bench does not touch it. Clearing the foreign configuration and removing the virtual disks is a separate step.
04.4Switches and routers
A switch is a computer with a filesystem. Bootflash and NVRAM hold the running and startup configuration, which typically means:
- Enable and local user passwords, often only reversibly encrypted
- SNMP strings, TACACS and RADIUS shared secrets
- Your complete VLAN and routing topology — effectively a map of the network
- ACLs, which document what you were protecting and from whom
- Historical logs, and on some platforms packet captures
Erasing the startup config is the step most people take, and on its own it often leaves the running config and the bootflash filesystem completely intact.
04.5Firewalls and VPN appliances
The worst case, and the one we’re most careful with. A next-generation firewall holds the full policy set, VPN pre-shared keys, certificates and private keys, the local user database, and admin credentials.
There’s a specific trap here. The console is credential-locked, and in a decommission the admin password often left with the person who configured it. No password means no factory reset.
Worked example — FortiGate 80E
Console was credential-protected, so a normal reset wasn’t available. The boot device was formatted directly from the BIOS configuration menu, which erases the FortiOS firmware and the entire configuration partition together.
Post-wipe the unit reported “No default firmware. You may try backup. Please power cycle. System halted.” — confirming the configuration partition holding credentials, keys and policies was gone. The device intentionally no longer boots; a purchaser loads fresh FortiOS.
04.6Storage array controllers
The disks in a SAN are half the job. The controllers hold host mappings, disk group and volume definitions, admin credentials, SMTP and SNMP settings, and certificates.
On a Dell EMC ME-series, an HPE MSA or a NetApp filer, the array configuration is a separate piece of work from the disks it contains — and should be certificated separately, so you can see both were done. Our ME4024 sample shows exactly that split: one record for the array config, nine more for the fitted drives.
04.7Four questions for your supplier
You don’t need to audit anyone’s process. Ask these and the answers will tell you quickly whether they’ve thought about it:
- Do you reset management controllers, and do you certificate that separately?
- How do you handle boot modules that aren’t in the drive bays?
- What happens to switch and firewall configuration?
- If a device is credential-locked, what then?
Vague answers to any of them mean the equipment goes out of the door with data on it. That might be fine for a batch of empty chassis. It is not fine for the firewall.
The short version: drive erasure is necessary and not sufficient. If a decommission only covers the drive bays, your credentials and network topology leave the building in the same pallet as the hardware.
About the author
Kamil Anwar — Founder, ServerGear. Kamil runs ServerGear, the data centre asset recovery arm of PYCO RENEW LTD. He spends most of his week looking at asset lists, arguing about what a four-year-old server is really worth, and making sure the drives that come with it are dealt with properly.