Dev Drive on Windows 11: a ReFS volume with a different antivirus model, and the security tradeoff nobody reads

A developer opens a ticket. Builds are slow. Someone links a Microsoft blog post about Dev Drive, the numbers look good, and the ticket gets closed with "enable Dev Drive". Three weeks later a new volume exists on forty laptops, and nobody in the security team has been told what it is.

Here is the thing worth understanding before you approve that ticket. Dev Drive is not a tuning flag. It is a different file system, with a deliberately reduced set of file system filters attached, and a Microsoft Defender Antivirus scanning model that is genuinely different from the one running on C:. Every one of those changes is documented, supported and reversible. But they are changes to how a whole volume is protected. That is a security decision, not a performance decision. This post walks through exactly what Dev Drive is, what Windows does differently on it, and the policy surfaces you use to decide the posture rather than inherit it.

The problem: a build volume your baseline has never seen

Let me start with what a Dev Drive actually is, in plain English, because the name is unhelpful.

A storage volume is the thing that decides how files and directories are laid out on disk. Windows uses NTFS, the New Technology File System, for the system drive and for most fixed drives by default. ReFS, the Resilient File System, is a newer Microsoft file system format. Microsoft describes it as designed to maximise data availability, scale efficiently to large data sets, and provide data integrity with resiliency to corruption.

A Dev Drive is a volume you format as ReFS, using a specific switch, on a machine where the feature is enabled. Microsoft's own wording is that Dev Drive "builds on ReFS technology to employ targeted file system optimizations and provide more control over storage volume settings and security, including trust designation, antivirus configuration, and administrative control over what filters are attached."

Read that list again. Trust designation. Antivirus configuration. Administrative control over what filters are attached. Those are the three security properties this feature exists to change. The performance improvement is the outcome. Changing those three things is the mechanism.

So here are the four concrete gaps between what your security baseline assumes and what a Dev Drive delivers.

One: it is not NTFS. Anything in your estate that assumes NTFS semantics on a fixed volume can behave differently. ReFS does not support several NTFS features. I list the documented ones below, because one or two of them will surprise you.

Two: most of your minifilters are not there. Microsoft documents the default plainly. Filter Manager turns off all filters on a Dev Drive, with the exception of antivirus filters. Not "some". All of them, except the ones in the antivirus altitude range. If a security product of yours works by attaching a minifilter, and that filter is not an antivirus-altitude filter, it does not see that volume until an administrator explicitly allows it.

Three: Defender scans differently. On a trusted Dev Drive, Microsoft Defender Antivirus runs in performance mode. Real-time protection is still on, but the scan happens after the open completes rather than before. Microsoft's summary of the two states is literally "open now, scan now" versus "open now, scan later".

Four: a local administrator can turn the antivirus filter off entirely. By default, and Microsoft states this in the enterprise guidance, "a local device administrator could configure the system to remove default antivirus filters, so that no antivirus filters are attached to the Dev Drive." One command does it. Unless you have set the policy that forbids it, that command works today on your managed devices.

Why it happens: ReFS, Filter Manager and an asynchronous scan

Now the chain, in order, from the moment someone creates the volume to the moment a build runs on it. Each step is a place where you can intervene.

Step 1: creation. Dev Drive designation happens only at original format time. Microsoft is explicit that existing volumes cannot be converted. The person creating it must be a local administrator.

Step 2: the trusted flag. Microsoft documents that "Dev Drives are automatically designated as trusted using a flag stored in the system registry during the original formatting time". Trust is a per-machine property. It does not travel with the volume.

Step 3: mount, and the filter attach decision. When the volume mounts, Filter Manager decides which minifilters attach to it. Its default for a trusted Dev Drive is to attach nothing except antivirus-altitude filters. Microsoft defines that range precisely. An antivirus filter is one attached in the FSFilter Anti-Virus altitude range, 320000 to 329999. Anything else needs to be on an allow list.

Step 4: Defender reads the trust flag. A Dev Drive marked as trusted is, in Microsoft's words, "a signal for Microsoft Defender to run in performance mode." Real-time protection stays enabled on every other volume. An untrusted Dev Drive gets ordinary synchronous real-time protection.

Step 5: the build runs. File opens on that volume are scanned asynchronously. The build gets its speed from not waiting on the scan, and from ReFS-specific optimisations including block cloning, which since Windows 11 24H2 and Windows Server 2025 is supported on Dev Drive.

