By Viktor Yoshimura – 6th of October 2026
Colocation has productised almost every service inside the building. Drive destruction is the one it still leaves to a vendor on the loading bay. I think that is a product waiting to be built, and the hard part is not the machine.
A tenant in a multi-tenant data centre has five failed drives that need physical destruction. They sit in a secure cage. The tenant raises a ticket, waits for the vendor, and eventually a truck arrives at the loading bay and the drives leave the building. Destruction happens elsewhere, on someone else’s schedule. You have drives sit locked in a cage for a week waiting for a scheduled shred run, the SLA clock running the whole time, because five drives did not justify calling the truck sooner.
That is a strange gap, because every other function in the building has been turned into a service. Power, cooling, remote hands, cross-connects, all packaged, priced and delivered against a defined SLA. Destruction is the one that is still a separate logistical exercise the tenant has to arrange.
What the hyperscalers actually did
It is tempting to say the hyperscalers solved this by shredding on site, and plenty of people do say it. It is not quite true, and the real version is more useful. The hyperscalers resolved destruction by owning the decision inside their own buildings, and they did not all pick the same answer. Some destroy in-house. Others wipe drives to standard and ship them out with the racks rather than shredding them. Two different models, one shared principle: the outcome is decided and executed inside their control, on their clock, with no third-party visit in the middle.
The multi-tenant tenant is the party that never got that. They cannot build a hyperscaler’s in-house process for a few cages of equipment, so they are left with the one option that still has a vendor and a van in it. The gap is not that colos fail to shred. It is that colos have not given tenants a way to resolve destruction inside the building the way the hyperscalers resolved it inside theirs.
Why the transport leg is the weak point
The case for closing that gap is not mainly about speed, though speed matters when an SLA is running. It is about the custody seam. Between the moment a drive leaves the cage and the moment it is destroyed, it is in a loading bay, on a lift, in a truck, logged by hand across a boundary and held by a third party. Every audit I have sat through treats that window as the weak point, because it is.
The cost of getting that wrong is not hypothetical. Morgan Stanley paid a 35 million dollar SEC settlement after a contractor it hired failed to wipe drives before they were resold, and devices surfaced on the open market with data intact. That is the transport-plus-third-party chain failing in exactly the place this proposal removes. Shorten the chain and you shrink the surface where that failure happens.
Destruction is the one colo function still handled as a logistical exercise rather than a service.
It does not mean buying an industrial shredder
When people picture on-site destruction they picture a full industrial shredder, and for most colos that is the wrong mental model. There are three delivery models, and they fit different volumes.
| Model | What it is | Fits |
|---|---|---|
| Colo-owned shredder | The colo buys, runs and maintains an industrial machine | High, steady volume |
| ITAD-operated on site | An ITAD partner installs and runs equipment in the building | Medium volume, shared risk |
| Compact device plus handoff | Trained staff destroy on a compact device; material is sealed into a tracked container; an ITAD partner collects it for downstream shredding and recovery | Low or irregular volume |
Table 1. Author’s framing. The third model is the one that makes the service reachable for an ordinary colo, because it removes the capital and footprint of an industrial line.
The third model is the interesting one, because it separates the two jobs that do not have to happen in the same place. The destruction event, the thing the tenant needs on demand, happens inside the building. The downstream shredding to final particle size and the material recovery, the things that need scale, stay with the ITAD partner. The tenant stops waiting for a truck to start, and the specialist still does the specialist work.
Verification is the real problem, and it is not solved yet
The machine is the easy part. The hard part is proving, to each tenant’s auditors, that the right drive was destroyed and that the record holds all the way to final processing. A drive can be scanned before destruction and tied to an operator, a timestamp and a job record. But its barcode is often unreadable once it has been through the device, so the downstream processor cannot reconcile the material it receives against each original drive. It documents the final shred by batch or by weight.
A defensible design probably looks like this: an asset-level record at the point of destruction, the resulting material sealed into a uniquely identified container, and the container’s transfer and downstream processing documented against that seal. Whether a batch-level certificate at the end is enough depends entirely on the tenant’s security requirements and the contractual definition of “destroyed.” For some it will be. For a bank or a government tenant it may not, and asset-level reconciliation stays mandatory. That is a question to settle with the customer before the service launches, not one to paper over after.
One more technical line that has to be right: an SSD is not an HDD. A coarse shredder or a punch-and-crush device built for magnetic drives can pass a NAND chip through intact, and an intact chip still holds data. Current practice puts HDD destruction around a 6mm particle and SSD nearer 2mm. A compact device can be a legitimate answer for HDDs and a false sense of security for SSDs, and anyone offering the service has to know the difference.
Why we are not there yet
So why is destruction still a phone call in most colos? Not technology. The equipment exists at every scale, and the hyperscalers have run in-house processes for years. It is that destruction has been treated as a service to procure rather than a service to sell, and the verification design has not been done. The first is a habit. The second is real work, but it is work, not a wall.
My belief is that on-site destruction becomes a standard colo product line within a few years, the way remote hands did, and that the operators who build the verification layer first will use it to win security-conscious tenants, not just to shave a cost. The case against is that the verification problem is hard enough, and the incumbent vendors entrenched enough, that colos decide it is not theirs to own. I do not buy it, but that is the honest other side.
That is my own thinking, and im prepared to convinced im wrong. And if that is the case, let me know why…