SPI NOR Sanitization: Firmware and Separate Security Registers

Short answer

Removing data from an SPI NOR chip requires a map of the main array, separately accessed storage and protection state. Replacing a firmware image or obtaining a blank main-array read does not establish that every location capable of holding a secret was processed.

The release question is concrete: where did this platform store target data, which operation covers each location, and what evidence shows that operation completed? Keep firmware usability, write protection and data removal as separate review items. A board that boots normally can still have an unresolved storage-area exception.

Who this is for

This guide is for owner-authorized board refurbishment and decommissioning teams reviewing SPI NOR storage. The case study is W25Q128JV, Revision G, April 8, 2019, for the Industrial and Industrial Plus grades described in that document. It is not a universal recipe for every W25Q suffix, another manufacturer's part or a newer revision.

No target board, programmer or electrical setup was provided. The workflow is therefore a qualification and evidence review. It does not prescribe wiring, protection-register writes or a destructive command to run on unknown hardware.

When to use this

Use this review before accepting “BIOS flashed,” “factory image restored” or “chip erased” as a data-sanitization result. Start with the platform's storage layout rather than assuming that firmware flash contains executable code only.

Ask the platform owner where device configuration, credentials, provisioning material and other target data can be stored. Record the actual answer; this article does not claim that every listed category exists on every board. Include authorized backups and recovery images if their target data also requires disposition.

When not to use this

Stop if the chip identity, voltage, board isolation, selected array range or protected-area treatment is unresolved. A programmer that can identify a part is not automatically qualified for every feature of that part.

Do not clear protection bits indiscriminately, set permanent locks as a cleanup step, or experiment with security storage on a production asset. If required data is in a location that cannot be erased through an approved process, hold the asset for an approved alternative disposition. Making it unreadable to one application is not sufficient evidence of removal.

Workflow

1. Build a storage inventory before selecting an operation

Record the physical board and chip identity, exact suffix, applicable datasheet revision, host or programmer, software build and electrical qualification. Correlate reported identity with the physical asset and platform design. Do not rely solely on a filename such as bios.bin or the capacity of a downloaded firmware image.

Map the main-array regions by address and role. Identify retained boot code, target-data regions, reserved areas and any range the approved access path cannot read. Then add separate rows for special storage and protection state. Include other nonvolatile components in the board-level review when the platform places target data there.

For each row, require one of three dispositions: processed with evidence, excluded with a justified reason, or unresolved. A region cannot disappear from the record merely because the selected utility does not expose it.

2. Recognize the separate-register case

The W25Q128JV example has three 256-byte Security Registers, accessed separately from the main memory array, with their own erase/program/read instructions. Their corresponding lock bits can permanently prevent modification. Do not infer their disposition from an ordinary main-array image comparison or from the name of a generic chip-erase option.

The same example also has a factory-set read-only unique identifier. Distinguish immutable identification from customer-programmed target data. A fixed identifier is not something a generic sanitization program should promise to overwrite; if an identifier itself creates a confidentiality issue, address that in the release policy.

These details are model-scoped. Other SPI NOR devices may organize special storage or protection differently. A label such as “OTP” describes a restriction that must be understood, not a portable erase instruction.

3. Review tool options without touching the device

For a flashrom classic CLI build, local information commands have this form:

flashrom --version
flashrom --help

These forms were checked against upstream revision 93546a16f2e096eab3f67a015dc7487f81a25e29. They request local program information and were not run against a chip for this article. Record the actual installed build and inspect its own help before selecting any programmer operation.

In that interface, short option -R means version, while -v means verify against a file. Do not substitute one for the other based on another tool's conventions. No programmer-specific read, erase or write command is supplied here because its correctness depends on the board, part and access setup.

Ask whether the chosen software separately supports the required special areas and exposes meaningful protection and completion information. A successful main-array operation proves no more than its supported and observed scope.

4. Qualify protection and the irreversible boundary

Capture the applicable protection state before destructive work. Determine which restrictions are temporary, which are nonvolatile, which depend on board signals and which are permanent. Keep this observation separate from the authorized decision to change a writable protection setting.

In the dated example, protection can prevent a Chip Erase operation from executing, and permanently locked Security Registers reject their erase operation. A control request that was sent is therefore not enough: the procedure must establish acceptance and completion for the selected target.