The drivers and binaries in the path

These are the actual files doing the work. Naming them matters, because they are what you look for when something does not behave.

What performance mode does, and does not, do

This is the part most worth getting right, so I am going to quote Microsoft rather than paraphrase. Performance mode "reduces the performance impact of Microsoft Defender Antivirus scans for files stored on designated Dev Drive." The mechanism is stated as "deferring security scans until after the open file operation has completed, instead of performing the security scan synchronously while the file operation is being processed."

Now the sentence that should end the "it is basically an exclusion" argument. Microsoft writes: "Deferring scans until after file open completes inherently provides faster performance, but with less protection. However, enabling performance mode provides significantly better protection than other performance tuning methods, such as using folder exclusions, which block security scans altogether."

So the honest summary is this. Less protection than synchronous real-time protection. More protection than an exclusion. There is a real window between the open completing and the scan finishing, and that window is the tradeoff you are accepting. Anyone telling you a Dev Drive is a free win has not read that paragraph. Anyone telling you it is the same as excluding a folder has not read it either.

Four documented limits on performance mode are worth writing into your own runbook.

Defender also has documented platform minimums for performance mode. Antimalware platform version 4.18.2303.8 or later, security intelligence version 1.385.1455.0 or later, and Defender as the primary antivirus solution.

What you cannot do on a Dev Drive

Because a Dev Drive is ReFS, everything ReFS cannot do, a Dev Drive cannot do. Microsoft publishes a feature comparison. These are the rows marked unavailable on ReFS.

Two of those bite in practice. No disk quotas means you cannot cap per-user consumption on a shared build box the way you would on NTFS. No shrinking means a Dev Drive partition you sized generously stays that size. Microsoft also documents that file system encryption on ReFS is available on Windows Server 2025 only, so do not plan around the Encrypting File System on a Windows 11 Dev Drive. BitLocker is a different story and works fine. Microsoft confirms a Dev Drive VHD is included in the BitLocker encryption of the hosting volume, and that you do not need to enable BitLocker on the mounted VHD separately.

Then there are the Dev Drive-specific restrictions, all documented.

What belongs on it, per Microsoft

This is answered directly in the documentation, and it is a short list. Source code repositories and project files. Package caches. Build output and intermediate files. For anything else, Microsoft asks you to think first.

On installing developer tools and SDKs there, the guidance is to "evaluate the trade-offs associated with the system and asynchronous scanning to ensure it aligns with the security requirements of your device and organization", and to verify that performance mode meets your needs for handling binaries. So the answer to "should a Dev Drive hold only source code" is not a flat yes. It is: source, caches and build output are the intended contents, tools and SDKs belong on C:, and anything else is a decision you have to justify.

There is also a specific note for multi-user machines that IT should read twice: "IT Admins will want to create per-user Access Control List (ACL) folders for multi-user devices as a best practice to avoid EOP attacks." EOP there means elevation of privilege. A world-writable root on a volume with a reduced filter set is exactly the shape of problem that note is warning about.

Prerequisites, and why the feature may be missing

Microsoft lists the requirements to create one: Windows 11 build 10.0.22621.2338 or later, 16 GB of memory recommended with 8 GB as the minimum, a minimum of 50 GB free disk space, local administrator permissions, and availability on all Windows SKU versions. Note that last one. This is not an Enterprise-only feature. Pro and Home devices can create Dev Drives too.

The reason the option is often missing on a managed device has nothing to do with hardware. The Dev Drive enterprise guidance states: "Dev Drive will be automatically disabled for devices that have their Windows updates managed by policies." That is temporary enterprise feature control, holding the feature back until an administrator makes a decision.

Two important qualifications, and my task brief for this post had the first one wrong, so it is worth spelling out. Microsoft's temporary enterprise feature control reference lists Dev Drive with a "Feature update that ends temporary control" of Windows 11, version 23H2. So on a device that has taken the 23H2 feature update or later, Dev Drive is no longer held back by temporary control at all. The same table notes that Dev Drive "also has multiple permanent control", pointing at EnableDevDrive and DevDriveAttachPolicy. Practical translation: on 22H2 with updates managed by policy, the feature is off until you enable it. On 23H2 and later, it is available unless a policy says otherwise. Either way, the policy is the thing you should be setting, not the temporary control.

