Controlled folder access blocked your backup software: reading the block events and allowing one app without allowing everything

Your backup agent ran fine for two years. This morning it started logging access denied against the user's Documents folder. You check the NTFS permissions and they are correct. You check the service account and it is a local administrator. You run the same copy by hand from an elevated prompt and it works. Nothing in the backup product's own log mentions Microsoft Defender, because the backup product has no idea Defender is involved. It asked the file system to write a file, and the file system said no.

That is what controlled folder access looks like from the outside. It is a Microsoft Defender Antivirus feature that blocks writes based on which process is asking, not on which account is asking. Because it returns a normal access-denied error rather than a distinctive one, it is one of the easiest Windows security controls to spend a whole afternoon misdiagnosing as a permissions problem.

This post explains what controlled folder access actually protects, how it decides whether to trust a process, and how to read the block event so you get the exact executable path and the exact target folder. Then it shows how to allow one application without loosening the control for everything else. Every registry path, event ID, binary and policy path below has been checked against Microsoft documentation or against the Microsoft-authored policy definition file on a live Windows 11 device.

The problem: a write that fails for no visible reason

Controlled folder access, which Microsoft abbreviates to CFA, is part of the attack surface reduction family of features in Microsoft Defender for Endpoint. Its job is narrow and it does that job well. It stops ransomware encrypting your documents.

It does this by refusing writes from processes it does not recognise. That is the whole mechanism. There is no signature, no heuristic on the file contents, no scan. If the process is not trusted and the target is protected, the write fails.

The trouble is that plenty of legitimate software looks exactly like ransomware to that rule. Consider what these four things have in common:

• A backup agent that enumerates a user's Documents folder and rewrites index or catalogue files inside it.
• A file sync client that is not OneDrive, writing into a folder under the user profile.
• An installer that extracts to a randomly named folder under C:\Windows\Temp and then writes into the user's profile.
• A build or scripting tool moving output files around inside a Documents subfolder.

All four are unfamiliar processes making bulk writes into protected user folders. That is the ransomware shape. CFA blocks them, and the application on the receiving end reports whatever its error handler says for a failed write, which is almost always the generic access-denied message.

Three facts about CFA make the diagnosis harder than it should be.

First, CFA is off by default. Microsoft documents the default mode as 0, Disabled. So on a device where CFA has never been turned on, you will never see this. That means when it does appear, it usually appears the day after somebody assigned a new Intune endpoint security policy, and the person troubleshooting the backup agent is not the person who assigned it.

Second, CFA follows folder redirection. Microsoft documents that if a folder is redirected, CFA protects it in the redirected location. On a device using OneDrive Known Folder Move, the protected Documents folder is the one inside C:\Users\<username>\OneDrive - <organization>\, not the one in the local profile. So the path in the block event will not match the path you expected.

Third, CFA requires Microsoft Defender Antivirus to be the active antivirus in Normal mode with real-time protection on. Microsoft is explicit that CFA does not work in Passive mode, Passive mode with EDR in Block mode, Limited Periodic Scanning, or Off. That means a device can carry a perfectly configured CFA policy and enforce nothing at all, which produces the opposite confusion: a control you think is protecting you that is not.

Why it happens: CFA judges the process, not the account

To fix this properly you need the chain of events in order. Here it is, from the moment your backup agent calls into the file system to the moment the event lands in the log.

1. Your backup agent calls a Win32 write API. That becomes an IRP_MJ_CREATE or write request travelling down the file system stack for that volume.
2. WdFilter.sys, the Microsoft Defender Antivirus file system minifilter, sees that request. It is registered at altitude 328010, inside the 320000 - 329998 FSFilter Anti-Virus range that Microsoft publishes in the allocated filter altitudes list. That altitude is why Defender gets to see the write before it reaches the volume.
3. The filter asks the Defender engine whether this process is trusted for this target. The engine is hosted in MsMpEng.exe, running as the WinDefend service.
4. The engine checks the target path against the protected folder set: the fixed default folders, plus anything an administrator or policy added.
5. The engine checks the calling process against its trust decision. Microsoft documents that Defender "assesses every type of executable file (including .exe, .scr, and .dll files) and automatically trusts most apps based on their prevalence and reputation". On top of that automatic list sits the explicit allowed-application list you control.
6. If the process is not trusted and the target is protected, the write is failed or allowed-and-recorded depending on the mode, and an event is written to the Microsoft-Windows-Windows Defender/Operational channel.

