A server that has been "retired" is often still very much alive. It may be powered on in a corner of a hall, still connected to the network, running an operating system nobody has patched in two years, with old credentials, old data and an IP address that firewall rules still trust. Security agencies have publicly described cases where attackers found exactly such a forgotten machine, took control of it and used it as a foothold to move deeper into the network. Even when the hardware is switched off and removed, its drives may carry data that should not leave the building. Decommissioning is the part of the asset lifecycle most likely to be rushed, and its mistakes last the longest.
How servers become zombies
The usual story is mundane. A project ends and its servers are no longer needed. Someone stops the application. The servers are marked for removal, but removal waits for a maintenance window, a technician, a disposal contract. Months pass. The servers stay powered because nobody is sure what else might depend on them. Monitoring was switched off with the application, so nobody notices when they stop receiving updates.
AI estates add their own variations. Older GPU servers are pushed out of production clusters by newer generations but kept "for experiments". Proof-of-concept clusters stay up after the pilot ends. Servers removed from a cluster for repair never quite return to service and never quite leave.
The risks
A powered-on, unpatched server on the production network is the obvious security risk. Its software accumulates known vulnerabilities, its accounts may include former staff, and other systems may still trust it.
Residual data is the second risk. Drives in retired servers can hold training data, customer data, model weights, credentials and logs. Drives that leave the building for resale, recycling or warranty return carry that data with them unless it is properly sanitised.
Stale records cause the third set of problems. IP addresses, DNS names, firewall rules, certificates, software licences and support contracts tied to the old server stay active. They cost money, confuse incident response and can be abused.
Wasted power and space follow. A zombie GPU server can draw several kilowatts while doing nothing, and it occupies rack positions and power capacity that new equipment needs.
A decommissioning checklist
A complete decommissioning touches every system that knew about the server.
| Step | What to do |
|---|---|
| Confirm dependencies | Check network flows, service records and owners for anything still using the server |
| Stop workloads and remove from service | Drain from schedulers and load balancers, stop applications |
| Remove access | Disable accounts and keys, revoke certificates, remove from directory services |
| Clean network records | Release IP addresses, remove DNS entries and firewall rules, disconnect switch ports |
| Sanitise storage | Erase or destroy drives according to the data classification |
| Reset management controllers | Clear BMC credentials and configuration, remove from management network |
| Update the asset record | Mark as decommissioned with date, method of sanitisation and person responsible |
| Update licences and contracts | End software licences, support and maintenance tied to the server |
| Remove from monitoring | After all the above, so alerts during the process are still seen |
| Physical removal and disposal | Remove from rack, update power and space records, use a certified disposal route |
Sanitising drives properly
NIST Special Publication 800-88 is the reference most organisations use for media sanitisation. It describes three levels. Clear uses standard commands to overwrite data, which protects against simple recovery. Purge uses techniques such as cryptographic erase or the drive's built-in sanitize command, which protect against laboratory recovery. Destroy physically shreds, disintegrates or incinerates the media.
For modern NVMe SSDs, the drive's sanitize or cryptographic erase command is usually the practical purge method, because overwriting does not reliably reach every flash cell. Drives with self-encrypting firmware can be purged quickly by destroying the encryption key. Whatever the method, the result should be verified and recorded per drive serial number, so that an auditor can trace every drive that left the site.
Finding the zombies you already have
Most estates already contain some forgotten servers. Three comparisons find them.
Compare power with purpose. Servers that draw steady power but show no meaningful CPU, GPU or network activity for weeks are candidates.
Compare discovery with the record. Devices that answer on the network or the management network but are not in the asset record, or are recorded as decommissioned, need investigation at once.
Compare the record with discovery. Devices in the record that cannot be reached may have been removed without updating it, or may be powered on but disconnected from monitoring.
A worked example: an operator compares PDU outlet power with server activity and finds 14 GPU servers drawing an average of 2.5 kW each with near-zero GPU utilisation for 60 days. Twelve belong to finished pilots and can be decommissioned. Two are running an unpatched operating system and are still reachable from the corporate network. The cleanup frees 35 kW of power, two racks of space and two security exposures.
Make the record the gatekeeper
The most reliable control is a rule: a server is only decommissioned when the asset record says so, with each checklist step completed and signed. Power, network and disposal teams act on the record, and the record shows what remains open.
CloudSino iDCOS keeps servers and their components in a CMDB with rack positions and change records, and DCOS records component replacements, racking and unracking from the hardware itself. Device-level power monitoring shows which servers still draw power, which helps find machines that should already be retired. Ask us to look for them in your own estate.
Frequently asked questions
What is a zombie server?
A zombie server has been retired on paper but stays powered on and often still networked, running an unpatched operating system with old accounts, data and trusted IP addresses. It wastes power and rack space and can give attackers a foothold. Look for servers that draw steady power but show almost no CPU, GPU or network activity for weeks.
How should SSDs be wiped before server disposal?
Follow NIST SP 800-88, which defines three levels: clear, purge and destroy. For NVMe SSDs, the drive's built-in sanitize or cryptographic erase command is the usual purge method, since overwriting may not reach every flash cell. Self-encrypting drives can be purged by destroying the key. Verify the result and record it against each drive serial number.
What steps belong in a server decommissioning checklist?
Confirm nothing still depends on the server, drain workloads, and remove accounts, keys and certificates. Release IP addresses and DNS entries, remove firewall rules and switch ports, sanitize the drives and reset the BMC. Update the asset record, licenses and support contracts, then remove monitoring last so problems during the process stay visible. Finish with certified physical disposal.