How to verify: fsutil, fltmc, Get-Volume and Get-MpPreference

Verification comes before configuration, because on this feature the intended posture and the actual posture drift easily. Four commands tell you everything. Run all of them elevated.

1. Ask the system what its Dev Drive policy is

The first command asks Windows, machine-wide, whether developer volumes are enabled at all, whether antivirus filters are forced on, and what the filter allow lists contain. Run it with no volume argument.

Read that output carefully. The phrase "by group policy" is the whole game. Microsoft's own enterprise documentation shows the enforced version of this output, and it includes two separate allow lists: "Filters allowed on any developer volume, by group policy:" followed by the policy-supplied filters, and "Filters allowed on any developer volume:" followed by the locally-set filters. If you only look at the second list you will miss what policy is doing.

2. Ask about a specific volume

Add a volume path and the command tells you whether that volume is a developer volume, whether it is trusted, and which filters are currently attached to it. This is the single most useful Dev Drive command there is.

That last point is easy to miss and it is documented in the fsutil devdrv reference: "The dev drive filter attach policy isn't honored for an untrusted dev drive." Untrusting a volume does not just cost you performance mode. It reverts the volume to ordinary filter behaviour.

3. Confirm the file system, and confirm what the filters are really doing

Get-Volume tells you the file system type. A Dev Drive reports ReFS. Then fltmc tells you which minifilters are attached where. Compare the Dev Drive against C: and the gap is the reduced protection you accepted.

4. Confirm the Defender side

Performance mode has its own state, separate from the volume's trust state. Check both. The Defender module exposes it as a property, and the group policy writes a registry value.

Yes, zero means enabled. It is the opposite of every other Defender toggle you know, and it catches people out in reporting queries. Microsoft's Defender configuration service provider documentation is explicit: value 0 is the default and means performance mode is enabled, value 1 means it is disabled.

The registry surface

Three values drive Dev Drive policy, and they all live under one key. Both Microsoft's enterprise guidance and the FileSystem policy CSP reference name this key, and the Microsoft-supplied Administrative Template files on the device agree with it.

Microsoft's own Configuration Manager example script in the Dev Drive enterprise guidance writes exactly these three values, with those exact types, which is a useful independent confirmation. Its example multi-string value is PrjFlt, MsSecFlt, WdFilter, bindFlt, wcifs, FileInfo.

The Defender performance mode policy writes somewhere else entirely. The Microsoft-supplied WindowsDefender.admx on a Windows 11 device maps the Configure performance mode status policy to this key and value.

One more genuinely useful detail from that same ADMX file, in the policy's own explain text: "Performance mode requires the following policies also be enabled: 'Enable dev drive', and 'Dev drive filter attach policy'." So the three policies are not independent knobs. Defender's performance mode policy expects the two Filesystem policies to be enabled alongside it.

Event Viewer: be honest, there is no Dev Drive channel

I looked for one. Microsoft publishes no Event ID catalogue for Dev Drive, and there is no Dev Drive event log channel. What does exist is a Microsoft-Windows-ReFS/Operational channel and a Microsoft-Windows-ReFS provider, both present on a stock Windows 11 device, but Microsoft does not publish an Event ID catalogue for them either, and on the device I checked the channel held zero records. So do not plan a Dev Drive alert around it.

What you can legitimately monitor is the Defender channel, because Microsoft does publish those IDs. The channel name is stated once here, and every ID below is from Microsoft's Defender Antivirus event ID reference.

Log files, services and scheduled tasks: mostly a genuine no

I want to be straight about this rather than pad the section. Microsoft documents no Dev Drive log file. There is no %WINDIR%\Logs\DevDrive or equivalent. The only log path Microsoft publishes anywhere near this feature is the one written by its own example Configuration Manager script, C:\Windows\temp\ConfigDevDrive-<TimeStamp>.log, and that only exists if you actually run that script. Its healthy lines end in Success and its broken lines end in Failure, because the script compares the value it wrote against the value it reads back.

On services, there is no Dev Drive service. ReFS is a kernel driver, not a service. The service that matters to the Defender half is WinDefend, display name Microsoft Defender Antivirus Service, and it must be running for performance mode to mean anything. There is also a ReFsDedupSvc provider and channel present on Windows 11, tied to ReFS deduplication rather than to Dev Drive, and Microsoft documents deduplication as a Windows Server capability. Do not read its presence as a Dev Drive feature.