Step 5 is where the false positives come from, and there are two distinct reasons a legitimate application lands on the wrong side of it.

The first reason is simple obscurity. Prevalence and reputation are global signals. A backup product with two thousand customers worldwide has low prevalence by Microsoft's standards. It is not malicious, it is just rare, and rare looks the same as new.

The second reason is more interesting, and it is the one that produces the really baffling cases. Microsoft documents it directly: "Some types of endpoint security or asset management software inject code into every process that starts on the system. This injection can result in CFA no longer trusting known applications like Office apps." In other words, an agent you deployed for a completely unrelated purpose can taint the trust of every process on the box, including Microsoft's own.

The five modes, and why the default is the wrong one to start with

CFA is not a simple on/off switch. Microsoft documents five values, and two of them are about the disk rather than about files. The following table reproduces the documented modes and their documented numeric values.

Modes 3 and 4 exist because the two halves of CFA have very different false-positive profiles. Microsoft's own reasoning is worth quoting: "Disk sector writes rarely come from legitimate apps, so this protection generates few false positives." Protecting the boot record from bootkits and disk wipers is cheap. Protecting user folders is where the tuning work lives.

That gives you a genuinely useful staged rollout. Turn on mode 3 in production immediately for boot-record protection, and run mode 2 in parallel on a pilot ring to build the allow list, before you move anyone to mode 1.

Not every method supports every mode

This catches people who test locally and then deploy. Microsoft publishes a support matrix, and the important lines are these. The Windows Security app supports only On and Off, which map to modes 1 and 0. You cannot set Audit Mode from the Windows Security app at all. Microsoft Configuration Manager supports Disabled, Enabled and Audit Mode, but not the two disk-modification modes. Intune, the Policy CSP, Group Policy and PowerShell support all five.

What is protected by default, and what you cannot change

Microsoft documents the default protected set as the hard drive boot sectors, plus the following folders for user accounts and for system accounts such as LocalService, NetworkService and systemprofile:

Two things to note. Microsoft states flatly that "you can't modify the list of default protected folders". There is no supported way to remove Documents from CFA protection. If a folder in that list is a problem, the answer is to allow the application, never to unprotect the folder.

Also note what is not in that list: the Desktop. Desktop appears in Microsoft's documentation only in the note about OneDrive Known Folder Move, where it says CFA protects a redirected folder in its redirected location and gives Documents, Pictures and Desktop as the examples. So on a Known Folder Move device the redirected Desktop can be in scope, while on a device without redirection the plain local Desktop is not in the documented default set. Test rather than assume.

CFA exclusions are not antivirus exclusions. Be precise about this.

This is the single most common wrong fix. Somebody sees Defender blocking a backup agent, adds an antivirus path exclusion for the agent, and is surprised when nothing changes. Microsoft's exclusions reference lists these as separate exclusion types, configured in separate places, with different capabilities.

There is one place where an antivirus exclusion genuinely is the right answer for a CFA problem, and it is the code-injection case. Microsoft's guidance is that if the client analyzer shows an injecting process is causing the detections, you should "consider adding an antivirus exclusion for that process". Note the target: the exclusion goes on the injecting agent, not on the blocked application. That is a narrow, specific case, not the general fix.

One more precision point, because it changes what you can write in a policy. Microsoft documents that antivirus and ASR rule exclusions support only system environment variables, while CFA allowed applications also support user environment variables such as %LOCALAPPDATA% and %USERPROFILE%, resolved in the context of the user running the app. CFA allowed applications also support the * wildcard in the folder portion of the path. CFA protected folders support environment variables but explicitly do not support wildcards. Same feature, three different path grammars.

How to verify: mode, lists, events, log files

Work from the outside in. First establish that CFA is even capable of enforcing. Then read the mode. Then read the lists. Then read the events, which is where the actual answer lives.

Step 1: confirm Defender is actually enforcing

