Software can always be told to switch off a software control, so the storage that holds a root of trust, a safety configuration or evidence needs a write barrier that compromised software cannot lift. MITRE D3FEND names the countermeasure Hardware-based Write Protection (D3-HBWP) and defines it as "Physical methods of preventing data from being written to computer storage." It sits under the Harden tactic as a child of Platform Hardening, with the relation hardens Secondary Storage. D3FEND's entry is short: one definition and one reference, an industrial transmitter vendor's FAQ on its write protect switch. This card turns that into practice across the three places the control matters most (boot firmware flash, industrial field devices and forensic acquisition), how to check it is engaged and where it fails. It is written for platform, OT and incident response engineers.
Key takeaways
- A physical signal, not a setting. The protection comes from a switch, jumper, pin or bridge device that the host's software cannot override; anything that can be changed from the operating system is a software control.
- Three main uses. Locking the read-only region of boot firmware, locking configuration on industrial field devices, and keeping evidence drives unchanged during forensic work.
- Almost no ATT&CK mapping. D3FEND 1.6.0 shows a single inferred technique, T1619 Cloud Storage Object Discovery, which has little practical connection to a physical write barrier; the useful threat links on this page are NHI Mgmt Group's view.
- Order matters for firmware. On SPI flash, hardware write protection pins the status register so that software protection ranges cannot be changed; ChromeOS documentation states "You cannot disable software write protect if hardware write protect is enabled."
- The weak point is physical access and process. Anyone who can open the case, flip the switch or attach a debug tool can lift it, and updates need a controlled way to do exactly that.
D3-HBWP at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-HBWP (d3f:Hardware-basedWriteProtection) |
| Tactic | Harden |
| Parent technique | Platform Hardening |
| Digital artefact | Secondary Storage (relation: hardens) |
| ATT&CK techniques listed by D3FEND | One inferred: T1619 Cloud Storage Object Discovery (D3FEND 1.6.0, checked November 2026) |
| Related ATT&CK mitigations listed by D3FEND | None |
| D3FEND reference | "What is Hardware Write Protect?", an industrial pressure transmitter FAQ |
| Main limitation | Defeated by physical access to the switch or bus, and of no use if the protected data was already bad when it was locked |
Where it is implemented
| Setting | Mechanism | What it protects | Who controls it |
|---|---|---|---|
| Boot firmware (SPI flash) | WP# pin on the flash chip plus the status register write disable bit and block protect ranges | The read-only firmware region that starts verified boot | Platform engineering; lifted only for controlled firmware work |
| Industrial field devices | Write switch or jumper on the device electronics, often combined with a password and sealed covers | Device parameters and calibration | OT engineering under change control |
| Forensic acquisition | Hardware write blocker bridge between the evidence drive and the examiner's computer | Evidence drives during imaging and review | Incident response and forensics teams |
| Removable and embedded media | Write protect switches or lock modes on media and devices | Golden images, installers, configuration media | Asset owners |
Boot firmware flash
The ChromeOS write protection documentation is a well-documented public example of the pattern. The read-only firmware is the root of trust for verified boot, and "the entire system security hinges upon the integrity of the RO firmware." When the hardware signal is asserted, the flash chip makes the configured region read-only and, in the documentation's words, the "Write Status Register (WRSR) instruction is no longer accepted for execution", so even compromised software on the CPU cannot shrink the protected range. The signal has been controlled by a screw inside the case on older devices, by a separate secure element on newer ones, and in some designs by disconnecting the battery; a connected debug board can force it either way. The same pin and status register mechanism exists on SPI flash used in many servers, network devices and embedded boards, but whether the platform wires and uses it is a design decision to confirm with the hardware vendor. See the Firmware and Boot Security Guide.
Industrial field devices
The reference D3FEND cites describes a slide switch labelled WR on the transmitter's CPU board. In the Disabled position it blocks parameter changes from a handheld communicator, a configuration tool or the local display; reaching it requires removing power, the amplifier cover and the display board. The FAQ states the password and the switch "can be applied independently or in combination", and adds cover locks against tampering. The purpose given is protecting devices in safety systems, custody transfer and critical processes from "tampering or inadvertent changes to their setup". Many field device families offer a similar switch or jumper; check each model's manual. See the OT Security Guide.
Forensic acquisition
Hardware write blockers sit between an evidence drive and the examiner's system so the drive is not altered during imaging. NIST's Computer Forensics Tool Testing (CFTT) programme publishes Hardware Write Block specifications (version 2.0 with a test plan) and test reports for individual devices and firmware versions. Pick devices with a published test report for the firmware version you run. See the Digital Forensics (DFIR) Guide.
Which attacks it blocks
D3FEND's only inferred link, T1619 Cloud Storage Object Discovery, comes from the shared storage artefact and has little practical bearing on a physical write barrier. In NHI Mgmt Group's view, the control is relevant to these techniques:
| ATT&CK technique (v20) | How hardware write protection helps | Condition |
|---|---|---|
| T1542.001 System Firmware (Enterprise) | Blocks writes to the protected firmware region from the running system | Region covers the code that verifies the rest of boot |
| T1495 Firmware Corruption (Enterprise) | Prevents destructive overwrites of protected firmware | Only the protected range; other regions stay writable |
| T1693 Modify Firmware (ICS) | Blocks remote firmware and parameter changes on devices with a write lock | Switch left in the protected position outside change windows |
| T1485 Data Destruction and T1565.001 Stored Data Manipulation (Enterprise) | Keeps golden media and evidence drives unchanged | Media stays write-protected while attached |
For the attacker side, see MITRE ATT&CK T1542 Pre-OS Boot, MITRE ATT&CK T1495 Firmware Corruption and T1693 Modify Firmware.
Implementation steps
- Find the storage worth locking: boot firmware on endpoints, servers and network devices; safety and custody transfer instruments; golden images and installers; evidence handling kit.
- Confirm the hardware supports it: ask the hardware vendor whether the flash WP# signal is wired and enforced, and check field device manuals for a write switch or jumper. Record which assets cannot be hardware-locked.
- Verify the content before locking: write protection preserves whatever is there, so verify firmware against signed vendor images and device parameters against the approved configuration first. See D3-SFV System Firmware Verification.
- Engage protection and seal access: set the switch or jumper, close and seal covers, and record the state in the asset register.
- Write the change procedure: define who may lift protection, for which change ticket, with two-person presence for safety systems, and how protection is restored and checked afterwards.
- Pilot an update cycle: run one firmware or parameter update end to end with the procedure before rolling it out, so teams do not leave protection off to avoid the effort next time.
- Rollback: keep known-good firmware images and parameter backups; with protection on, rollback is a controlled reflash under the same procedure.
How to verify it works
- Firmware state: query the platform's own reporting. The ChromeOS example uses crossystem wpsw_cur (1 means hardware protection is on) and reports the software protection range separately; other platforms expose equivalent state through vendor tools.
- Write test: in a lab, attempt an authorised write to the protected region or parameter with protection on and confirm it is rejected, then confirm it succeeds only through the change procedure.
- Field devices: during inspection rounds, attempt a harmless parameter change from the handheld tool and confirm it is refused, and check cover seals.
- Forensic kit: keep the CFTT test report for each write blocker model and firmware version, and run an internal validation (hash a test drive before and after use) after any firmware update.
- Drift: alert on any change of reported write protection state outside a change window, and investigate unexplained device restarts or configuration changes.
Metrics (examples, not standards)
| Metric | Source | Example target |
|---|---|---|
| In-scope assets with hardware write protection engaged | Asset register and inspection records | 100 per cent of capable assets |
| Protection lifts without a change ticket | Change records against reported state | Zero |
| Average time protection stays lifted per change | Change records | Within the change window |
| Write blockers with a current test report and internal validation | Forensic kit register | 100 per cent |
Limits, bypasses and failure patterns
- Physical access lifts it: a screw, switch, battery or debug connector is the control, so anyone with time alone with the device can remove it. Pair with physical security and seals. See D3-PAM Physical Access Mediation.
- Protected range too small: on SPI flash only the configured block protect range is read-only. If it does not cover the code that verifies the rest of boot, the attacker writes around it.
- Advisory switches: some media switches only signal the host, which then decides whether to honour them. Treat a media switch as a convenience unless the device itself enforces it.
- Locking in a compromise: protection preserves bad firmware or a wrong setting as faithfully as a good one. Verify before locking.
- Left off after maintenance: the most common failure is a switch never returned to the protected position. Make restoring protection a checklist step with a second person signing.
- Software controls mistaken for hardware ones: operating system policies that deny writes to removable storage are useful, but an administrator or malware with administrator rights can change them. See the Removable Media and USB Control Guide.
Framework mapping
| Framework | Reference | Fit |
|---|---|---|
| NIST SP 800-53 Rev. 5 | SC-34 Non-modifiable Executable Programs; SC-34(1) No Writable Storage; SC-34(2) Integrity Protection on Read-only Media | Direct |
| NIST SP 800-53 Rev. 5 | SI-7(10) Protection of Boot Firmware | Direct for firmware flash |
| NIST SP 800-53 Rev. 5 | CM-5 Access Restrictions for Change | Physical control over who can make changes |
| NIST CSF 2.0 | PR.PS-01 Configuration management practices; PR.DS-01 Data-at-rest protection | Locked configuration and protected media |
| ATT&CK mitigation | M1046 Boot Integrity | Related area; see the M1046 Boot Integrity guide |
This mapping is NHI Mgmt Group's view; D3FEND lists no ATT&CK mitigation for D3-HBWP.
Related countermeasures
- System Firmware Verification (D3-SFV) and Firmware Verification (D3-FV): confirm the content is good before it is locked. See D3-FV Firmware Verification.
- Bootloader Authentication (D3-BA): relies on a protected root of trust. See D3-BA Bootloader Authentication.
- Operating Mode Restriction (D3-OPR): the OT counterpart that keeps controllers out of program mode. See D3-OPR Operating Mode Restriction.
Practitioner checklist
- List the storage whose integrity must survive a full software compromise.
- Confirm with hardware vendors which assets enforce a hardware write signal.
- Verify firmware and parameters against approved baselines before locking.
- Make sure the protected firmware range covers the verified boot root of trust.
- Seal covers and switches and record protection state in the asset register.
- Use a written, ticketed, two-person procedure to lift and restore protection.
- Use write blockers with a current NIST CFTT test report and validate them internally.
- Check protection state during routine inspections and alert on drift.
Standards and references
- MITRE D3FEND: Hardware-based Write Protection (D3-HBWP)
- NIST: CFTT Hardware Write Block specifications and test reports
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls (SC-34, SI-7(10))
- ChromiumOS: Write Protection
- Yokogawa: What is Hardware Write Protect? (reference cited by D3FEND)
Related NHI Mgmt Group resources: Firmware and Boot Security Guide · M1046 Boot Integrity · OT Security Guide · MITRE D3FEND Guide