On scheduled tasks, there is no task under \Microsoft\Windows\ that drives Dev Drive. Nothing polls it, nothing re-applies it. The trust flag and the filter policy are read at volume mount time, which is why so many of these settings say a reboot or a dismount is required.

The fix: decide the posture, then enforce it with policy

The decision comes first, so let me give you a defensible default before the click paths.

If you manage developer devices and you want to allow Dev Drive, the posture I would argue for is: enable the feature by policy, force the antivirus filter to stay attached, define an explicit filter allow list that includes your EDR sensor filter, and leave Defender performance mode enabled. That gives your developers the asynchronous scan they actually came for, while removing the local administrator's ability to detach antivirus entirely and while keeping your EDR watching the volume. If you cannot commit to setting the allow list, do not enable the feature yet, because the default allow list is empty and the default local-admin freedom is wide.

Group Policy Editor, step by step

Both Dev Drive policies live in the same place. Here is the path.

1. Open the Local Group Policy Editor, or edit a domain GPO in the Group Policy Management Console.
2. Navigate to Computer Configuration then Administrative Templates then System then Filesystem.
3. Open Enable dev drive and set it to Enabled. This is what lifts temporary enterprise feature control and lets developers create Dev Drives at all.
4. In the same policy's Options pane, tick Let antivirus filter protect dev drives. This is the checkbox that stops a local administrator detaching antivirus. Leaving it unticked is what makes fsutil devdrv enable /disallowAv effective.
5. Select Apply, then OK.
6. Back in the Filesystem node, open Dev drive filter attach policy.
7. Set it to Enabled and populate the Filter list with the filter names you have decided to allow. Microsoft's guidance is worth reading twice here: with the policy Enabled and no filter list, any filter can attach. With it Disabled, local administrators are not allowed to attach or detach filters at all.
8. Select Apply, then OK, then reboot the device. Both policies document that a reboot is required.

The Defender performance mode policy is in a different tree entirely.

1. Navigate to Computer Configuration then Administrative Templates then Windows Components then Microsoft Defender Antivirus then Real-time Protection.
2. Double-click Configure performance mode status.
3. Select Enabled, then Apply, then OK.

Intune, step by step

The two Dev Drive policies are in the Settings Catalog, under the Administrative Templates surface, and Microsoft documents this path directly.

1. Sign in to the Microsoft Intune admin center.
2. Go to Devices then Windows then Configuration profiles then Create profile.
3. Set Platform to Windows 10 and later.
4. Set Profile type to Settings catalog, then select Create.
5. Give the profile a name and description, then select Next.
6. In the settings picker, search for Dev Drive, or browse to Administrative Templates\System\Filesystem.
7. Select Enable Dev Drive and its Let antivirus filter protect Dev Drives option, then Dev Drive filter attach policy and its Filter list.
8. Configure each setting, then complete Scope tags and Assignments and select Create.

Under the covers these are ADMX-backed settings in the FileSystem policy CSP. If you would rather do it with a custom profile and OMA-URI, the two nodes are documented: ./Device/Vendor/MSFT/Policy/Config/FileSystem/EnableDevDrive and ./Device/Vendor/MSFT/Policy/Config/FileSystem/DevDriveAttachPolicy. Both are device scope, both are format chr, and Microsoft notes that ADMX-backed policies need the special SyncML format rather than a plain value.

Defender performance mode is the awkward one, so here is the honest answer. Microsoft's performance mode article documents Intune configuration by OMA-URI only, not by a Settings Catalog path.

1. Go to Devices then Configuration then Create then New policy.
2. Set Platform to Windows 10 and later and Profile type to Templates, then choose Custom.
3. Add a row. Set OMA-URI to ./Device/Vendor/MSFT/Defender/Configuration/PerformanceModeStatus.
4. Set Data type to Integer.
5. Set Value to 0 to enable performance mode, which is also the documented default, or 1 to disable it.
6. Complete Assignments and create the profile.

The filter allow list, and what to put in it