The command below reads Defender's runtime state. It changes nothing. Run it from an elevated PowerShell window, because the Defender cmdlets return less to a non-elevated caller.

Step 2: read the mode and the lists

Now read the CFA settings themselves. The first line prints the mode number. The remaining lines print the three lists that matter: the immutable default folders, any extra folders, and the explicit allow list.

Step 3: read the block event, which is where the answer is

The mode and the lists tell you the policy. The event log tells you the incident. CFA writes its events to one channel, stated once here because every path below lives in it:

Microsoft publishes the following event IDs for this feature area. The right-hand column is the part people get wrong, so it is worth reading carefully: several of these IDs belong to sibling attack surface reduction features and have nothing to do with CFA.

Here is what a real CFA audit event looks like in Event Viewer. This is a genuine 1124 from a lab device with the user name, computer name and organisation name replaced.

Read it like this. Process Name is the exact string you will paste into the allowed-application list. Path is the protected folder that was targeted, and it is the answer to "which folder was this even about". The phrase "would have been blocked" tells you this was Audit Mode; in Block mode the wording is a straight "was blocked". User matters because CFA resolves user environment variables in the context of the calling user, so an allow entry using %LOCALAPPDATA% resolves per user.

Microsoft publishes a ready-made XML filter for a CFA-only custom view. Import it through Action › Import Custom View in Event Viewer, or paste it into the XML tab of Create Custom View:

<QueryList>
  <Query Id="0" Path="Microsoft-Windows-Windows Defender/Operational">
   <Select Path="Microsoft-Windows-Windows Defender/Operational">*[System[(EventID=1123 or EventID=1124 or EventID=1127 or EventID=1128 or EventID=5007)]]</Select>
   <Select Path="Microsoft-Windows-Windows Defender/WHC">*[System[(EventID=1123 or EventID=1124 or EventID=1127 or EventID=1128 or EventID=5007)]]</Select>
  </Query>
</QueryList>

If you have Defender for Endpoint Plan 2, the same evidence is available fleet-wide in advanced hunting. The action type names are the documented ones:

DeviceEvents
| where ActionType in ('ControlledFolderAccessViolationAudited','ControlledFolderAccessViolationBlocked')
| project DeviceName, FileName, FolderPath, InitiatingProcessFileName, InitiatingProcessCommandLine

Step 4: the registry surface, and one honest correction

The Group Policy and MDM surface for CFA lives under a single parent key. That parent is stated once here and the table below is relative to it. This is confirmed both by the Policy CSP documentation and by the Microsoft-authored WindowsDefender.admx policy definition file shipped in C:\Windows\PolicyDefinitions.

Now the correction. It is often claimed that there is a matching "preference" key at HKLM\SOFTWARE\Microsoft\Windows Defender\Windows Defender Exploit Guard\Controlled Folder Access holding whatever Set-MpPreference wrote. On a live Windows 11 26200 device with Defender platform 4.18.26070.9, an elevated read of that path returns Requested registry access is not allowed. Microsoft does not document a supported preference-key layout for CFA. Treat the non-policy Defender hive as opaque, use Get-MpPreference as the source of truth for effective state, and do not build detection logic on reading those keys directly.

Step 5: the binaries and the log file

If you want to understand where the enforcement actually happens, these are the components in the path. Only files verifiable on a live device or in Microsoft documentation are listed.

You can confirm the minifilter is loaded and attached without installing anything. fltmc is in-box.

Defender's own diagnostic log is a text file, and it does carry CFA state. The files live here:

Two strings in that file are useful. The first confirms the loaded state. On a device in Audit Mode, a real line reads:

Engine-HIPS:Loaded ASR vdm rule "Controlled folder access", State=2, Action=0, Type=1

The State=2 matches the documented Audit Mode value, which is a satisfying cross-check that the engine really did load the mode you deployed. The second string is more revealing. Lines of this shape appear when a process loses trust because something injected into it:

Engine:Process C:\Program Files\<vendor>\Agent\collector.exe (PPID:nnnnn) is tainted:
TaintType:0x1. TaintReason:C:\Windows\assembly\...\SomeLibrary.ni.dll, EnableCfa:1

