Last technical review: June 29, 2026

“Read-only” sounds like a simple property: a storage device either allows changes or it does not. In practice, the phrase describes a rule enforced somewhere along the path between an application and the storage media.

That distinction becomes important when a Multipurpose USB Device (MUD) travels between Windows, macOS, Linux, ChromeOS, and computers that may not be fully trusted. A computer may report that the MUD is read-only while the device itself remains physically capable of accepting writes. Connect it to a different host—or start the same computer under a different operating system—and the rule may no longer apply.

The right security question is therefore not simply, “Is the MUD read-only?” It is:

 

Which component refuses the write, and does that component remain in control when the environment changes?

Once that question is answered, the strength and limits of any read-only solution become much easier to understand.

 

 

The MUD Does Not Enforce Read-Only Mode

The MUD is a mass-storage device. Its hardware and firmware do not provide a physical switch, controller setting, or other device-level mechanism that can be used to make it reject write commands.

An operating system can still treat the MUD as read-only. That is useful in the right setting, but it does not transform the MUD into inherently read-only media. The MUD remains writable if it is connected through a storage path that permits writes.

This is not merely a distinction in terminology. It determines what kinds of mistakes or attacks a control can resist.

 

A Write Passes Through Several Layers

A typical write to a USB mass-storage device moves through a chain resembling this:

Application
 -> file system
 -> volume and disk drivers
 -> USB mass-storage or UASP driver
 -> USB host controller
 -> USB device controller
 -> flash storage

At the USB transport layer, the USB-IF Mass Storage Class Bulk-Only Transport specification describes distinct command, Data-Out, Data-In, and status traffic between the host and device. A read-only rule can be imposed at more than one point in the broader storage chain. The closer the enforcement point is to the application, the more it depends on the host environment. The closer it is to the storage device—or the more independent it is from the host—the harder it is for the host to bypass.

This gives us three distinct security models:

1. Host-enforced read-only: The operating system or one of its storage layers declines to send writes.
2. Device or path-enforced write protection: The device controller or an independent component in the USB path rejects writes.
3. Verification after exposure: Writes are still possible, but later checks reveal whether the contents changed.

These models solve different problems. Treating them as interchangeable is where most confusion begins.

 

Host-Enforced Read-Only Is a Local Policy

Windows DiskPart can set or clear a disk’s read-only attribute. Linux and other operating systems offer read-only mounts, block-device settings, and removable-storage policies. The util-linux mount documentation also illustrates why the enforcement layer matters: a read-only mount is a host setting, and filesystem state or behavior can still affect whether the underlying device receives writes. When these controls are working as intended, applications see a read-only disk and ordinary write attempts fail.

For preventing accidents on a computer you administer, that can be exactly the right tool. A host-level rule can protect against:

• Accidental deletion or modification
• Applications that write metadata automatically
• Ordinary user processes that honor the operating system’s storage controls
• Routine handling mistakes within a managed environment

The limitation is the source of the rule. The booted operating system both defines and enforces it. A sufficiently privileged host may be able to clear or bypass the setting. A different computer may know nothing about it. Another operating system, recovery environment, or low-level tool may apply a different policy to the same storage device.

 

Example: One Device, Two Host Policies

Suppose you set the MUD’s read-only attribute with DiskPart on a managed Windows workstation. Windows then presents the selected disk as read-only. If the same MUD is later attached to a Linux system, that host applies its own mount and block-device policy. Its behavior should be evaluated separately rather than assuming that the Windows-enforced result is a portable property of the MUD.

In other words, a host-enforced setting belongs to the host’s view of the MUD. It is not a portable lock carried inside the MUD.

This leads to a useful rule of thumb:

If the component enforcing read-only is under the control of the system you do not trust, the protection cannot establish trust in that system.

Host-based controls are still valuable. They simply need to be matched to the right threat model. They are safeguards for cooperative or managed hosts, not proof against a hostile one.

 

Strong Prevention Requires an Independent Enforcement Point

If writes must be prevented regardless of what the connected computer requests, the refusal has to occur somewhere the computer cannot reconfigure.

For the MUD, that means adding an external hardware control such as a forensic USB write blocker or read-only USB bridge. The blocker sits between the computer and the MUD. The host may issue a write command, but the independent device prevents that command from reaching the storage media. NIST defines a write blocker as a hardware or software method that prevents media content from being added, deleted, or altered.

This changes the trust boundary:

Untrusted host
 -> write blocker: rejects writes
 -> MUD: receives permitted reads only

The important feature is not that the operating system displays a “read-only” status. It is that the storage path refuses writes even when the host attempts them.

A USB drive with controller-enforced physical write protection follows the same principle, with the enforcement built into the drive. The MUD does not contain that mechanism, so an inline write blocker is the practical way to add comparable preventive control.

