Starting with the Windows security updates released on October 13, 2026, Microsoft has begun auditing ReFS volumes stored on removable media, such as external drives connected over USB. From the January 2027 security update, Windows is scheduled to refuse to mount those volumes by default. External drives that have worked without problems until now could become inaccessible after the update. Using ReFS on removable media was already unsupported by Microsoft, but this change turns that limitation into standard Windows behavior. Affected environments will need to decide ahead of time whether to keep the current behavior through a configuration change or to migrate their data to a supported storage configuration.

AD

External ReFS volumes will be refused by default from January 2027

According to Microsoft's support document KB5130741, the change applies to all supported Windows platforms. That includes not only Windows 11 but also businesses and organizations that use Windows Server. The specific updates that apply differ by OS, however, so administrators need to check the Windows version and update status of the systems they use. Microsoft is introducing the change in two phases, auditing and then blocking, so organizations can assess the impact on their operations beforehand.

Update timing Default behavior Impact on users and administrators
October 13, 2026 security update Audits affected ReFS volumes. Blocking is off by default Event logs can be used to identify affected devices and investigate business impact
January 2027 security update Auditing and blocking enabled by default Mounting of affected volumes is refused unless an administrator changes the setting

It is worth noting that external ReFS drives will not stop working the instant January 1, 2027 arrives. The switch to refusing mounts by default will take place with the January 2027 security update. Because blocking is disabled by default in the October 2026 update, affected drives will not suddenly become unusable at that stage either. Microsoft asks organizations to use the audit feature first to identify affected environments, take the necessary measures, and then prepare for the introduction of blocking.

Mounting is the process that makes a volume on a storage device available to the OS. This change refuses that process; it does not delete the stored files or reformat the ReFS volume. Still, if a volume cannot be mounted, its data can no longer be read or written through normal means, so an external drive used for business could suddenly become unusable. The change targets only ReFS volumes on removable media. It does not ban USB devices in general, and it does not disable ReFS on internal storage across the board. Microsoft says the aim is to strengthen security, but KB5130741 does not disclose specific vulnerability numbers, examples of exploitation, or the detailed mechanism used to determine which devices are affected.

Event ID 524 identifies the drives that will be affected

The key to finding affected environments is ReFS warning event 524, which is recorded in the Windows event log. According to Microsoft, when a ReFS volume on removable or externally attached storage is detected in a configuration considered unsupported, this event is written to the System log. By checking for event 524, administrators can identify drives that may be refused after the January 2027 update. If affected devices are identified during the audit period, data migration and changes to operating procedures can be considered before access is actually lost.

There are limits to how events are recorded, however. Microsoft explains that the warning event is logged once per affected volume at each system startup. In addition, up to 32 volumes can be tracked for auditing per boot. That figure of 32 is a limit on audit tracking, not a cap on the number of volumes subject to mount refusal.

This distinction matters in environments that handle many external drives. Even if the number of volumes recorded in the audit log reaches the limit, other affected volumes are not exempt from future blocking. For that reason, it is not appropriate to conclude that a particular drive is unaffected simply because no event 524 was recorded for it. In addition to log-based auditing, you need to check how your storage is actually connected and which file system it uses.

For example, if an external ReFS drive is used to carry data or for backups, simply listing the drives is not enough. It is important to understand which PCs or servers they connect to, and which applications and business processes depend on the stored data. Microsoft also recommends identifying affected devices, workloads, and applications during the audit period and moving the necessary data and processes to a supported storage configuration.

AD

External ReFS was already unsupported, and problems arose in 2022

To understand this change, it helps to distinguish between being able to mount a ReFS volume and Microsoft officially supporting that configuration. In fact, using ReFS on removable media such as external USB drives has long been unsupported. Microsoft's support document KB5010691 records a problem in which, after the January 11, 2022 update, removable volumes formatted with ReFS could fail to mount or were recognized as RAW. That document also stated explicitly that removable media, including external USB drives, is not supported for ReFS.

For the 2022 problem, an out-of-band update was released on January 17 of that year, along with a resolution for ReFS version 2 and later. However, that was a response to a failure at the time, and it did not make ReFS on removable media officially supported. The current change is a planned measure that introduces mount refusal as the default behavior after an audit period, and it differs in nature from the 2022 failure. Just because volumes became mountable again after a past update does not mean the same configuration can continue to be used in the future.

Comparing KB5130741 and KB5010691 with the official ReFS overview, this change calls for treating three questions separately: whether a volume can be mounted, whether it is supported, and whether it is recorded in the audit.

Question What Microsoft's official documents confirm Operational caution
Can it be mounted? Affected volumes are refused by default from the January 2027 update. Administrators can change the setting Actual access depends on update status and the policies applied
Is it supported? ReFS on removable media has long been unsupported Past usability or lifting the block does not mean official support
Is it recorded in audit? Logged once per affected volume per boot. Up to 32 volumes tracked Logs are a clue for impact assessment; absence of a record alone does not mean a drive is unaffected

ReFS is a file system designed with an emphasis on data availability, reliability, and support for large-scale storage. It uses checksums for metadata and can optionally apply them to file data as well. Combined with Storage Spaces mirror or parity configurations, it can also automatically repair corruption from another copy when it is detected. But having these data protection features is a separate matter from whether a configuration in which a standalone USB drive is carried around and used is supported. The reliability features of ReFS alone are not a reason to keep using an unsupported configuration.

Official Windows Server documentation sets certain conditions on the hardware and applications used in supported ReFS configurations. In examples such as basic disks, non-removable locally attached storage is assumed, and when used as a backup target, conditions such as fault tolerance and availability on the application or hardware side also apply. Moving an external drive to internal storage therefore does not necessarily satisfy every support requirement. When choosing a migration destination, you need to check not only the file system but also the storage configuration and the applications involved.

The block can be lifted, but Microsoft recommends moving to a supported configuration

The mount restriction is controlled by a registry value named RefsRemovableDeviceMountPolicy. It is a DWORD, where 0 means disabled, 1 means audit, and 2 means block. Microsoft's official documentation lists audit as the default in its settings table, while the rollout schedule explains that auditing and blocking will both be enabled by default from the January 2027 update onward. Administrators should therefore be careful not to read the default in the settings table alone and conclude that mounting will still be allowed after January 2027.

Where the setting is stored differs between Group Policy and the local registry. The locations Microsoft gives are HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Policies for Group Policy and HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem for the local setting. If values exist in both, Group Policy takes precedence, so in environments where policies are distributed by an organization, changing only the local value will not produce the expected behavior. Whichever method is used to change the setting, a Windows restart is required for it to take effect.

Microsoft's recommendation is to first apply the relevant Windows update and review the audit log to identify affected storage and workloads. Then, move the necessary data and applications to a supported storage configuration and verify the blocking behavior in a managed environment. For data used in business operations in particular, you need to ensure it can be accessed normally from supported storage before the January 2027 restriction takes effect.

If administrators change the policy, the option to maintain access to external ReFS volumes remains. However, lifting the block does not make that storage configuration officially supported by Microsoft. There is no guarantee that the same behavior will be maintained in future Windows updates, and for long-term operation, moving to a supported configuration is the basic countermeasure.

What matters about this change is not only whether external ReFS drives can be mounted again after the January 2027 update. Because a configuration that previously worked will be restricted by Windows' default behavior, it is necessary to prepare in advance an environment where the data you need remains usable. The important steps are to understand the scope of impact through event 524 auditing, confirm business dependencies, and then proceed with migration to supported storage and verification of its behavior.