For the trust question specifically, Microsoft points at a supported tool rather than the log file. The Defender for Endpoint client analyzer, run with the -cfa argument, "reports the reason for each CFA detection, which helps you decide whether to allow the app". If you have an application that is blocked and you cannot work out why, that is the supported answer.

Step 6: services and scheduled tasks

Three services are relevant, and one common assumption is wrong.

No scheduled task drives controlled folder access. This is worth saying explicitly because it is a reasonable thing to assume and it is wrong. The tasks under \Microsoft\Windows\Windows Defender\ on a Windows 11 device are Cache Maintenance, Cleanup, Verification and Scheduled Scan. All of them serve scanning and signature housekeeping. CFA is enforced synchronously and in real time by the minifilter on every write. There is no periodic job to check, no task to re-run, and no "trigger the task to make policy apply" step. If you deploy an allow list and it does not seem to apply, the thing to restart is the blocked application, not a scheduled task.

Step 7: run the companion script

Doing all six steps by hand for every reported case is tedious, so there is a read-only script that does the whole pass and groups the events by process and target path, which is exactly the shape you need to build an allow list. It is on GitHub in the Windows 11 scripts repository under controlled-folder-access-false-positives, as Get-CfaStateReport.ps1.

It reads only. It calls Get-MpPreference, Get-MpComputerStatus, Get-Service, Get-WinEvent and registry reads, and nothing else. It aborts with exit code 1 rather than print a clean-looking report if it is not elevated or if a required read fails, because a CFA report that says "no blocks found" when the read actually failed is worse than no report at all. It reports HIDDEN rather than empty when Get-MpPreference returns the exclusions-are-hidden marker.

The fix: allow one app, not the whole folder

You now have the exact executable path from the Process Name field of a 1123 or 1124 event. Add that one path to the allowed-application list. Do not add a protected folder exclusion, because there is no such thing, and do not try to remove the folder from protection, because Microsoft does not allow it.

Option A: Intune endpoint security policy (recommended)

Microsoft's documented path uses an Attack surface reduction policy. Note that CFA settings live inside the ASR rules profile, not in a profile of their own, which is the main reason people cannot find them.

1. Sign in to the Microsoft Intune admin center at intune.microsoft.com.
2. Select Endpoint security in the left navigation, then Attack surface reduction.
3. Select Create policy.
4. Set Platform to Windows.
5. Set Profile to Attack Surface Reduction Rules. This is the profile that carries the CFA settings.
6. Select Create, then give the policy a name such as ASR - CFA audit ring and select Next.
7. On Configuration settings, find Enable controlled folder access and select a mode. For a first deployment choose Audit Mode.
8. Find Controlled folder access allowed applications. Select Add and paste the executable path from the event, for example C:\Program Files\Contoso\BackupAgent\bkupsvc.exe. Repeat for each application. Alternatively select Import and supply a CSV whose first line is the literal header ControlledFolderAccessAllowedApplications followed by one path per line.
9. If you need to protect folders beyond the nine defaults, use Controlled folder access protected folders with the same Add or Import method. Remember: environment variables are supported here, wildcards are not.
10. Select Next, set Scope tags if you use them, then assign the policy to a pilot device group first. Select Next, review, and select Create.

Option B: Group Policy

The Group Policy path is the same on a domain controller through the Group Policy Management Console and on a single device through gpedit.msc.

1. Open the Group Policy Management Console on your management machine, or run gpedit.msc on the device.
2. Expand Group Policy Objects, right-click the GPO you want, and select Edit.
3. Navigate to Computer Configuration › Administrative Templates › Windows Components › Microsoft Defender Antivirus › Microsoft Defender Exploit Guard › Controlled Folder Access.
4. Open Configure controlled folder access. Set the policy to Enabled, then in Configure the guard my folders feature choose one of Disable (Default), Block, Audit Mode, Block disk modification only or Audit disk modification only.
5. Open Configure allowed applications. Set it to Enabled, select Show..., then for each application enter the full path and file name as the Value name and the digit 0 as the Value.
6. Open Configure protected folders if you need extra folders. Set it to Enabled, select Show..., and enter each folder path as the Value name with 0 as the Value.
7. Close the editor and run gpupdate /target:computer /force on a test device.

