Modern servers hold data in a dozen places that aren't the drive bay. And the standard everyone cites for wiping them was replaced last year.
A technician pulls twelve drives from a retired server, runs a certified erasure, and files the certificate. The asset is clean. Except the management controller still has the administrator accounts, the SSH keys, the LDAP binding to your directory, the syslog target pointing at your SIEM, and a complete event history of everything that server did. The RAID controller still has array metadata and whatever was sitting in write cache. The TPM still has ownership. The boot module still has a hypervisor install with its configuration intact.
None of that lives on the drives you wiped.
Where Data Actually Hides
Most decommissioning scopes are written around the drive bay because that's where the obvious storage is. The rest of the chassis gets treated as metal. Here's what's actually in it.
The management controller. iDRAC, iLO, XCC, or generic IPMI — every enterprise server has one, and it's a small computer with its own persistent storage that runs whether or not the host is powered on. It typically holds local user accounts and password hashes, API keys and service credentials, directory bindings, SSH host and client keys, TLS certificates, network configuration including static addresses and DNS, alert destinations for SNMP, SMTP, and syslog, virtual media paths, and a rolling event log. A buyer who racks that server and opens the management interface inherits all of it.
RAID and HBA controllers. Array metadata, configuration, and cache. Battery-backed or flash-backed write cache can hold recently written host data. Array metadata alone tells someone how the volume was structured, which matters if any drive from that array escaped destruction.
Boot and utility media. M.2 modules, Dell BOSS cards, internal SD modules, and USB boot devices. These frequently hold a full hypervisor or OS install with its configuration, and they sit outside the main drive bay, so bay-based inventory processes miss them entirely.
NVDIMMs and persistent memory. Non-volatile by design. They survive power loss, which is the point of them.
TPM and platform firmware. TPM ownership and sealed keys, UEFI variables, Secure Boot key enrollment, and BIOS configuration including any stored passwords.
Network interfaces and adapters. NICs, HBAs, and smart adapters with their own firmware and saved configuration.
For AI and GPU systems, add local scratch NVMe that accumulates model artifacts, checkpoints, and training data; GPU vBIOS that may have been reflashed away from the OEM baseline; and platform crash dumps.
One honest clarification, because it gets overstated: GPU high-bandwidth memory is volatile and clears on power-down. The risk in an AI server isn't the HBM. It's the credentials, the logs, and the scratch storage around it.
Why This Got Harder
Three changes compounded.
Servers grew more out-of-band management, so the controller holding privileged access to your environment became standard rather than optional. Storage moved off the backplane into boot modules and M.2 slots that a drive-bay inventory never sees. And AI workloads put large volumes of proprietary data onto local scratch storage that was never intended to be permanent and therefore never made it into anyone's data classification.
The result is that a decommissioning checklist written five years ago is scoped for a machine that no longer exists.
What NIST Changed in Revision 2
If your sanitization policy cites NIST SP 800-88 Revision 1, it cites a withdrawn document. NIST published Revision 2 on September 26, 2025 and withdrew Revision 1 the same day, superseded in its entirety.
NIST describes three significant changes.
The document's focus shifted from hands-on sanitization decisions toward establishing an enterprise media sanitization program as part of disposal or reuse. It is now a governance document rather than a technical manual.
Program-focused guidance improves alignment with cybersecurity standards such as SP 800-53 and ISO/IEC 27040, updates certain methods to match current practice, and addresses trust establishment in a vendor's implementation of clear and purge techniques. That last clause is the one worth reading twice if you outsource disposition: the standard now explicitly concerns itself with whether you can trust your vendor's claim.
And apart from cryptographic erase, all sanitization technique and tool detail has been replaced with recommendations to comply with IEEE 2883, NSA specifications, or an organizationally approved standard. The per-device tables that made Revision 1 useful at a bench are gone. Technique lives in IEEE 2883 now.
Revision 2 also states that degaussing is not an approved destroy technique, directing readers to IEEE 2883 and NSA/CSS Policy Manual 9-12 for detail. If your contracts treat degaussing and destruction as interchangeable, that language needs revisiting.
The Practical Consequence
Three documents in most organizations now reference a standard that no longer exists: the internal data sanitization policy, the ITAD contract or statement of work, and the RFP template used to select vendors.
None of that makes anyone non-compliant overnight. Revision 1's methods didn't become unsafe on September 26. But "sanitized in accordance with NIST SP 800-88 Rev. 1" is now a citation to a withdrawn publication, and that is exactly the kind of detail an auditor notices and a plaintiff's counsel enjoys.
The fix is a find-and-replace plus one real decision: which technique standard you're adopting, since Revision 2 no longer supplies one.
A Defensible Scope
Inventory by component, not by chassis. The unit of sanitization is the data-bearing component. A server is a container for several of them.
Factory reset every management controller. Accounts, keys, certificates, directory bindings, network and alert configuration, virtual media settings, and event logs. Verify by logging in afterward with default credentials and confirming the environment is empty.
Clear controller configuration and cache. RAID and HBA configuration, array metadata, and cache contents.
Release TPM ownership and reset platform firmware. Including Secure Boot key enrollment and any stored BIOS passwords.
Treat boot modules as drives. M.2, BOSS, and internal SD are storage. They belong in the inventory and on the certificate.
Name your technique standard. Revision 2 points to IEEE 2883, NSA specifications, or an organizationally approved standard. Pick one and write it into the policy.
Require evidence per component. Method, tool and version, operator, timestamp, and result, tied to a serial number. A certificate that covers "the server" is not evidence about the controller inside it.
Update the paperwork. Policy, contract, SOW, and RFP template.
The Test
Ask whoever handles your disposition a single question: when a server leaves, what happens to the iDRAC?
If the answer is about drives, the scope is wrong.
Vibrant Technologies has provided secure, documented IT asset disposition since 1998, and is R2v3 certified. Component-level sanitization, serialized evidence, and reporting your security and finance teams can both use. Request a valuation
This article summarizes publicly available standards guidance and is not legal or compliance advice. Confirm requirements specific to your organization with your own advisors.
Sources
- NIST, September 26, 2025 — Announcement of SP 800-88r2 and the three significant revisions compared with Rev. 1. NIST news · CSRC announcement
- NIST SP 800-88r2, Guidelines for Media Sanitization — Chandramouli R, Hibbard EA (2025). Includes the treatment of degaussing and references to IEEE 2883 and NSA/CSS Policy Manual 9-12. Publication PDF
- NIST SP 800-88r1 withdrawal notice — Revision 1 withdrawn September 26, 2025 and superseded in its entirety by Revision 2. Withdrawal notice