Microsoft documents the change in support article KB5130741. The scope is narrow, but people who keep data on external ReFS disks could lose access to it if they ignore the change.
What Microsoft is changing
Microsoft says that starting with Windows updates released on and after October 13, 2026, Microsoft is making hardening changes to the Resilient File System (ReFS). The article states plainly that ReFS on removable media, such as a USB disk, is not a supported configuration. It adds that the changes add auditing and enforcement controls that help administrators identify these volumes and prevent them from being mounted.
This is not a new support policy. Microsoft's ReFS overview on Microsoft Learn has long included a feature comparison table that marks "Supported on removable media" as unavailable on ReFS and available on NTFS. The same documentation lists the supported deployments. For Storage Spaces, Storage Spaces supports local non-removable direct-attached via BusTypes SATA, SAS, NVME, or attached via HBA (also known as RAID controller in pass-through mode). For basic disks, it says they include local non-removable direct-attached via BusTypes SATA, SAS, NVME, or RAID.
So the configuration was never supported. Until now, though, nothing stopped it from working. Windows will now detect it, log it and, from January, block it by default.
Microsoft describes the change as hardening. It is not a vulnerability disclosure: the KB lists no CVE and does not describe active exploitation or a specific attack.
In short: ReFS has always been documented for fixed, direct-attached storage. KB5130741 adds detection now and enforcement later.
Which Windows versions are affected
KB5130741 applies to almost every supported Windows release:
- Windows 10: Enterprise LTSB 2016, Enterprise LTSC 2019, IoT Enterprise LTSC 2021, and version 22H2 (all editions)
- Windows 11 22H2: Home and Pro, Enterprise and Education, Enterprise Multi-Session, IoT Enterprise
- Windows 11 23H2: Home and Pro, Enterprise and Education, Enterprise Multi-Session, SE
- Windows 11 24H2, 25H2 and 26H1: all editions
- Windows Server: 2012 ESU, 2012 R2 ESU, 2016, 2019, 2022 and 2025
Microsoft does not publish a separate build-number matrix. The cumulative update installed on or after October 13 delivers the audit behavior.
The Home and Pro entries matter even though ReFS is mostly a server and workstation file system. According to a long-running ElevenForum thread, client editions below Pro for Workstations can still read and write existing ReFS volumes but cannot create new ones. An external ReFS disk formatted on a server or workstation could therefore be mounted on an ordinary laptop, and that laptop is covered by the new policy.
The timeline
| Phase | Update | Default behavior |
|---|---|---|
| Audit | October 13, 2026 security update | Auditing on for qualifying external ReFS volumes. Blocking off. |
| Enforcement | January 2027 security update | Auditing and blocking both on. Qualifying volumes are blocked from mounting unless an administrator changes the setting. |
Microsoft gives no specific January date beyond "the January 2027 security update." For planning, assume that Patch Tuesday is the deadline.
The KB says January's enforcement applies to volumes that meet "either configured external-media condition" but does not define those two conditions. It also doesn't explain how Windows decides whether a disk is removable or externally attached. The safest reading: any ReFS volume that triggers the audit event in October would be blocked in January.
Event ID 524: finding affected volumes
During the audit phase, Windows writes a warning to the System log when it finds a qualifying volume:
| Property | Value |
|---|---|
| Log | System |
| Event ID | 524 |
| Source | ReFS |
| Level | Warning |
The message names the volume and states that it is on a removable or externally attached disk. This is not a supported configuration for ReFS. If a policy to block these volumes is enabled, the volume will not be mounted. Move the volume to a supported disk type. Microsoft says administrators can use this event to identify volumes that may be affected by future enforcement policies that block mounting ReFS volumes on removable or externally attached media.
The KB also explains how logging works:
- Once per volume per boot. The event is logged once for each affected volume each time the system starts. It won't flood your logs, but a drive plugged in only now and then appears only when it is actually attached.
- 32-volume audit cap. Windows tracks up to 32 affected external volumes per boot for auditing. That limit applies only to auditing. It does not limit blocking.
The second point matters. Microsoft says explicitly not to treat the 32-volume limit as an enforcement boundary. If a machine has a 33rd external ReFS volume, it may not show up in the audit log, but it will still be blocked once Block mode is active.
How to find the events
Open Event Viewer, go to Windows Logs > System, and filter the current log for Event ID 524. Check that the Source column says ReFS, because other components could in theory use the same event number.
For a quick check across many machines, a PowerShell query on the System log filtered by event ID 524 (for example, with Get-WinEvent and a filter hashtable on LogName and Id) gives you the same data in script form. Verify the provider in the results. Because the event fires only when a qualifying volume is attached at or after boot, a single scan will miss drives that sit in a drawer most of the month.
Configuration: Off, Audit, Block
The update adds one setting, RefsRemovableDeviceMountPolicy. It is a DWORD with three documented values:
| Value | Meaning |
|---|---|
| 0 | Off |
| 1 | Audit (default during the October phase) |
| 2 | Block |
Microsoft documents two locations for it:
- Group Policy-backed location:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Policies - Local registry location:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem
If both are set, Group Policy wins. A value set locally under FileSystem does not override one supplied through policy. For managed fleets, Microsoft recommends Group Policy.
After changing either value, restart the device. The new configuration does not take effect until then.
The KB names the policy but does not give a Group Policy Management Editor path or say which administrative template version contains it. Until Microsoft publishes those details, check your central store after the October update rather than assuming where the setting appears.
Rolling it out
The KB recommends this order:
- Update. Install the applicable security update released on or after October 13, 2026.
- Monitor. Collect Event ID 524 warnings from the System log across your devices.
- Assess. Identify the workflows, devices and applications that depend on external ReFS volumes. Move the data or workloads to supported storage.
- Test. Set the value to
2(Block) on a pilot group and confirm that required devices and applications still work. - Enforce. Turn on blocking when you're ready. If you configure nothing, January's update does it for you.
Microsoft warns that blocking can affect access to data on an external ReFS volume. Ensure that required data is available from supported storage before enforcing the policy. In practice, copy data off any external ReFS disk while it still mounts.
Who is likely to be affected
The KB doesn't name specific scenarios. Based on general industry practice (not anything Microsoft has confirmed), these are the likeliest cases:
- Backup rotation drives. Some admins format USB backup targets as ReFS for its integrity features and block cloning, and some backup products have encouraged ReFS repositories for their speed gains. External rotation disks are an obvious risk.
- Seeding and migration drives. People who ship large VHDX sets on external enclosures may have picked ReFS because it handles virtual disk files efficiently.
- Lab and home-lab setups. Enthusiasts who formatted a USB SSD as ReFS out of curiosity, or because they had a workstation edition that allowed it.
- Enclosures that report as external. The KB doesn't say how Windows classifies disks. Some enclosures and bus types may count as externally attached even if you think of them as permanent storage. The audit phase exists to catch exactly these cases.
There is one escape hatch. Setting the value to 0 turns the policy off, and an explicit setting overrides the January default. Treat that as a temporary bridge, not a long-term plan: Microsoft still calls the configuration unsupported and offers no exception list. Turning the policy off also removes the audit visibility the change was designed to provide.
Is this overreach?
Some readers will be annoyed that a configuration that works is about to stop working. That's a fair complaint for anyone who has run an external ReFS disk for years without trouble.
Microsoft's position is easier to defend. The configuration was documented as unsupported, the company is giving three months of audit-only lead time, and administrators get a policy switch to override the default. The bigger complaint is about what the KB leaves out. It doesn't explain the security reasoning beyond "reduced exposure," doesn't define the two external-media conditions, and doesn't explain how Windows decides a disk is removable. Administrators have to rely on the audit log to tell them what qualifies.
Bottom line
- KB5130741 adds auditing now (October 13, 2026) and blocking by default in January 2027 for ReFS volumes on removable or externally attached media, across Windows 10, Windows 11 and Windows Server 2012 ESU through 2025.
- Watch for System log Event ID 524 (Source: ReFS, Level: Warning). It is logged once per volume per boot, and audit tracking stops at 32 volumes per boot. Blocking has no such cap.
- Control the behavior with
RefsRemovableDeviceMountPolicy(0 = Off, 1 = Audit, 2 = Block). Group Policy overrides the local registry, and a restart is required after any change. - Copy data off external ReFS disks before January and plan to reformat them with a supported file system. If you need to keep a workflow running in the meantime, set the policy deliberately rather than waiting to see what January's update does.