Tear-A-Wipe: What It Looks Like When a Company Finally Owns Its Most Critical Tool
The Man of Few Words Was Giggling
The first person outside the build to see Tear-A-Wipe working was TechR2’s primary technical contact, someone who had been evaluating and using professional wiping software for years.
He watched the PXE boot server come up on a USB drive. He watched devices on the closed network find it and start wiping themselves. He watched the sneakernet fallback work on a machine that couldn’t network boot: plug in, wipe all drives, auto-shutdown, pull the USB, plug it back into the central server, and watch it ingest everything. He watched the web interface update in real time as attestation data came in from the field. He watched the tool burn a copy of itself onto a fresh USB.
He is, by reputation, a man of few words.
He was giggling like a kid in a candy store.
The Gap Nobody Talked About
TechR2’s core value proposition is verifiable chain of custody. A client hands over end-of-life hardware and receives documented proof that their data is gone, that the process met a defined standard, and that every step from intake to disposition is traceable. That proof is the product.
Before Tear-A-Wipe, the actual wiping step in that chain relied on third-party software. Good software. Expensive software that did the job it was designed to do. But software that wasn’t built around TechR2’s workflows, their inventory system, their asset tagging, or their reporting needs. Getting data out of those tools and into TechR2’s systems required an export step. A manual bridge. A seam right at the most compliance-critical moment in the entire process.
It wasn’t broken. It just didn’t fit. And more to the point: for a company whose entire value is in the chain of custody, depending on an outside vendor for the link that matters most is a structural exposure that only looks acceptable until something goes wrong.
“TechR2 relying on a third-party vendor for such a critical component of their core business just didn’t make a lot of sense,” says Matt Bradford, founder of New Era Systems and the developer behind Tear-A-Wipe.
What the Tool Actually Does
Tear-A-Wipe is a policy-driven, multi-architecture wiping suite. TechR2’s full Cyber Asset Management workflow runs in one connected sequence: receive, track, sanitize, validate, destroy, certify, report. Tear-A-Wipe covers the sanitize-through-certify steps with no manual bridge and no export step required.
The engine supports NVMe using cryptographic purge, SSD using purge or secure erase, and magnetic media using raw overrides. It detects what it’s looking at and applies the right method. It can be flashed to a USB drive and stand itself up as a PXE boot server for a closed network, so devices in a processing bay can boot directly into the wipe environment without any individual setup. Devices that can’t PXE boot get a fallback: a secondary USB that carries the wipe environment to the machine, runs the process, and carries the attestation data back to the central server when it’s done.
The architecture is hub-and-spoke. The hub handles reporting and coordination. The spokes cover endpoints, servers, and anything else in the workflow. Integration with TechR2’s inventory management system means the wipe record connects to the asset record at the PID level, including the specific drives inside a device, not just the device itself. That matters because a laptop has a PID. The NVMe drive inside the laptop has its own serial number, EUI, and controller data. Tear-A-Wipe tracks both and links them.
For devices with RFID tagging, that linkage extends to physical location tracking across the entire workflow: intake, wipe station, destruction. That’s a complete custody log, not just an end-state certificate.
The web interface and terminal UI give operators real-time visibility into the status of every device in the queue. The client lease table shows MAC address, IP, state, progress, and flags at a glance. Red flags are red. Missing wipes are visible immediately.
The Certificate
When a wipe completes, Tear-A-Wipe generates a certificate.
That certificate contains the manufacturer serial number, board and motherboard identifiers, controller type, and dozens of additional data points about both the drive and the system it came from. It records the operator, the timestamp, the result.
Most importantly, it records the policy the wipe was held to.
This is where Tear-A-Wipe is in different territory from existing solutions. The policy editor is fully configurable. If a client requires NIST 800-88 purge for NVMe drives, the policy says so and enforces it. If a client needs to go beyond NIST requirements, the policy reflects that. If a client’s risk profile only requires a lower standard for certain device types, the policy documents that too, and the certificate makes it explicit. The exact standards a wipe was held to are part of the record, not assumed from context.
NIST 800-88 doesn’t have a one-size-fits-all answer. Neither does DoD. Different media types, different sensitivity levels, and different regulatory environments call for different methods. Tear-A-Wipe handles that variability at the policy layer, which means the certificate is always accurate and always specific, not just a checkbox that says “wiped.”
The Tear-A-Wipe certificate pairs with TechR2’s Tear-A-Byte physical destruction certificate for devices that go to shred. TechR2’s inventory hub consolidates the two into a complete chain-of-custody record: here is the wipe, here is the destruction, here is proof they refer to the same physical device. An auditor can verify any link in that chain independently.
The clients who need that level of documentation are concentrated in industries where a single gap carries real consequences. For a healthcare system, it means patient data does not survive a retired device. For a financial institution, customer records and credentials cannot be recovered from decommissioned equipment. For a data center turning over high volumes of hardware, serialized control at scale is the only way to manage exposure. For government and regulated clients, the documentation has to stand up to formal audit and vendor oversight review. In those environments, the certificate is the deliverable.
What It Cost to Build
When the bid for Tear-A-Wipe went in, TechR2 pushed back.
Not because the number was too high. Because they were seriously concerned it was too low. A policy-driven, multi-architecture wiping suite with PXE boot infrastructure, a web UI, a terminal UI, hub-and-spoke reporting, inventory integration, CMDB sync, server-class device support, and a custom compliance policy editor: that’s not a project a single developer completes at that price point. That’s an eight-person team, thousands of hours, and somewhere between half a million and three quarters of a million dollars if a traditional consulting firm is doing the work.
Bradford explained the AI-augmented software development lifecycle and what it makes possible. TechR2 looked at the previous projects he had delivered and noted that those had always seemed to go faster than expected. But those were projects a solo developer could have handled in the old world too, just slower and more expensively. This was different. This was the kind of project that simply doesn’t get done by one person in the traditional model.
That’s the threshold they crossed.
The build came in approximately 50 percent faster and 85 percent cheaper. One developer. The gap between the bid and the alternative wasn’t small.
A compliance-heavy, deterministic system is, it turns out, nearly ideal for AI-assisted development: define the acceptance criteria clearly, let the agent iterate until every box is checked, then bring in human judgment for code review, audit, and the decisions that require knowing what good actually looks like.
“They’re not paying for me to type,” Bradford says. “They’re paying for me to know what good looks like and to hold the line.”
That’s the job. The typing is the least valuable part of it, and it shows in the price.