Write Blocker

A write blocker is a piece of equipment (sometimes also a piece of software) that performs one specific function: it prevents any data from being written to a source drive while still allowing reads. The blocker sits between the source drive and the computer doing the analysis, intercepting commands as they travel between the two. The source drive can be a traditional HDD, an SSD, a USB stick, or any other storage device the examiner needs to read without modifying.¹

How a hardware write blocker works

The standard configuration is straightforward: source drive plugs into one side of the write blocker, host computer plugs into the other side. From the computer’s perspective, the drive looks like a normal connected device that responds to read commands but reports write attempts as errors. From the drive’s perspective, it never sees a write command at all; the write blocker absorbs them silently or reports failure to the host.

Two operating modes

Hardware write blockers operate in one of two modes:

• Strict denial: all write commands are rejected and reported to the host as errors. The host operating system sees the drive as read-only.
• Cached writes: write commands are accepted and stored in the write blocker’s internal memory for the duration of the session. The host operating system sees writes “succeeding” but the actual drive never receives them. When the session ends, the cached writes are discarded.

Cached-write mode allows some host operating systems to function normally with the connected drive (since they think writes are working), while still preserving the source drive intact. This is useful for scenarios where strict-denial would prevent the OS from properly mounting the drive at all.

The forensic bridge terminology

“Write blocker” and “forensic bridge” are often used interchangeably. The Wikipedia entry for forensic disk controllers notes that the device “is named forensic because its most common application is for use in investigations where a computer hard drive may contain evidence.”² The “bridge” terminology emphasizes that modern devices typically also handle interface conversion, allowing a SATA drive to connect to a USB host or an NVMe drive to connect to a USB-C host while simultaneously providing write-blocking. In the recovery industry, both terms refer to the same general category of equipment.

Patent and industry history

Hardware write-blocking was invented and patented by Steve Bress and Mark Menz (US Patent 6,813,682). The technology emerged in the early 2000s as digital evidence handling moved from ad-hoc to standardized practice. Early write blockers were dongles fitting between a computer and an IDE or SCSI hard drive. The advent of USB and SATA produced the form factors most common today, and NVMe write-blocking has emerged as a newer category as more storage moves to that interface.

The reason write blockers are necessary at all has to do with a behavior most users don’t realize their operating system performs: modern operating systems write to attached drives automatically, before the user does anything. This is the “first touch” problem, and it’s what makes “I’ll just be careful” insufficient for forensic work.³

What Windows writes to attached drives

When Windows mounts a drive, it performs several automatic operations that involve writes:

• NTFS journal updates: Windows updates the $LogFile NTFS journal file when it mounts the drive, recording the mount event and any cleanup operations the journal indicates are needed.
• Last access timestamps: Windows may update access timestamps on files and directories the OS examines during the mount process.
• System Volume Information folder: Windows may create or update this hidden folder, used for system restore points and indexing.
• Recycle Bin metadata: Windows may create or update $Recycle.Bin directory structures.
• Windows Search indexing: if indexing is enabled, Windows may begin reading file content (which on some file systems updates access timestamps).
• Antivirus scanning: Windows Defender or third-party antivirus may scan the drive immediately on mount, reading every file (which updates access timestamps).

None of this requires the user to open a single file. Within seconds of plugging in the drive, several megabytes of write activity may have occurred.

What macOS writes to attached drives

macOS performs similar automatic activity, with some differences:

• Spotlight indexing: by default, macOS begins indexing newly mounted drives, which involves reading every file and may write index data to the drive.
• .DS_Store files: macOS creates these directory metadata files when Finder examines folders.
• .Trashes folder: created automatically on mounted drives to support drag-to-trash operations.
• HFS+ or APFS journal updates: the file system journal records the mount event.
• Quarantine attributes: may be added to files on the drive for Gatekeeper purposes.

What Linux mounts write

Linux is generally more controllable than Windows or macOS, but default mounts still perform writes:

• Journal updates: ext4, XFS, and other journaling file systems update their journals on mount.
• Last mount time: the file system superblock typically records when the file system was last mounted.
• Mount counter: some file systems increment a counter on each mount, which is itself a write.
• fsck behavior: if the file system is marked dirty, an automatic fsck may run, performing repairs that constitute writes.

Linux can be configured for read-only mounting via the ro mount option, but this is software-enforced and depends on correct configuration. Hardware write-blocking provides protection regardless of OS configuration.

