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.
Who TechR2 Is
TechR2 has been in the asset recycling and data destruction business for over 25 years. The company is purpose-built around one of the more unforgiving niches in IT services: decommissioning hardware for organizations where the data on that hardware carries real regulatory weight. Healthcare systems. Financial institutions. Government agencies. Data centers turning over hardware at volume.
At roughly 50 people, TechR2 is built to move. Large enough to staff and execute against any job a realistic client would bring them. Not so large that decisions have to travel through layers before anything happens. That combination is harder to find in this industry than it sounds. The depth of credentialing they carry is the kind of institutional investment a company makes only when it genuinely believes the compliance work is the product, not window dressing. NAID AAA certification. R2/RIOS. Full chain of custody. Those are not marketing checkboxes for TechR2. They are the commitments of a company that has spent 25 years learning what happens when they are absent.
Twenty-five years in this industry is also long enough to watch what happens when the chain of custody breaks. TechR2 built their operation specifically so it wouldn’t happen in theirs.
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.
For a healthcare system, a verifiable wipe record is the difference between a clean decommission and a reportable breach. For a financial institution, it is the documentation that proves customer credentials and account data did not survive a device retirement. For a data center cycling through high volumes of hardware, serialized control at the drive level is the only way to manage exposure at scale without accepting audit risk. For government clients and vendors operating under formal oversight, the certificate has to stand up to independent review. Not as a claim. As a traceable record that connects a specific wipe event to a specific piece of media with a specific policy applied.
That is the kind of certificate Tear-A-Wipe produces. For a company with TechR2’s 25-year track record serving those exact client profiles, that matters in a specific way. The certificate is generated natively. It lives inside their own system, linked to their own asset records. No export step. No bridge. No third-party dependency at the moment in the process where dependency is least acceptable. That is not a minor operational improvement. It is the chain of custody finally closing.
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.