Intune firewall rules: why they silently fail to apply

Intune firewall rules are the one policy type that routinely reports success in the portal and enforces nothing on the device. The rule list looks correct, the assignment looks correct, the setting status reads as applied, and the traffic you meant to block still flows. The cause is usually not the rule you are staring at. It is the profile that rule travels inside, and the all or nothing way Windows applies that profile.

Windows treats a firewall policy as an atomic block. One malformed rule takes the entire profile down with it, and the portal gives you no obvious place to read that. Add a second firewall profile, a security baseline, and whatever Group Policy still survives on the device, and you have the evaluation problem described in Intune policy conflict with considerably less reporting. Every Microsoft fact below was verified against Microsoft Learn on 25 September 2026.

Where firewall policy lives, and what conflicts with what

Firewall policy sits under Endpoint security > Firewall in the Intune admin centre. For Windows there are three profile types, and the distinction between the first two accounts for most of the confusion in support tickets.

Microsoft’s firewall policy documentation is explicit that a Windows Firewall profile does not conflict with a Windows Firewall rules profile. They are separate settings surfaces and they coexist by design. Two Windows Firewall profiles assigned to the same device do conflict, and so does a Windows Firewall profile against a firewall setting delivered through device configuration. When they do, the documentation states that the conflicting setting is not sent to the device at all, so the device keeps its previous value rather than either of yours. That is the first thing to rule out when the global state is wrong rather than an individual rule.

Why Intune firewall rules fail without an error you can read

The Firewall configuration service provider carries one sentence that explains more production incidents than anything else in the documentation:

Atomic blocks are “all or nothing.” If a firewall rule or firewall setting in an Atomic block fails to be applied, the entire Atomic block fails to be applied.

A firewall rules profile is delivered as an atomic block. If rule 14 of 40 references a path Windows cannot parse, or an address token the device does not recognise, all 40 rules fail. Nothing partially applies. The device keeps whatever it had before, which on a freshly enrolled machine means the default inbound block and no custom rules at all, and on an existing machine means the previous version of the profile still running quietly while you believe you have replaced it.

What surfaces in Intune is a setting status of error and, very often, the generic 65000 code. That code is not specific to firewall policy and it does not name the rule that failed. It is the client reporting that the configuration service provider rejected what it was sent. The useful information is on the device, not in the portal, and that is where the next section goes.

Reading what actually landed on the device

The default policy store for Get-NetFirewallRule is the PersistentStore, which Microsoft describes as the persistent policy for the local computer, created manually or programmatically during application installation, and explicitly not from Group Policy. Nothing Intune wrote appears there. An administrator who runs the cmdlet bare, sees no sign of their rules, and concludes the profile never arrived is the most common false diagnosis in this whole area.

The store you want is the ActiveStore, documented as the currently active policy and the sum of all policy stores that apply to the computer, including the resultant set of policy and the local stores. Checked on the Get-NetFirewallRule reference on 25 September 2026.

1# The rules traffic is actually evaluated against. Without -PolicyStore
2# ActiveStore this returns local static rules only, and nothing delivered
3# by Intune or Group Policy will appear in the output.
4Get-NetFirewallRule -PolicyStore ActiveStore |
5    Where-Object { $_.Enabled -eq "True" } |
6    Select-Object DisplayName, Direction, Action, Profile |
7    Sort-Object Direction, DisplayName

If the rules are present in the active store and the traffic still flows, the problem is the rule definition. If the profile reports success and the rules are absent, the atomic block failed and you are hunting one bad entry. Bisecting the profile is crude and it is also the fastest route: split it in half, assign both halves, and see which half survives.

The 150 rule ceiling, and what merging actually means

A Windows Firewall rules profile supports up to 150 custom rules. That is a per profile limit rather than a per device limit, and Microsoft’s documented answer to needing more than 150 is to use more than one profile, because non conflicting rules from separate profiles merge on the device into a combined configuration.

Merging is not the same as arbitrating. When two rules describe the same traffic with different configurations, both are sent to the device and both are applied, which is how an allow and a block for the same executable end up sitting in the active store together. Intune does not pick a winner and does not report the pair the way a settings catalog conflict is reported. Windows resolves it instead, and the Windows Firewall rules article, last updated 6 June 2025, sets out the order plainly: explicit allow rules beat the default block, explicit block rules beat any conflicting allow rule, and more specific rules beat less specific ones except where an explicit block is involved.

The practical consequence is that a single forgotten block rule in an unrelated profile will quietly defeat an allow rule you have just spent an afternoon writing, and nothing in the Intune reporting will connect the two. The same shape of problem, with better tooling, is covered in Intune security baseline conflicts, and it is worth reading alongside this because security baselines carry firewall settings of their own.

The failure modes

These are the ways Intune firewall rules fail in practice, in rough order of how often they turn up in public support threads. The first two account for most of them.

The January 2026 incident, and why the signature is worth knowing

In early January 2026 Microsoft ran a service incident, IT1214934, in which recently created or modified firewall rule policies were not enforced on Windows devices. The policy reported as applied while multiple rules sat on the device with the active flag false. The public record is thin, because service health messages are tenant scoped and never published on Learn. NHS Digital’s NHSmail service issued an advisory describing the symptom as firewall rule policies that admins have recently created or modified in Microsoft Intune not being enforced on Windows devices, and Patch My PC published an analysis attributing the behaviour to Intune temporarily treating rule names rather than generated identifiers as the rule identity, so that renames and reassignments produced delete and add sequences which left stale inactive rules behind.

I have not reproduced this and cannot: it was a service side defect, not a configuration one, and my tenant is a lab. I raise it because the signature is distinctive and it recurs. Rules physically present on the device, only the most recently modified one enabled, and a portal that insists everything is fine. If you see that shape, stop editing. Changing the profile again is the operation that caused it.

What I would do differently

Keep the profiles carrying your Intune firewall rules small. The 150 rule ceiling invites you to fill it and the atomic block behaviour punishes you for accepting the invitation. A profile of twenty rules that fails costs you twenty rules and bisects in a couple of passes. A profile of 150 costs the device everything it was relying on and bisects in eight. Group rules by purpose rather than by how many will fit. This is a judgement, and it sits against Microsoft’s own planning advice, which is to apply firewall policy to a device through a single policy where possible. That advice is aimed at conflicts between settings profiles; for rules profiles, which Microsoft documents as merging, I would still take a smaller blast radius over a tidier assignment list.

Never edit a live rules profile in place against a production assignment. Duplicate it, edit the copy, assign the copy to a pilot group, confirm the result in the ActiveStore on a real device, then swap the assignments. Renaming and reassigning is both the operation that broke in January 2026 and the operation where an unparseable value gets introduced, which makes it the one worth doing carefully.

Decide once whether Group Policy or Intune owns the firewall, then remove the loser. The Firewall CSP reference, last updated 15 May 2026, states the merge law for the global settings repeatedly: the Group Policy store value wins where it is configured, otherwise the local store value is used. A half migrated device will therefore accept your rules and ignore your defaults, which is the most confusing outcome available. The same sequencing argument applies to policy surfaces generally, which is the subject of settings catalog vs administrative templates.

Above all, check that the rules landed rather than that the policy reported. Forcing an Intune sync will not repair an atomic block failure, and a green tick in the Intune portal is a statement about delivery, not about enforcement.

Last verified: 25 September 2026