As with any security hardware, the blocker must support the USB mode and device behavior required by the intended workflow. NIST’s Computer Forensics Tool Testing program publishes specifications and test results for hardware write-blocking tools, underscoring that write-blocker capabilities should be validated rather than assumed. Its role, however, is conceptually straightforward: it moves enforcement outside the host.

 

Verification Answers a Different Question

Sometimes preventing every write is impractical. In that case, cryptographic hashes or digital signatures can provide evidence about whether the MUD’s contents changed.

Before the MUD is exposed to another system, calculate and securely retain hashes of the files—or of an appropriate storage image or manifest. Afterward, calculate them again and compare the results. A signed manifest can additionally authenticate the expected values. NISTIR 8387 describes verifying hashes or digital signatures to establish that digital copies are identical and stresses storing those records where they cannot be altered or overwritten.

This is a detective control, not a preventive one:

• A write blocker aims to stop a change.
• A hash or signature aims to reveal a change.

Verification cannot make writable media read-only, undo a modification, or by itself explain why a mismatch occurred. It can, however, make unauthorized changes observable. That is especially useful when integrity matters and the MUD must remain writable for part of its job.

Prevention and verification are often stronger together. A write blocker reduces the opportunity for modification; an integrity check provides evidence that the protected contents still match the expected state.

 

Choose the Control by Asking What You Distrust

There is no single read-only control that is best for every use. The appropriate choice follows from the failure or adversary being considered.

Concern	Appropriate control	What it establishes
Accidental changes on a managed computer	Host-enforced read-only setting	The cooperating OS should refuse ordinary writes
Writes from an untrusted or compromised host	Forensic write blocker or read-only USB bridge	Writes are rejected outside the host
Need to determine whether contents changed	Hashes, signatures, or known-good comparison	Changes can be detected after exposure
Need for both prevention and evidence	Hardware blocking plus verification	Writes are blocked and integrity can be checked

This framework also prevents a common category error: observing that a disk is reported as read-only does not tell us where the rule is enforced. The same user-visible result can come from controls with very different security properties.

Frequently Asked Questions

Can Malware Bypass Windows Read-Only Mode?

A host-level read-only setting can stop ordinary writes while Windows continues to enforce it. It should not, however, be treated as a security guarantee against malware with sufficient control over the same host. When the host itself is outside the trust boundary, use an independent hardware write blocker.

Does Linux Honor a Read-Only Setting Applied in Windows?

Do not assume that a host-enforced result is portable across operating systems. Linux applies its own filesystem mount and block-device settings, and the exact behavior depends on how read-only was imposed. Evaluate the Linux storage path independently if preventing writes matters.

Can BIOS, UEFI, or Another Operating System Bypass Read-Only Mode?

BIOS or UEFI is not usually the decisive component. The key question remains where read-only is enforced. Booting another operating system or recovery environment can remove a policy that existed only in the original operating system. A device-level control or independent hardware blocker remains in the storage path regardless of which operating system starts.

Is BitLocker the Same as Write Protection?

No. BitLocker provides full-volume encryption to protect data from unauthorized access, particularly when a device is lost, stolen, or offline. It does not make an unlocked volume read-only. Encryption and write protection address different risks and can be used together.

Does Read-Only Mode Stop Ransomware?

Read-only enforcement can prevent ransomware from modifying files through the write paths that the control successfully blocks. A host-level setting is not an independent guarantee if the host is already compromised, while a hardware write blocker rejects writes outside that host. Hash or signature verification can provide separate evidence of whether protected content changed.

 

A Practical Pattern for the MUD

For ordinary use on trusted systems, an operating-system read-only setting may provide a convenient guardrail. It can reduce accidental writes without adding hardware to the setup.

When the MUD must be connected to a system that is not trusted, place a forensic USB write blocker or read-only bridge between the host and the MUD. If the contents are important enough to require evidence of integrity, verify them against securely retained hashes or signatures before and after exposure.

The MUD itself should be treated as writable storage throughout this process. Any stronger guarantee comes from the component enforcing the rule around it.

That is the broader lesson behind read-only security: the label matters less than the authority behind it. A reliable design identifies where writes are stopped, who controls that enforcement point, and how the result can be verified. Once those boundaries are explicit, “read-only” stops being an ambiguous promise and becomes a security property that can be evaluated.

 

References

1. USB Implementers Forum. USB Mass Storage Class: Bulk-Only Transport, Revision 1.0.
2. Microsoft Learn. attributes disk.
3. util-linux project. mount(8) documentation.
4. National Institute of Standards and Technology. Write Blocker.
5. National Institute of Standards and Technology. Computer Forensics Tool Testing: Hardware Write Block.
6. Guttman, B., White, D. R., Williams, S., and Walraven, T. Digital Evidence Preservation: Considerations for Evidence Handlers (NISTIR 8387). National Institute of Standards and Technology, 2022.
7. Microsoft Learn. BitLocker Overview.