Do not “fix” a permanent restriction by repeatedly retrying or by writing unrelated status bits. Record the covered area and the unresolved location. Obtain an engineering disposition when a required secret cannot be removed by the approved method.

5. Execute a model-qualified sequence and retain results

Before execution, freeze the target identity, area map, exact method, supported electrical conditions, expected timing bounds and recovery behavior. Obtain the owner-approved retention decision and ensure that competing board activity cannot alter the target during the operation.

The W25Q128JV example uses write-enable prerequisites and a BUSY indication during relevant program/erase work. Treat these as parts of a complete transaction, not as standalone proof of sanitization. Do not invent a fixed timeout or assume that a reset after interruption completed the operation.

Preserve the actual command transcript and result, addressed scope, status observations, errors and interruptions. If communication is lost or the device remains busy beyond the qualified conditions, segregate the asset and use the documented recovery process. A later successful boot must not erase the earlier exception from the record.

6. Verify the right area, then make the release decision

Compare read-back only with its declared scope. A firmware-image match can show that the selected bytes match the approved image; it cannot automatically settle special registers, inaccessible ranges or copies elsewhere. Keep the expected post-operation state for each area explicit.

For separately addressed storage, require its own supported observation or removal evidence. For immutable or permanently locked locations, retain the applicable limitation and disposition. Avoid classifying “not readable by this utility” as “empty.”

After any necessary platform reprovisioning, account for newly written data separately from remnants of the previous owner. The acceptance record should say what was removed, what was restored, and what remains excluded. Restoration of functionality and acceptance of data removal are related engineering tasks, but neither proves the other.

Verification checklist

• Exact chip suffix, grade, revision and board association are recorded.
• Main-array regions and separately accessed storage have individual dispositions.
• The actual tool build and supported area coverage are identified.
• Protection state and permanent restrictions are retained in the evidence.
• Completion and errors are tied to the operation and addressed scope.
• Read-back claims do not exceed the interface's observed areas.

Resale and evidence checklist

Retain the asset identity, target-data inventory, approved procedure, actual result, exception list and approving reviewer. A main-array-only result must be labeled that way. If required Security Register data remains unresolved, the asset must not receive an unsupported whole-chip success statement.

NIST SP 800-88 Rev. 2 distinguishes checking the outcome of a technique from validating whether the result is adequate. Apply that distinction to every required region, not just the largest storage range. Keep confidential engineering backups under the same disposition process rather than treating them as harmless byproducts.

What not to publish

Do not publish firmware dumps containing secrets, customer identifiers, unique provisioning material or private recovery images. Do not claim that a generic chip erase removes every immutable or separately accessed value. No certification, resistance to physical recovery or forthcoming software capability is established by this article.

Common mistakes

Calling an image rewrite sanitization. Determine whether the selected write actually addresses all target-data regions.

Ignoring separate security storage. A main-array dump cannot answer every question about the package.

Equating lock with deletion. Preventing modification or access is different from removing the stored value.

Using a familiar short option from another tool. Confirm the installed CLI's meaning before operating on hardware.

Treating an all-ones image as universal proof. First establish that the read path, scope and expected state are correct.

CliDeck workflow fit

A runbook can make the storage-area inventory, protection review and acceptance evidence mandatory before release. Attach actual observations to the asset record when the approved workflow supports it. This is a process recommendation, not a claim that CliDeck currently provides SPI NOR programming or special-register sanitization.

FAQ

Does restoring factory firmware prove that customer data is gone?

No. Establish the exact regions and copies processed by that platform operation, then verify its result and remaining exceptions.

Can permanent Security Register locks be undone by a normal erase?

For the W25Q128JV revision used here, the corresponding locks are permanent. Do not claim successful removal from such a region without a supported basis and disposition.

Is every fixed identifier a sanitization failure?

No. Classify its role and confidentiality implications. Distinguish an immutable manufacturer identifier from customer-programmed sensitive content rather than promising that every value will change.

Related guides

Compare NAND pages, erase blocks and bad-block evidence, examine eMMC's separate storage areas, and review key copies that can survive cryptographic erase.

Verification note: model-scoped review, no chip operation

The dated datasheet case and local help/version command forms were reviewed against primary material and pinned upstream code. No SPI chip was read, unlocked, erased, programmed or physically tested. The workflow describes evidence required during a future qualified operation.