Why this matters for evidence

For forensic acquisitions, even seemingly innocuous changes break the integrity proof. The integrity guarantee for a forensic disk image depends on showing that nothing changed on the source between seizure and acquisition; automatic OS writes break that chain:

• Hash mismatches: if the drive is modified between the moment of seizure and the moment of imaging, the hash of the imaged drive will not match any pre-imaging baseline.
• Timestamp changes: last-access times on files reflect when files were examined, which can affect the timeline reconstruction the case depends on.
• Forensic artifacts: automatic indexing and journal updates can create artifacts that are indistinguishable from artifacts that might have been created during the period of investigation.
• Chain of custody breaks: any modification, even unintentional, opens the door for opposing counsel to argue the evidence cannot be trusted.

Write-blocking can be implemented in hardware or in software. Both approaches prevent writes to the source drive, but they differ in implementation, reliability, and evidentiary weight.⁴

How hardware write-blocking works

A hardware write blocker is a physical device that intercepts write commands at the hardware bus level. The device contains its own controller that runs firmware specifically designed to filter the command stream between the host and the drive. Write commands never reach the drive itself; the hardware controller handles them before they get there. Because the protection is at the hardware level, it doesn’t depend on the host OS being correctly configured or on any software running correctly.

How software write-blocking works

Software write blockers like SAFE Block (by ForensicSoft) run as drivers or services on the host computer. They intercept write commands at the OS level, before the OS would send them to the drive’s hardware. Software write-blocking depends on the OS being correctly configured and on the software not having bugs that allow writes through. In normal operation, software write-blocking works well; the failure mode is typically configuration error or software defect rather than systematic failure.

Side-by-side comparison

Concern	Hardware write-blocker	Software write-blocker
Where it intercepts	Hardware bus level (physical device)	OS driver or service level
Depends on host OS config	No	Yes
Depends on software being correct	Hardware firmware only	OS plus software stack
Works across operating systems	Yes (any OS the bus supports)	Per-OS implementations needed
Court-preferred	Yes, strong default	Sometimes accepted; supplementary
Cost	$200-$2,000+ per device	$50-$500 per license
Portability	Physical device to carry	Software install on workstation
NIST CFTT testing	Yes, multiple validated devices	Less common

Why hardware is the forensic default

For court-admissible work, hardware write-blocking is the strong default. The reasons are about defensibility against legal challenge:

• Independent validation: hardware devices can be tested by independent organizations (NIST CFTT) to specific published requirements. Software running inside the host OS is harder to validate independently.
• OS independence: a hardware device works correctly regardless of what the host OS is doing. A software write-blocker depends on the host OS being correctly configured throughout the session.
• Bug surface area: a hardware device has a small, specialized firmware codebase. Software running in a general-purpose OS has a much larger surface area where bugs could allow writes through.
• Demonstrability: in court, an examiner can physically point to the device used and show that it has documented validation. Software write-blocking is harder to demonstrate to a jury.

Software write-blocking is sometimes used in addition to hardware (defense in depth) or in scenarios where hardware isn’t practical. It’s almost never a replacement for hardware in cases that may go to court.

The National Institute of Standards and Technology operates the Computer Forensic Tool Testing (CFTT) program, which tests forensic tools against published requirements and publishes results. For hardware write blockers, NIST CFTT is the closest thing the industry has to an authoritative validation standard.⁵

The four top-level CFTT requirements

NIST CFTT defines four requirements that hardware write blockers must satisfy:

1. The HWB device shall not transmit any command to the protected storage device that modifies the data on the storage device. This is the core function: no writes get through.
2. The HWB device shall return the data requested by a read operation. Reads must work correctly.
3. The HWB device shall return without modification any access-significant information requested from the drive. Identify commands, capacity reports, and other metadata must come through accurately.
4. Any error condition reported by the storage device to the HWB device shall be reported to the host. Drive errors must be visible to the examiner.

These four requirements seem simple but cover the cases that matter: the drive cannot be modified, the drive can be read, the drive’s identity is preserved, and errors aren’t hidden.

The Federated Testing program

NIST CFTT publishes test results for specific tested devices through the Federated Testing program. Recent test results include:

• WiebeTech USB Data Diode WriteBlocker v2.1.0.7 (September 2024)
• Apricorn Aegis NVX Firmware v0203.7846 (January 2024)
• Tableau Forensic Universal Bridge (April 2023)
• CRU USB 3.0 WriteBlocker (January 2023)
• WiebeTech Forensic ComboDock v6 (June 2022)
• WiebeTech Forensic UltraDock v6 (June 2022)
• WiebeTech NVMe WriteBlocker (June 2022)
• Coolgear SS-127ASD USB 3.0 to SATA (multiple versions)

NIST testing applies to a specific firmware version of a specific device. Updating the firmware can invalidate the previous validation, so examiners working under strict standards verify they’re running the validated firmware version.

Why NIST validation matters in court

Using NIST-validated equipment provides documented support for the examiner’s testimony:

• Independent verification: the tool’s correct behavior has been verified by an entity independent of both the manufacturer and the examiner.
• Documented test methodology: NIST publishes the test methodology so opposing counsel can examine what was tested and how.
• Transparency: the test results are public, so any expert can review them.
• Federal endorsement: NIST is a US federal agency; its testing carries weight in US courts.

Outside the US, other validation programs exist with similar functions, but NIST CFTT is the most widely cited in international forensic literature.

The hardware write blocker market is dominated by a handful of vendors, each with a product line covering different interfaces and form factors.

Major vendors

Vendor	Status	Position
Tableau	Now part of OpenText	Long-standing standard; widely used by law enforcement
WiebeTech / CRU	WiebeTech is part of CRU	Strong NIST CFTT testing record across product line
Apricorn	Independent	Aegis line, including NIST-validated NVX
Atola	Independent	Insight Forensic includes built-in write-blocking on source ports
Logicube	Independent	Forensic imagers and write blockers, common in government use
Digital Intelligence	Independent	Forensic workstations and write blockers
Coolgear	Independent	Lower-cost USB-to-SATA write blockers
SalvationDATA	Independent	DCK2 and other forensic acquisition equipment

Interface coverage

Modern forensic acquisitions need write blockers covering current and legacy interfaces:

• SATA: the most common consumer drive interface; universally supported by all major vendors.
• SAS: enterprise-class interface; supported by professional-grade write blockers.
• USB 2.0, 3.0, USB-C: external drives and removable media; covered by USB-specific products like the WiebeTech USB Data Diode.
• NVMe: the newer high-speed interface for modern SSDs; specific products like the WiebeTech NVMe WriteBlocker handle this. Increasingly important as more storage moves to NVMe.
• IDE: the legacy parallel ATA interface for older drives; supported by some current write blockers and most universal devices.
• FireWire: legacy external drive interface, less common today; specialized devices for legacy media.
• Thunderbolt: newer high-speed interface; specialized write blockers exist but coverage is less standardized.
• eSATA: external SATA; covered by combination devices or specialized adapters.

Forensic duplicators vs write blockers

Forensic duplicators (like the OpenText Forensic TD4 Duplicator) and write blockers are related but distinct:

• Write blockers let an analyst read from a source drive without modifying it; the analysis happens on the host computer.
• Duplicators create exact copies of source drives via sector-by-sector cloning, sometimes one-to-many for evidence distribution. Most modern duplicators include integrated write-blocking on the source side.

Many forensic equipment products combine multiple functions: a single device may serve as imager, write blocker, and duplicator depending on configuration.

Pricing tiers

Write blocker pricing varies by capability and certification status:

• Entry-level USB write blockers: $200-$500. Basic SATA-to-USB or USB-to-USB write protection.
• Mid-range multi-interface bridges: $500-$1,500. SATA, IDE, USB, and sometimes SAS support.
• Professional integrated devices: $1,500-$5,000+. NIST-validated, multiple interfaces, integrated imaging capabilities.
• Forensic workstations with built-in write-blocking: $5,000-$25,000+. Complete acquisition stations with multiple write-blocked ports.

What write blockers don’t do

Write blockers prevent writes; they don’t perform other forensic functions:

• They don’t bypass disk encryption. A BitLocker-encrypted drive read through a write blocker is still encrypted; the encryption keys are needed separately.
• They don’t recover deleted data themselves. Recovery happens against the imaged drive using forensic analysis tools.
• They don’t perform hash verification automatically, though many integrated forensic bridges include hash computation as an optional feature.
• They don’t prevent the drive from receiving non-write commands like SMART queries, identify commands, or status checks.
• They don’t make the host computer forensically sound on their own. The examiner still needs proper acquisition tools, hash verification, and chain-of-custody documentation.