Windows Firewall is one of those controls everyone assumes is on and nobody looks at. In the tenants I review, the most common situation is a firewall that is technically enabled but riddled with local allow rules added by installers, technicians and old software. A proper Intune firewall policy fixes that by making the firewall state and rule set something you manage centrally, not something each laptop decides for itself.
This article covers the two parts of an Intune firewall policy, the settings I configure for most small and mid-sized businesses, the rules worth adding, and the rules that should never exist.
Why the firewall still matters on cloud-first devices
It is tempting to think the firewall matters less once everyone works from home and your apps live in Microsoft 365. The opposite is true. Laptops now sit on hotel Wi-Fi, home networks with smart TVs, and coffee shop networks full of strangers. The firewall is what stops another device on that network from reaching file shares, remote desktop or a vulnerable service on your laptop.
Inside the office, the firewall limits lateral movement. If one machine is compromised, a tight inbound policy makes it much harder for an attacker to jump from laptop to laptop using remote management protocols.
The two parts of an Intune firewall policy
In the Intune admin center, firewall policy lives under Endpoint security > Firewall. For Windows there are two profile types that do different jobs:
Profile
What it controls
How conflicts behave
Windows Firewall
Global state: firewall on or off per network type, default inbound and outbound actions, local rule merging, logging.
If two policies set the same setting to different values, the setting is not applied. Use one policy per device.
Windows Firewall Rules
Individual allow and block rules for apps, ports and addresses.
Non-conflicting rules from multiple profiles merge on the device. Each profile holds up to 150 rules.
The key point is to keep exactly one Windows Firewall settings profile per device, and also not to configure the same settings in a security baseline or an old device configuration profile. Duplicate settings are the most common reason firewall policies show errors.
The settings profile I start with
Create a policy under Endpoint security > Firewall > Create Policy, platform Windows, profile Windows Firewall. For each of the domain, private and public network types:
Turn on Windows Firewall: Yes.
Block inbound connections (default inbound action): Yes. Anything not explicitly allowed is blocked.
Block outbound connections (default outbound action): No, for most businesses. Default-deny outbound is powerful but needs a mature rule set and constant upkeep.
Disable inbound notifications: Yes. Users should not be asked whether to allow an app through the firewall. That prompt is how local rules pile up.
For the public profile I go further and set the local rule merge options to ignore local rules:
This means that on public networks only the rules you push from Intune apply. Whatever an installer added locally is ignored. Once you are confident in your managed rule set, you can extend the same approach to the private and domain profiles.
Turn on firewall logging for dropped packets at least on a pilot group. It is the fastest way to find out what a rule change broke.
Rules you need
For a typical cloud-managed Windows fleet, the list of inbound rules you actually need is short. Most outbound traffic is already allowed by default. Rules worth considering:
Remote support tools your help desk uses, scoped to the specific program path rather than a port range.
Line-of-business apps that listen for connections, such as a lab instrument interface or a scanning app, scoped to the program and, where possible, to the local subnet or specific remote IPs.
Remote Desktop, only if you genuinely use it, and only from a management subnet or VPN range. Never from any address.
File and printer sharing on the domain profile only, if devices still need to share locally.
Write rules around the program path wherever possible. A program-based rule allows that app to listen and nothing else. A port-based rule allows anything that binds to that port. Intune also lets you define reusable groups of remote IP addresses, which keeps rules readable when several apps need the same management subnet.
Rules you do not need
When I audit firewall rule sets, these are the ones that come out:
Allow all inbound on any profile. Usually added during troubleshooting and never removed.
Remote Desktop (TCP 3389) open to any address. One of the most abused entry points there is.
File and printer sharing on the public profile. There is no reason for a laptop at an airport to accept SMB connections.
Broad port ranges like 1024-65535 inbound, often from an old vendor instruction.
Rules for software that is no longer installed. Harmless until something else uses the same path or port.
Duplicate rules that differ only by name, which make the rule set impossible to reason about.
If you are not sure whether a rule is used, set the firewall to log dropped packets on a pilot group, remove the rule there, and watch for a week.
A rollout plan that avoids surprises
Inventory. Export the current local rules from a few representative devices to see what you are dealing with.
Build the managed rule set in a Windows Firewall Rules profile, using program paths and scoped addresses.
Deploy the settings profile to a pilot group, with local rules ignored on public networks only.
Watch logs and tickets for a week. Add rules for anything legitimate that broke.
Roll out to everyone, then consider ignoring local rules on the private and domain profiles too.
Review quarterly. Remove rules for retired apps.
Avoid shielded mode in general policy. It blocks all inbound traffic, including rules you allowed, and is better kept as an incident response action.
Firewall policy is one layer of a hardened Windows build. Our endpoint security baseline service covers it alongside Defender, ASR and account protection, and an Intune health check will find conflicting firewall profiles and leftover local rules. If you are still deploying Intune, start with our Intune deployment service.
Should I block outbound connections in my Intune firewall policy?
Not as a default for most small and mid-sized businesses. Default-deny outbound needs a complete, maintained list of every app’s network needs. Blocking inbound by default and controlling outbound through Defender network protection is a better balance.
How many firewall rules can one Intune profile hold?
Each Windows Firewall Rules profile supports up to 150 rules. Rules from multiple profiles merge on the device as long as they do not conflict, so you can split rules into logical groups.
What happens to firewall rules that users or installers added locally?
By default they still apply. If you set the policy to ignore local firewall rules for a network profile, only the rules you deploy from Intune are enforced on that profile.
Want to know how many open inbound rules are sitting on your laptops right now? Book a free Microsoft 365 security assessment and we will review your device firewall posture as part of it.
Windows Firewall is one of those controls everyone assumes is on and nobody looks at. In the tenants I review, the most common situation is a firewall that is technically enabled but riddled with local allow rules added by installers, technicians and old software. A proper Intune firewall policy fixes that by making the firewall state and rule set something you manage centrally, not something each laptop decides for itself.
This article covers the two parts of an Intune firewall policy, the settings I configure for most small and mid-sized businesses, the rules worth adding, and the rules that should never exist.
Why the firewall still matters on cloud-first devices
It is tempting to think the firewall matters less once everyone works from home and your apps live in Microsoft 365. The opposite is true. Laptops now sit on hotel Wi-Fi, home networks with smart TVs, and coffee shop networks full of strangers. The firewall is what stops another device on that network from reaching file shares, remote desktop or a vulnerable service on your laptop.
Inside the office, the firewall limits lateral movement. If one machine is compromised, a tight inbound policy makes it much harder for an attacker to jump from laptop to laptop using remote management protocols.
The two parts of an Intune firewall policy
In the Intune admin center, firewall policy lives under
Endpoint security > Firewall. For Windows there are two profile types that do different jobs:The key point is to keep exactly one Windows Firewall settings profile per device, and also not to configure the same settings in a security baseline or an old device configuration profile. Duplicate settings are the most common reason firewall policies show errors.
The settings profile I start with
Create a policy under
Endpoint security > Firewall > Create Policy, platform Windows, profile Windows Firewall. For each of the domain, private and public network types:For the public profile I go further and set the local rule merge options to ignore local rules:
This means that on public networks only the rules you push from Intune apply. Whatever an installer added locally is ignored. Once you are confident in your managed rule set, you can extend the same approach to the private and domain profiles.
Turn on firewall logging for dropped packets at least on a pilot group. It is the fastest way to find out what a rule change broke.
Rules you need
For a typical cloud-managed Windows fleet, the list of inbound rules you actually need is short. Most outbound traffic is already allowed by default. Rules worth considering:
Write rules around the program path wherever possible. A program-based rule allows that app to listen and nothing else. A port-based rule allows anything that binds to that port. Intune also lets you define reusable groups of remote IP addresses, which keeps rules readable when several apps need the same management subnet.
Rules you do not need
When I audit firewall rule sets, these are the ones that come out:
If you are not sure whether a rule is used, set the firewall to log dropped packets on a pilot group, remove the rule there, and watch for a week.
A rollout plan that avoids surprises
Avoid shielded mode in general policy. It blocks all inbound traffic, including rules you allowed, and is better kept as an incident response action.
Firewall policy is one layer of a hardened Windows build. Our endpoint security baseline service covers it alongside Defender, ASR and account protection, and an Intune health check will find conflicting firewall profiles and leftover local rules. If you are still deploying Intune, start with our Intune deployment service.
Microsoft’s reference on conflicts and rule merging is here: Firewall policy for endpoint security in Intune.
Frequently asked questions
Should I block outbound connections in my Intune firewall policy?
Not as a default for most small and mid-sized businesses. Default-deny outbound needs a complete, maintained list of every app’s network needs. Blocking inbound by default and controlling outbound through Defender network protection is a better balance.
How many firewall rules can one Intune profile hold?
Each Windows Firewall Rules profile supports up to 150 rules. Rules from multiple profiles merge on the device as long as they do not conflict, so you can split rules into logical groups.
What happens to firewall rules that users or installers added locally?
By default they still apply. If you set the policy to ignore local firewall rules for a network profile, only the rules you deploy from Intune are enforced on that profile.
Want to know how many open inbound rules are sitting on your laptops right now? Book a free Microsoft 365 security assessment and we will review your device firewall posture as part of it.