Option C: any MDM through the Policy CSP

If you are not using Intune, the same three settings are available as OMA-URIs in the Defender area of the Policy CSP. List values are separated by the pipe character.

The first takes an integer from 0 to 4. The other two take pipe-separated strings, for example C:\Apps\app1.exe|%ProgramFiles%\Fabrikam\DriveManager\*\DriveService.exe. All three are device-scoped, not user-scoped, and Microsoft documents them as applicable from Windows 10 version 1709 onward.

Option D: PowerShell on a single device

For a one-off test or a single server, use Add-MpPreference. The command below appends one application to the allow list without touching anything already there.

Things that will still bite you

Three documented behaviours cause "I allowed it and it is still blocked" tickets.

The path is matched exactly. Microsoft documents that "only the app in that location is allowed to access protected folders. If an app with the same name is in a different location, it isn't added to the allowed list and might be blocked." An agent that updates itself into a new versioned folder will start being blocked again after the next update, which is precisely what the wildcard patterns are for.

Script engines are never trusted implicitly. Microsoft states that "script engines like PowerShell aren't trusted by CFA, even if you create an allow indicator by using indicators of compromise. The only way to allow script engines to modify protected folders is by adding them as an allowed app for CFA." If your backup or maintenance work runs through a PowerShell script, the thing to allow is the engine executable.

Endpoint data loss prevention can override your allow entry. Microsoft's note is direct: if you allowed an app but CFA still blocks it, Purview data loss prevention might be preventing your allowed apps from taking effect. The documented diagnostic is to run the client analyzer for at least five minutes and search the .evtx files in the EventLogs folder of MDEClientAnalyzerResult.zip for instances of DLP EA.

Proof it worked: a real audit-mode run

The output below is a genuine run of Get-CfaStateReport.ps1 on a Windows 11 Enterprise 26200 device with Defender platform 4.18.26070.9, in Audit Mode, managed by Intune. The user name, computer name, organisation name and application paths have been replaced with placeholders. Everything else, including the counts, the timestamps and the literal hidden-exclusions marker, is exactly what the device returned.

The second half of the same run is where the operational value is. The script groups every CFA event by process and target path so the allow list writes itself.

Two conclusions follow directly from that output, and they are the two you want from any audit-mode soak.

First, the ranking tells you what to allow. Nine events from one executable against one folder is a repeating scheduled job, and it is the first candidate for the allow list. A single event from a tool a user ran once by hand probably is not.

Second, the target paths tell you the folder set is the redirected one. Every group targets a path under OneDrive. If you had written an allow entry, or a monitoring rule, against C:\Users\<user>\Documents, it would never have matched anything on this device.

Community deep-dives worth reading

Both of the following were fetched and confirmed to be on this exact topic before being listed.

References

• Protect folders from ransomware with controlled folder access - Microsoft Learn. The modes table, the default protected folder list, the trust model, and the allowed-application path grammar.
• Configure controlled folder access - Microsoft Learn. Intune, Defender portal, Policy CSP, Configuration Manager, Group Policy, PowerShell and Windows Security app procedures.
• Monitor controlled folder access activity - Microsoft Learn. The event ID table, the advanced hunting action types, and the client analyzer -cfa guidance.
• Attack surface reduction events in Windows Event Viewer - Microsoft Learn. Separates the CFA IDs from the ASR rule, exploit protection and network protection IDs, and supplies the custom-view XML.
• Policy CSP - Defender - Microsoft Learn. OMA-URIs, allowed values, and the ADMX-backed Group Policy mapping including the registry key name.
• Exclusions reference for Microsoft Defender for Endpoint - Microsoft Learn. The table that proves CFA, antivirus and ASR exclusions are separate types.
• Configure custom exclusions for Microsoft Defender Antivirus - Microsoft Learn. Documents that HideExclusionsFromLocalAdmins makes exclusions invisible to Get-MpPreference and Registry Editor.
• Allocated filter altitudes - Microsoft Learn. Confirms WdFilter.sys at altitude 328010 in the FSFilter Anti-Virus range.
• Run the client analyzer on Windows - Microsoft Learn. How to obtain and run the analyzer and what its result package contains.