Multi-Pass Wiping: History and Modern Storage Scope
Short answer
A historical multi-pass wiping recipe is meaningful only within its original storage assumptions. Increasing a host overwrite count does not establish that the operation reaches every location holding the old data. Review the medium, addressing path and required sanitization outcome before choosing a pattern schedule.
The practical question is not just how many passes ran. It is which data locations the selected operation could affect, what completed, and whether that result is acceptable for this asset's disposition. Keep those questions separate from the age or reputation of a method name.
Who this is for
This guide is for authorized ITAD and refurbishment teams reviewing old wipe policies, inherited scripts and tool presets. It focuses on the historical reasoning behind pattern-heavy magnetic-disk overwrites and the mistakes that arise when those recipes are transferred to different storage technology.
Verification note: The history and tool semantics here were checked against primary material. No magnetic recovery experiment, SSD extraction, device overwrite or physical sanitization test was performed. The workflow below supplies review criteria, not a report of a successfully erased drive.
When to use this
Use it when a work order requests a named historical method, a script advertises a large pass count, or a customer asks whether a 35-pass setting is stronger than a supported device sanitization procedure. It also helps a reviewer distinguish an actual processing requirement from a tool's default configuration.
When not to use this
Do not use this article as permission to change a binding customer procedure or erase unidentified media. It supplies no universal HDD, SSD or flash erase command. A disputed requirement needs an authorized resolution before processing; an operator should not silently substitute a preferred method.
What the historical patterns were trying to solve
The 35-pass Gutmann scheme appeared in 1996. Its magnetic-media analysis connected overwrite patterns with recording encodings, including modified frequency modulation and run-length-limited codes. Host data bytes and the transitions recorded on a platter were not interchangeable descriptions of the signal.
The complete schedule combined patterns for different encoding scenarios. It was not a finding that every disk needed 35 identical improvements in security. Later epilogues expressly reject applying the whole schedule indiscriminately and distinguish newer recording technology from the older cases it addressed.
That history is useful because it makes the assumptions visible. A byte pattern chosen for a particular recording code is not automatically a useful prescription for another recording channel, much less NAND flash. The paper's historical magnetic-media reasoning is not a present-day SSD sanitization specification.
Do not turn this observation into the opposite absolute claim that every overwritten bit on every drive is unrecoverable under every threat model. Historical applicability and the acceptance of a particular job are separate questions. This article does not reproduce a laboratory recovery capability or assign a probability of recovery.
Three different problems can hide behind “wipe”
A reviewer should first determine which problem the proposed operation addresses:
| Problem | Question to resolve |
|---|---|
| Ordinary logical recovery | Can the intended user-facing interface still retrieve the target data? |
| Historical magnetic remanence | Does the physical recording argument apply to this medium and threat model? |
| Copies outside the write target | Could old data remain in locations the selected writes do not address? |
These questions should not collapse into a single progress bar. A pattern schedule intended to influence magnetic transitions does not, by its name alone, expand the target of an operation. A completed partition job still needs a partition-scoped interpretation unless separate evidence establishes a wider effect.
The same caution applies to a file job. If the requested outcome concerns an entire asset, identify how a file-level operation would satisfy it before approving the work. A file name, partition name and physical asset identifier are different pieces of the record.
What SSD research changes about the question
The FAST '11 study of flash-based SSD erasure examined raw flash after sanitization attempts. It demonstrated that hard-drive-oriented methods could not simply be assumed to work on the studied SSDs. Its experiments also exposed implementation problems in some built-in erase operations.
Those are findings about the devices and techniques examined in 2011. They are not measured failure rates for current NVMe products, and a successful result on one sampled SSD would not validate another model or firmware. The enduring review issue is the difference between a logical write target and physical copies managed behind it.
For a current drive, obtain the supported operation, scope and completion semantics for its exact model and firmware. Do not claim that running an old pattern set repeatedly bypasses a translation layer. Equally, do not assume a sanitize label is sufficient evidence without resolving the implementation and operation result.
Current guidance is about suitability and assurance
NIST SP 800-88 Rev. 2 was published in September 2025 and supersedes Rev. 1. Its clear-method discussion distinguishes host-addressable overwriting from media-specific coverage limits, including flash with spare cells and wear leveling. It cautions against carrying overwrite habits across incompatible media.
For an acceptance review, identify the required method and applicable technique before execution, then examine the operation's outcome and decide whether it is adequate. A pass count is not a certification or a substitute for that decision. Historical DoD-style labels likewise do not establish a universal current requirement.
Inspect the preset instead of trusting its label
GNU Coreutils 9.12 provides a concrete example of why the exact invocation matters. Its shred interface has an iteration count and an optional final zero pass. The final zero pass is additional to the requested iterations. Its documented default is three overwrite passes; that default is a tool behavior, not a media sanitization standard.
On a station where GNU shred is already installed, these commands only inspect the program:
shred --version
shred --help
Check that the output identifies the expected GNU implementation and installed release. These invocations supply no file or device operand and do not start an overwrite. If the command is absent, record that fact; do not replace it with a similarly named utility or install an arbitrary wiping package during intake.
In a script review, inspect the actual argument list and wrapper behavior. Record whether there are extra passes, a size limit, a file-removal option or a narrower target than the work order implies. Help output establishes option semantics, not the suitability of applying those options to an asset.
The overwrite-in-place assumption also matters for file-oriented tools. Journaling of file data, snapshots, other copies and device remapping can invalidate the apparent relationship between overwriting a file and removing its prior contents. Treat the filesystem and storage path as part of the scope review.
Workflow
1. Preserve the inherited requirement
Save the exact requested method name, pass count, tool preset and procedure revision in the private job record. Identify who is authorized to clarify it. Distinguish a customer requirement from a bench convention or a default that happened to survive in a script.
If a document merely says “military wipe” or “Gutmann compliant,” ask for a precise acceptance definition through the normal review process. Do not infer a particular pattern sequence, threat model or certification from a phrase.
2. Map the target before comparing recipes
Reconcile the physical asset with the tool's selected object. Record model, serial in the private record, firmware, interface, controller path and the intended disposition. Determine whether the planned object is a file, partition, logical volume, exposed disk or another storage abstraction.
List scope uncertainties as questions that need evidence. For example: Does the procedure reach only the selected logical object? Does another stored copy require a separate job? Can the processing interface expose the required completion information? Avoid hiding those questions in a generic “passed” field.
3. Match the procedure to the medium
Retrieve the applicable device procedure and the organization's approved technique for that media type. Check restrictions for the actual model and firmware. If an old pattern-heavy overwrite is proposed, identify the current basis for using it and the outcome it is expected to establish.
When the proposed scope is insufficient, select an authorized alternative that closes the gap. Do not add passes merely because the required alternative takes more preparation. Approved destruction may be a disposition option, but its own media treatment and evidence requirements still apply.
4. Resolve conflicts before the irreversible step
If the inherited work order and the suitable supported method conflict, retain custody and obtain an amended instruction or an explicit approved exception. Preserve both versions. The history of a recipe can support that discussion, but it does not authorize a unilateral change.
The destructive boundary belongs in a separate operational runbook: identify the target again, confirm permission to lose the data, and execute only the supported procedure. This history review deliberately contains no ready-to-run destructive invocation.
5. Verify the operation that actually ran
Retain the exact tool and version, invocation or selected operation, target scope, timestamps, completion outcome, errors and interruptions. If the process ends early, report a partial attempt rather than its configured pass count as though all work completed.
A report that says “35 passes configured” is different from evidence that the defined operation completed. Neither phrase alone establishes physical coverage. Visible-address sampling cannot prove sanitization of inaccessible physical locations.
6. Make the acceptance decision explicit
Have the designated reviewer compare the actual outcome with the required disposition. Record whether the result is accepted, rejected or unresolved, and why. A rejected result should retain its evidence when another supported technique is attempted.
For example, if a synthetic job record requests whole-asset treatment but its attachment documents only a partition operation, the immediate issue is missing scope evidence. A second attachment with a larger pass number would not answer that issue. Keep the asset on hold until the scope and required outcome are reconciled.
Verification checklist
- The historical method's recording assumptions are distinguished from the current asset's technology.
- The work order specifies an actual outcome and authorized procedure.
- The selected tool object matches the claimed scope.
- The installed implementation, options and extra passes are understood.
- Completion, errors and interruptions are documented independently of configuration.
- Coverage questions are resolved through applicable evidence, not a pass-count comparison.
- Acceptance is signed off for the stated disposition.
Resale and evidence checklist
Keep the identity linkage, approved procedure revision, actual operation result, exceptions and reviewer decision with the asset. Document any authorized change from the inherited recipe. A reseller-facing summary should describe the accepted method and scope accurately, without presenting a historical label as a certification.
What not to publish
Keep serial numbers, customer work orders, identifiers, authentication material and raw processing reports private. Use synthetic examples when explaining a report defect. Do not publish unsupported claims of recovered or irrecoverable data based solely on a tool screenshot.
Common mistakes
Common errors include treating a large number as an assurance scale, applying magnetic patterns to flash without a supported basis, and counting configured passes as completed work. Another is reading an old paper's use of “modern” as a description of today's hardware. Preserve the original publication date when interpreting technical claims.
CliDeck workflow fit
A review runbook can separate the requested recipe, media suitability, actual target, operation result and acceptance. This structure helps make inherited assumptions visible. It is workflow guidance, not a claim that forthcoming CliDeck wiping software implements historical patterns, supports particular storage devices or certifies their results.
FAQ
Does 35-pass wiping establish stronger coverage than one pass?
The number alone does not establish coverage. Resolve the operation's target and suitability first; compare results against the required acceptance criteria.
Should an operator silently replace an old customer recipe?
No. Obtain an authorized clarification or revision and preserve the record before executing a changed procedure.
Is this a recommendation to use a file-overwrite utility on an SSD?
No. The tool example inspects version and help only. Device-specific suitability and physical data coverage need separate evidence.