Setting the list from the command line is the fast path for a pilot ring. Microsoft's syntax is fsutil devdrv setFiltersAllowed [[/f] /volume <volume path>] "filter1, filter 2, ...". Without /volume it applies to every Dev Drive on the system, and with /f the volume is force-dismounted so the change takes effect immediately rather than at next mount.

These are the filters Microsoft documents for common scenarios. Pick from this list rather than inventing names.

And if you decide the answer is no

Declining Dev Drive is a legitimate outcome and it takes one setting. Set Enable dev drive to Disabled. Microsoft documents the effect precisely: disabling it disallows creation of new developer volumes, and existing developer volumes mount as regular volumes. Note the second half. Existing Dev Drives keep their data and keep working. They just stop being special, and every filter attaches to them again. That is a clean rollback path, which is more than many Windows features offer.

There is also a device-local equivalent, fsutil devdrv disable, with the same documented effect: "Existing dev drives will function as a regular volume i.e., all filters are allowed to attach." Use the policy, not the command, on managed devices. The command is a local setting a local administrator can undo.

Proof it worked: a read-only posture report

The gap this feature creates is between the posture you intended and the posture the device has. So the companion script for this post reports the second one. It answers: does a Dev Drive exist here, is it trusted, what file system is it, what is the machine-wide policy, which minifilters are actually attached to it versus to C:, and what is Defender's performance mode state.

It is strictly read-only. Every call is a query. It never creates, formats, trusts, untrusts, or reconfigures anything, and it fails loud with exit code 1 rather than printing a clean-looking report from a failed read. It needs no modules installed.

That is a real run, trimmed for length, with the computer name replaced and third-party filter names removed. Read it as a worked example of the gap this post is about. Dev Drive support is enabled on this device, no policy constrains it, no allow list exists, and Defender's performance mode reads as disabled while the governing policy value is not configured at all. Nobody decided any of that. It is simply what the defaults plus one tenant's Defender configuration add up to.

Three lines are the ones I would put on a dashboard. Antivirus filter forced by GPO tells you whether a developer with local admin can strip antivirus off the volume. Untrusted Dev Drives tells you which volumes are quietly not getting the performance they were built for. And the per-volume filter comparison, which lists what is attached to C: but not to the Dev Drive, tells you in one line exactly what security coverage you traded away.

Run it before you enable the feature, to establish a baseline. Run it after your policy lands, to prove the policy took effect. Run it on the first ticket that says "Dev Drive is slow", because the answer is usually that the volume is untrusted.

References

Microsoft-official sources, all verified against the live pages while writing this post.

• Set up a Dev Drive on Windows 11 - the primary document. Prerequisites, creation, trust model, fsutil devdrv usage, the filter table, and the unsupported scenarios list.
• Configure Dev Drive policy for enterprise business devices - temporary enterprise feature control, the policy options, the Intune and Configuration Manager walkthroughs, and the registry values.
• Protect Dev Drive using performance mode - what performance mode is, the synchronous versus asynchronous table, the exclusion comparison, and the Intune, Group Policy and PowerShell paths.
• fsutil devdrv - full command reference including trust, untrust, setFiltersAllowed and the /f force-dismount parameter.
• FileSystem Policy CSP - EnableDevDrive and DevDriveAttachPolicy, with their ADMX mappings and registry key names.
• Defender CSP - the PerformanceModeStatus node and its 0-enabled, 1-disabled value mapping.
• Resilient File System (ReFS) overview - the ReFS and NTFS feature comparison, including the features unavailable on ReFS.
• Block cloning - the ReFS copy optimisation now supported on Dev Drive.
• Load order groups and altitudes for minifilter drivers - where the FSFilter Anti-Virus altitude range comes from.
• Microsoft Defender Antivirus event IDs and error codes - the source for every Event ID in this post.
• Format-Volume - the -DevDrive parameter.
• Temporary enterprise feature control in Windows 11 - why the feature is off on policy-managed devices.

Community deep-dives, each fetched and confirmed on-topic before citing.

One last thought. The best argument for Dev Drive is not that it is fast. It is that it replaces the thing your developers were going to do anyway, which is ask for a folder exclusion. An exclusion turns scanning off. Performance mode defers it. If the choice on the table is those two, Microsoft's own documentation says which one is safer, and it is not the exclusion. Just make sure that the exchange is the one you actually made, and that a local administrator has not quietly made a different one on your behalf.