Self-Encrypting Drives: Revert and Sanitization Evidence
Short answer
Accept a self-encrypting drive's sanitization only after matching the exact operation, parameters, protected data ranges and completion evidence to the intended disposal decision. A reset security state or an accessible drive is insufficient by itself. Some operations remove encryption keys; some security-state changes can preserve a key and its associated data.
For a PSID-based erase, use the supported procedure for the actual drive, firmware and controller path. Record the full operation name, target identity, result and exceptions. Treat a missing completion record as unresolved, even when the drive becomes usable again.
Who this is for
This guide is for authorized ITAD and storage teams processing self-encrypting drives for reuse or retirement. It focuses on a specific decision: whether a security revert actually establishes the required data-removal result.
The protocol example is TCG Opal SSC Version 2.30, published January 30, 2025, particularly sections 5.1.3.2 through 5.1.3.4. This is a version-scoped example, not a claim that every SED implements Opal 2.30. The controller example uses the Dell HII PSID erase path for eligible drives on the H975, H965, H365 and HBA465 families, excluding HBA465e. Verify the installed controller firmware, drive support and management interface before applying that path.
Verification note: This article supplies review criteria from primary documentation. No drive was queried, unlocked, reverted or erased while preparing it. There are no real device logs, measured erase times or claims of hardware validation.
When to use this
Use this workflow when an approved erase job is described as PSID Revert, RevertSP, factory-state recovery or another security reset, and the reviewer needs to establish its actual data-removal scope. Also use it when an intake report says only that a drive is now unlocked or no longer managed by its previous security configuration.
When not to use this
Do not use this guide to recover someone else's files, obtain credentials or authorize work on an unidentified drive. Do not infer support from an SED label alone. Drives behind unsupported adapters, active arrays or management layers that obscure the physical target need a supported processing path before a destructive operation is considered.
Separate three questions at intake
First, identify the hardware and its current management path. Second, determine which security subsystem and operation apply. Third, establish what evidence would justify the required sanitization decision. Combining those questions into one green status indicator makes it easy to approve the wrong outcome.
Keep a small identity record: asset reference, drive model and serial, drive firmware, interface, controller model and firmware, enclosure/slot where applicable, and tool build. Record the storage security profile that the device actually reports. A product family can contain variants with different capabilities.
On a Linux intake station, these are read-only inventory examples using util-linux lsblk:
lsblk --version
lsblk -d -o NAME,MODEL,SERIAL,TRAN,SIZE
Check the installed help and available columns. The output supports identity reconciliation; it does not demonstrate Opal support, expose a media encryption key or prove erasure. A controller can present a virtual disk rather than the physical drive. Match the displayed identity to the approved asset instead of choosing a device merely because its path ends in the expected number.
Record the physical label through an approved handling procedure. Do not pull an active array member simply to read it. Keep PSIDs and other label identifiers in the private job record. Possession of a printed code does not replace the owner's authorization.
Why the exact revert parameters matter
In Opal 2.30, the Locking SP's RevertSP method has a KeepGlobalRangeKey parameter. With that parameter true and the specified unlocked-range conditions satisfied, the Global Locking Range's key and data can be preserved while the Locking SP is disabled. With the Global Range both read-locked and write-locked, that keep-key request fails instead.
This establishes a concrete reason to record method parameters rather than the word revert alone. It does not establish that a product's separately named PSID erase uses the keep-key behavior. Match the implementation's documented action to its exact scope.
For a runbook, record what is requested and what is unknown. If the interface hides a parameter, do not invent its value from the post-operation screen. Obtain the applicable product behavior or retain an evidence exception. A clean-looking configuration page cannot resolve an unspecified key-preservation policy.
Workflow
1. Define the target data before choosing the action
Write down whether the job covers the entire physical drive, selected locking ranges, a namespace or some other supported target. Map the intended data to the actual operation's coverage. Identify external backups and independent copies separately; resetting this drive cannot remove copies stored elsewhere.
For cryptographic erase, evaluate the relevant encryption history and key handling. Determine whether target data was protected by the keys being removed and whether recoverable copies of those keys remain in scope. An algorithm name or advertised key length cannot answer those questions.
NIST SP 800-88 Rev. 2, the September 2025 final, distinguishes an operation's outcome from acceptance of its effectiveness. Its cryptographic-erase considerations include product scope, key handling and error behavior. Apply those considerations to the supported implementation; do not claim that an SED badge certifies a particular unit's disposal result.
2. Confirm eligibility through the actual management path
Use the manufacturer's supported utility or controller interface and verify that it identifies the same physical asset. Resolve active use, array membership and controller prerequisites before proceeding. Do not delete configurations or change storage modes just to make an erase option appear.
In the Dell controller example, the PSID operation applies to an eligible encryption-capable, unconfigured physical disk and is offered for SED-capable drives. The controller-family restriction matters: this workflow excludes HBA465e. Availability in another controller or utility is a separate support question.
If the expected operation is unavailable, stop and record the exact tool, firmware, target state and connection path. A missing button is not permission to substitute a similarly named action. In particular, clearing a controller's configuration is not automatically a drive-level data-removal operation.
3. Perform only the approved destructive operation
The following is the Dell HII path for the scoped controller example. The erase is destructive and is not a way to retain or recover the existing files. Complete the applicable controller and physical-disk prerequisites first.
- Enter the PERC Configuration Utility and open Main Menu → Device Management → Logical Enclosure for the correct enclosure.
- Select the reviewed physical disk and recheck its identity.
- Select Cryptographic Erase with PSID Revert from the Operations list.
- Enter the selected drive's PSID privately, then choose Go.
- At the final prompt, recheck the target and authorized scope before using Confirm and Yes.
These labels describe that controller procedure. Do not translate them into an arbitrary generic RevertSP command or assume that another vendor's factory-reset menu has the same effect. Preserve the reported outcome and any error instead of treating the confirmation click as completion evidence.
4. Resolve completion and interruption explicitly
Opal 2.30 warns that a RevertSP return status does not mean all required background work has finished. Its interruption behavior permits abort on reset, including power loss, and specifies a Data Removal Operation Interrupted indication. Read the supported completion and interruption information through the applicable product interface.
Do not import a different protocol's resume behavior into this operation. A procedure that is appropriate for an NVMe background sanitize job is not automatically appropriate for a TCG security revert. If an outage occurs, retain custody and reconcile the identified drive and operation before an approved recovery attempt.
Save both the initial request outcome and the later completion evidence where they are distinct. When the tool cannot expose enough information to close the decision, record that limitation. Avoid repeatedly resetting the device to obtain a more convenient status screen.
5. Review the post-operation state without creating confusion
Collect the drive identity again and compare the reported security configuration with the expected result. Any vendor-required refresh, restart or follow-up check belongs to the specific approved procedure. An unexpected identity, remaining configured range, interrupted state or failed response requires review.
Keep accessibility and sanitization as separate record fields. A usable device can be an expected reuse outcome, but usability alone cannot establish which keys were removed. Conversely, a device that cannot be read is not automatically sanitized.
If a reuse test writes new data, identify it as post-sanitization activity. Do not mix those writes with the evidence about the old dataset, or use a new partition table to explain away missing completion information. Sampling visible logical addresses cannot prove that inaccessible physical storage was sanitized.
Verification checklist
Before accepting the job, establish that:
- The physical drive, firmware and controller path match the approved asset record.
- The supported operation and any relevant parameters match the intended data ranges.
- Key-preservation behavior is known rather than inferred from a generic reset label.
- The original request, later completion checks and any interruption are accounted for.
- Reported errors and unsupported observations remain visible in the review record.
- External copies and the encryption/key-history assumptions have a documented boundary.
- The designated reviewer approves the result for the specified disposition.
Where evidence is insufficient, use an unresolved or failed-attempt outcome. A different supported sanitization method or approved physical destruction may be the next decision. That decision should close the identified gap, rather than merely replace one screenshot with another.
Resale and evidence checklist
Attach the selected operation, tool and firmware versions, target scope, completion result, exceptions and reviewer decision to the asset. Record the intended next owner or disposition through the normal internal process. Preserve the interrupted or failed attempt when a later attempt succeeds; it remains part of the asset's history.
What not to publish
Do not publish PSID codes, real serial numbers, label photographs, authentication values, key material, customer identifiers or raw controller reports. Public examples should explain evidence interpretation with synthetic identifiers. The private record can retain the identity linkage needed for an authorized audit.
Common mistakes
Common errors include equating unlocked with erased, assuming every revert destroys every key, accepting a returned command status before required background completion, and treating a controller configuration reset as a disk erase. Another error is assigning certification based on marketing terminology instead of the actual product and validated scope.
CliDeck workflow fit
A sanitization runbook should keep identity, eligibility, irreversible action, completion checks and reviewer acceptance as distinct stages. Store the exact operation name and unresolved parameters beside the job record. This is workflow guidance, not a claim that forthcoming CliDeck wiping software supports Opal, automates PSID handling or certifies the result.
FAQ
Does an SED label prove the old data is unrecoverable after reset?
No. Identify the supported security profile and actual operation, then evaluate coverage, key handling and completion. A product label alone cannot establish the outcome of this job.
Is every RevertSP operation an erase of the Global Locking Range?
No. The Opal 2.30 keep-key option is an explicit counterexample under its defined conditions. Review the full method and parameters rather than relying on the shortened name.
Can PSID Revert recover the previous owner's files?
The scoped PSID erase workflow is destructive. Use it only for authorized data removal with an accepted loss-of-data boundary; it is not a file-recovery procedure.