When two antivirus policies conflict and neither wins, no policy is delivered to the device at all.
The resolution order is documented and reads simply enough: most secure wins, then last modified, then nothing at all. It is that third outcome that deserves your attention, because a machine which received no policy for a given setting is indistinguishable in the console from one that received exactly the right policy.
- 3 platformsLinux, macOS and Windows, plus Windows Server
- 3 settingsSupport policy merge into a superset
- Most secureWins where merge is not supported
- No policyThe outcome when a conflict cannot resolve
Every exclusion lowers the protection. Microsoft says so plainly.
No other antivirus change gets requested as often or scrutinized as little. An exclusion arrives as an ordinary service ticket, gets approved in a minute, and quietly lowers your security position for as long as it survives.
- The warning in the documentation leaves no room for interpretation: exclusions lower the protection Defender provides, the risk of each one should be evaluated before it is added, and nothing should be excluded unless you positively know it is not malicious.
- They also behave unlike almost every other setting. Processes, extensions and paths all merge, so where several policies reach the same machine those lists combine into one superset rather than one policy taking precedence over the others.
- That merging is genuinely useful and occasionally alarming. One team adds an exclusion for one application, and it becomes part of the effective configuration on every machine where those policies overlap. Almost nobody requesting an exclusion imagines it reaching that far.
- What actually controls this is a written record. An exclusion carrying a named requester, the application it exists for, a stated reason and a date to review it can be defended to anybody. A list that has quietly accumulated over three years with no provenance behind any entry cannot, and that list is exactly what a SOC 2 assessor or an insurance reviewer will ask to see.
Eight things that determine what actually reaches your devices.
Antivirus settings, without the surrounding noise
A profile here carries only what is relevant to antivirus on macOS and Windows, or to the security app your users actually see. The identical settings also live inside the endpoint protection and device restriction templates, mixed in with unrelated categories, and that mixing is precisely what makes configuring this workload through those templates harder than it needs to be.
The macOS case where nothing else works
On the Mac side there is no real choice to make. The settings in the macOS antivirus policy simply are not exposed through the other policy types, and this profile is documented as replacing the need to hand-write property list files. Treat it as the supported route rather than one option among several you might evaluate.
Policy merge, for three specific settings
Processes, extensions and paths all support merging, which means several policies aimed at the same person or machine combine into one superset rather than one winning outright. This explains something administrators find genuinely baffling: an exclusion list containing entries nobody recalls adding to that particular policy, because they arrived from a different one.
Conflict resolution, and the third outcome
Outside the settings that merge, conflicts resolve in favor of whichever policy is more secure. Where two are equally secure, the most recently modified one wins. And if even that fails to break the tie, nothing at all is delivered for that setting. Note what that means in practice: you get a silent gap rather than an error somebody would notice.
Tamper protection and its prerequisite
This is configured through the security experience profile and reaches macOS, Windows 10 and 11 including the multi-session editions, and Windows Server back to 2012 R2 provided the modern unified agent is in place. One prerequisite catches people out: the device has to be onboarded to Defender for Endpoint first, and protection switches on at the first check-in after that happens rather than immediately.
Controlled configuration, which goes further
Currently in preview, this establishes one authoritative source for Defender settings rather than several competing ones. The distinction from tamper protection is worth understanding: tamper protection pins particular settings to secure defaults, whereas this pins every applicable setting to whatever you configured centrally, with anything you left unconfigured falling back to the secure platform default.
Four Windows profiles, each with a purpose
Four profiles, each with a distinct job. One holds the core antivirus settings. A second holds exclusions, covering paths, extensions and processes. A third governs what your users see in the security app and controls tamper protection. The fourth handles update channels for the engine, the platform and the security intelligence itself.
Reports that only show the problems
The unhealthy endpoints view shows antivirus status from Defender running on the device, and only devices with detected issues appear. Devices identified as clean are not displayed, so an empty report is good news rather than a broken report.
An unresolvable conflict means no policy is delivered for that setting.
The order is published explicitly rather than left to be discovered, and it is the final step that carries the real operational consequence.
- For any setting that does not merge, a conflict passes through three steps in order. The more secure policy wins. Where two are equally secure, whichever was modified most recently wins. And where that still fails to decide, nothing is delivered to the machine at all.
- Consider what that final case actually produces. The machine gets the setting from nowhere, so it keeps whatever value it was already carrying, and nothing in the console flags this as a failure. Over time your estate drifts apart in ways nobody can trace back to any particular change, because no change occurred.
- Merging deserves attention for the same reason, working as it does in the opposite direction. Processes, extensions and paths combine into one superset drawn from every applicable policy. A single machine may therefore be running exclusions contributed by three different policies, and no one of those policies displays the complete list that machine is actually enforcing.
- Both behaviors point to the same conclusion: keep the number of antivirus policies small and give each one a named owner. Where policies have accumulated across several projects over several years, you reliably find two things sitting side by side, an exclusion superset nobody has ever audited and a set of settings that quietly resolve to nothing at all.
Four things that make antivirus policy predictable.
We assemble the effective exclusion list
Because processes, extensions and paths merge across every applicable policy into one superset, no individual policy displays what a machine is genuinely excluding. Building that combined list by hand is reliably the single most valuable hour of any antivirus review we run, and reliably the most uncomfortable one for whoever owns the estate.
We hunt for settings that resolve to nothing
When a setting does not merge and neither the security ranking nor the modification date breaks the tie, that setting simply never reaches the machine. What you have is a gap that produces no error and no alert. Reducing the number of policies is what removes the possibility of it happening rather than treating individual symptoms as they surface.
We treat exclusions as risk, because Microsoft does
The documentation is unambiguous that every exclusion lowers the protection you are paying for, and that nothing should be excluded unless you positively know it is safe. Applied practically, that means each entry in the superset needs a stated reason and a named owner. Anything holding neither should be removed, and there are always more of those than anybody expects.
We scope controlled configuration honestly
It establishes one authoritative source for Defender settings, which is the whole point, but during preview its reach stops at the antivirus and attack surface reduction templates. Detection and response, firewall configuration, settings catalog policies and account protection all sit outside it. That boundary matters, because assuming broader coverage than exists is how a consolidation project leaves gaps behind.
Four phases across roughly four weeks.
- 01Week 1
Find every source of antivirus settings
Endpoint security antivirus policies, endpoint protection and device restriction templates in device configuration, settings catalog policies, Group Policy where it still applies, and Configuration Manager where devices are co-managed. All of them can configure the same settings.
- Every source of Defender settings inventoried
- Overlapping policies identified per setting
- Group Policy and ConfigMgr contributions mapped
- Co-management workload slider position confirmed
- 02Week 2
Audit the exclusion superset
Because excluded processes, extensions and paths merge across policies into a superset, the effective exclusion list on a device is not visible in any single policy. Assembling it is usually uncomfortable, and Microsoft is explicit that exclusions lower the protection offered.
- Effective exclusion superset assembled per device group
- Each exclusion justified or removed
- Exclusions with no owner identified
- Exclusion policy consolidated where possible
- 03Week 3
Consolidate policies and resolve conflicts
A small number of clearly owned antivirus policies replacing the accumulated set, so that conflict resolution rarely has to run at all. Where conflicts remain, they are deliberate rather than accidental, and the outcome is known rather than discovered.
- Policy set consolidated with clear ownership
- Remaining conflicts identified and resolved deliberately
- Old platform profiles migrated where still in use
- macOS settings moved off property list files
- 04Week 4
Lock it down and verify
Tamper protection enabled where devices are onboarded to Defender for Endpoint, and a decision recorded on controlled configuration given its preview status and its documented scope. Then reporting verified, including that clean devices do not appear in unhealthy endpoints.
- Tamper protection enabled with prerequisites met
- Controlled configuration decision recorded with scope understood
- Reports demonstrated including the empty-is-good behavior
- Ongoing exclusion review cadence agreed
Six situations where antivirus policy needs untangling.
An organization where Defender settings vary by device
The cause is almost always several sources configuring the same settings, where conflicts land differently depending on which policy somebody edited most recently, or resolve to nothing whatsoever. There is even a published term for it: indeterminate device states, produced by multiple management channels overriding what the cloud delivered.
A business with an exclusion list nobody can explain
Since exclusions merge into a superset drawn from every applicable policy, the list a machine is genuinely enforcing appears nowhere in one place, and it grows a little each time somebody adds an entry to close a ticket. Remember that every exclusion reduces protection, which makes this accumulation a security position drifting quietly in one direction rather than a housekeeping matter.
A Mac estate configured through property list files
The dedicated macOS profile removes any need to hand-write property list files, and the settings it carries are documented as unavailable through the other policy types. So for an organization still shipping plists to Macs, this is not an alternative worth evaluating. It is the supported route, and the plists are technical debt.
An operator with a mix of Windows Server versions
Policy reaches Windows Server through Defender for Endpoint security settings management rather than the usual path, and tamper protection extends to Server 2016 and later, to version 1803 and later, and back to Server 2012 R2 where the modern unified agent is deployed. That brings machines into scope which the console does not natively surface, and which most organizations had assumed were simply out of reach.
A regulated firm that needs settings to stay set
Tamper protection pins particular settings to secure defaults. Controlled configuration goes considerably further, pinning every applicable setting to the value you configured centrally and letting anything unconfigured fall back to a secure platform default. When somebody asks you to evidence a configuration for a HIPAA assessment or a SOC 2 request, that distinction is the entire answer.
A company still using the retired platform profiles
Back in April 2022 the older platform designation was superseded. You can no longer create new profiles of the retired type, though anything already in place continues to work and can still be edited, which is exactly why nobody notices. An estate still depending on those profiles is on a path with a finite end, and the sensible time to move is before that end arrives.
How US organizations configure Defender antivirus.
| Feature | Consolidated endpoint security policy | Settings from several sources | Defaults plus local changes |
|---|---|---|---|
Effective configuration knowable | Yes | Difficult | No |
Exclusion superset audited | Yes | Rarely | Not applicable |
Conflicts deliberate | Yes | Accidental | Not applicable |
Silent no-policy gaps | None | Possible | Not applicable |
macOS managed without plist files | Yes | Sometimes | No |
Tamper protection enabled | Yes | Partly | No |
Group Policy contributions removed | Yes | No | Not applicable |
Unhealthy endpoints monitored | Yes | Rarely | No |
Update channels controlled | Yes | Default | Default |
Ownership per policy clear | Yes | No | Not applicable |
What it covers, and what it deliberately does not.
Area
Antivirus policy template
- Covered by controlled configuration
- Yes, during preview
Area
Attack surface reduction template
- Covered by controlled configuration
- Yes, during preview
Area
Endpoint detection and response
- Covered by controlled configuration
- No
Area
Firewall settings
- Covered by controlled configuration
- No
Area
Settings Catalog policies
- Covered by controlled configuration
- No, authored outside Endpoint Security
Area
Account Protection
- Covered by controlled configuration
- No, not a Defender component
Area
Settings not explicitly configured
- Covered by controlled configuration
- Revert to defaults, and local users can still modify them
Area
Group Policy and Configuration Manager values
- Covered by controlled configuration
- Overridden where Intune configures the setting
Area
Overlapping non-controlled policy settings
- Covered by controlled configuration
- Report as Not applicable on that device
Area
Scope of the switch
- Covered by controlled configuration
- Per device, reversible at the next policy check-in
Five steps, and consolidation does most of the work.
- 1
Inventory every source of Defender settings
We catalog every source: endpoint security antivirus policies, the endpoint protection and device restriction templates, settings catalog policies, Group Policy, and Configuration Manager wherever devices are co-managed. This exact multiplicity is named in the documentation as the cause of indeterminate device states that are hard to troubleshoot, so the inventory is not busywork.
- 2
Assemble the effective exclusion superset
Because processes, extensions and paths merge across every applicable policy, the effective list cannot simply be read off a screen. It has to be assembled. Once assembled, each entry is either justified with a reason and an owner or removed, on the basis that the documentation is explicit about exclusions lowering the protection you are paying for.
- 3
Consolidate to a small owned policy set
With fewer policies in play, the conflict resolution rules rarely need to run at all, and that removes the possibility of a setting quietly resolving to nothing. Whatever conflicts survive become deliberate decisions with an outcome somebody predicted, rather than accidents discovered halfway through an incident.
- 4
Enable tamper protection and decide on controlled configuration
Tamper protection requires machines onboarded to Defender for Endpoint and comes into force at the first check-in afterward rather than immediately. Controlled configuration is the step beyond it, still in preview, reaching the antivirus and attack surface reduction templates while leaving detection and response, firewall configuration and settings catalog policies outside its scope.
- 5
Verify through the reports and set a review cadence
Unhealthy endpoints shows only devices with detected issues, so an empty view is a good result rather than a broken report. Then a recurring exclusion review, because exclusions accumulate and removing one is a decision nobody makes unless it is scheduled.
What organizations ask about Intune antivirus policy.
Fifteen questions about your own antivirus configuration.
Sources
- How many antivirus policies do we have?And who owns each.
- Do device restriction templates also set these?They contain the same settings.
- Any settings catalog policies overlapping?Another source.
- Does Group Policy still configure Defender?Common in hybrid estates.
- Is the co-management slider set to Intune?Required for these settings.
Exclusions
- What is the effective exclusion superset?It merges across policies.
- Can we justify each exclusion?They lower protection.
- Who added the oldest ones?Usually unknown.
- Are any exclusions overly broad?Whole drive paths, for example.
- Do we review exclusions periodically?Most estates never do.
Protection
- Is tamper protection enabled?Needs Defender for Endpoint onboarding.
- Are devices onboarded to Defender for Endpoint?P1 or P2.
- Have we considered controlled configuration?Preview, and narrower than it sounds.
- Are we still using old platform profiles?No new versions can be created.
- Does anybody read unhealthy endpoints?Only problem devices appear.
Try to assemble the complete antivirus exclusion list for one device group.
Exclusions merge into a superset across every applicable policy, so no single policy shows it. If assembling that list takes more than an hour, you have found the problem worth fixing.
Related Services
Explore more solutions that work great with this service
Intune Endpoint Security Firewall Policy
Host firewall policy managed from Intune, per ring
Learn moreIntune Security Baselines
Security baseline design and management for US organizations: stating
Learn moreAttack Surface Reduction Rules Deployment
Attack surface reduction rules deployment for US organizations:
Learn moreMicrosoft Defender for Endpoint Services
EDR plan selection, onboarding and zero-gap AV migration
Learn moreEndpoint Security
Endpoint security for US businesses using Microsoft Defender for
Learn moreMicrosoft Intune
Device management and endpoint security
Learn more