Defender Firewall and CSPM Security Profiles: One Policy Language for Every Endpoint
Merge GPO-era firewall sprawl into Intune profiles and Defender CSPM security profiles — with precedence rules you can actually explain to auditors.
C
CloudEngineerHub Team
Published: September 9, 2026· Last Updated: September 28, 2026·9 min read
Defender Firewall and CSPM Security Profiles: One Policy Language for Every Endpoint
Host firewall policy is where GPO-era thinking goes to die: dozens of policies, rules nobody can attribute, and "temporary" exceptions from 2019 still shipping to every laptop. Modern estates have a better set of options — Intune endpoint security firewall profiles for enrolled clients, and Defender security profiles (delivered through Defender for Endpoint's security configuration management, the cloud policy service some Microsoft documentation labels CSPM) for the devices Intune can't reach. Get the precedence model and the merge behavior right, and one policy language covers servers, workstations, and everything in between.
Visual Walkthrough
C
CloudEngineerHub Team
Author
The CloudEngineerHub editorial team — Microsoft endpoint management and cloud engineers writing hands-on guides on Intune, Azure, Entra ID, Autopilot, Defender and PowerShell. Every article is reviewed against current Microsoft documentation.
Defender Firewall via Intune — Rules That Ship Safely. 1. Baseline firewall policy: Domain/private/public profiles on, inbound default block. — 2. Rules authored per app: Program path/port/protocol scoped to the right profile. — 3. Assign with monitoring: Pilot group first; CSP writes rules to the stack. — 4. Traffic evaluated: Windows Filtering Platform enforces at kernel level. — 5. Logs collected: Firewall event log + Log Analytics prove behavior. — 6. Fleet-wide release: Broad rollout after pilot metrics stay clean.
Prerequisites
Intune: Endpoint Security Manager role; the firewall node requires Intune licensing for the managed devices (part of the standard Intune/EMS suites).
Defender security profiles: devices must be onboarded to Microsoft Defender for Endpoint (Plan 2 is the norm for security configuration management); the Defender portal's Configuration management blade is the control plane.
Entra roles: Intune Administrator or Endpoint Security Manager for Intune-side work; Security Administrator for the Defender portal side.
A firewall rule inventory from every GPO currently touching hosts — see the migration section before you write a single new profile.
Windows 10/11 (FirewallPolicy CSP) and Windows Server 2012 R2+ for Defender-managed servers.
Where firewall policy lives now
Three stores, three authorities, one host firewall. Knowing which wins is the whole game:
Store
Control plane
Typical devices
Authority when both apply
Group Policy
GPMC / domain
Domain-joined legacy estate
GPO wins where MDM doesn't conflict-loop
Intune endpoint security
Intune admin center
Enrolled Windows clients
Intune policy is authoritative for enrolled devices
Fills gaps; Intune wins for settings Intune manages
The design principle: pick one primary authority per device population. Clients enrolled in Intune get firewall from Intune. Servers that will never enroll get Defender security profiles. GPO firewall policies get scheduled for retirement, not left to "also apply."
Intune firewall profiles that actually matter
The base profile
Under Endpoint security > Firewall, the Windows Firewall profile configures the three network profiles (Domain, Private, Public): firewall on/off, inbound and outbound default actions, notifications, unicast responses, and — critically — rule merging (whether locally created rules apply). It rides the FirewallPolicy configuration service provider, so everything here is MDM-native and works on fully cloud-managed devices.
Set defaults like a firewall engineer: inbound default-deny on all three profiles, outbound default-allow unless your compliance regime says otherwise, and rule merging explicitly decided rather than inherited from whatever the GPO said in 2016.
Windows Firewall Rules profiles
The Windows Firewall Rules profile creates individual rules: program or port, local/remote addresses, protocol, profile types, interface types, and allow/block. This is where the GPO estate's per-app rules come to be reborn. Two operational notes:
Scope rules to device groups deliberately; a rule that ships to every device "because the GPO did" is how portfolios rot.
Name rules with a convention (APP-Team-Service-Direction) — the name is what everyone greps for during the next incident.
Rule merge and the conflicts that generate tickets
Windows evaluates firewall settings with block-beats-allow precedence, and multiple policy sources merge unless you disable merging. The classic ticket: an application works on a tester's machine and dies in production — because a second policy source (a leftover GPO, another Intune profile) ships a block rule that shadows your allow rule. Intune surfaces conflicts in policy and device reports; use them, and audit for shadowed rules on pilot devices with:
If AllowLocalFirewallRules is False, locally created rules are ignored — which is usually what you want on managed clients, and exactly what surprises the admin who just added a local rule to "quickly test something."
Defender security profiles (CSPM): firewall for the unmanaged edge
The Defender portal's security configuration management (security profiles, built on the cloud policy service — the "CSPM" in some Microsoft and community references) lets Defender deliver security configuration — including Microsoft Defender Firewall and Firewall Rules profiles — to devices that Intune doesn't manage: Windows servers, endpoints onboarded for Defender-only scenarios, and Arc-connected machines. It's also where the Defender security baseline can be managed as profiles, giving servers a baseline without ever enrolling them in MDM.
Enforcement scope and the MDE-SecurityConfiguration tag
In Defender portal > Endpoints > Configuration management, the enforcement scope decides who receives profiles:
Intune-enrolled devices — toggle on only if you intend Defender profiles to complement Intune there.
Devices tagged MDE-SecurityConfiguration — onboard servers and non-Intune endpoints with security settings management enabled; the tag is the membership test for the Defender policy channel.
That tag is your blast-radius control. Start with a pilot tag on a test OU's servers, verify profile delivery in the device's configuration view, and only then tag production server groups.
Who wins: Intune versus Defender precedence
When a device is touched by both — say a co-managed client that's also tagged — Intune is the authority for settings Intune manages: Defender security profiles do not override Intune-applied values, they apply where Intune leaves a gap. Document this in the runbook, because it's the question every auditor and every confused server owner will ask. The practical corollary: never define the same firewall setting in both channels for the same population; pick a channel per device type and keep the other one out.
Field note: Servers are where Defender security profiles earn their keep, but servers are also where a bad firewall rule has the largest blast radius. A blocked management port on 400 servers doesn't roll back like a laptop policy — pilot the tag, verify remotely-accessible recovery paths ( Bastion/serial console), and stage server fleets by application, not by the alphabet.
Visual Walkthrough
Every security control on this site maps to one of these five layers.
Layered StackDefense in Depth — Five Aligned Layers6/6
Firewall rules, tunnel, private endpoints segment the path.
layer 4
5
Data
DLP, sensitivity labels, immutable storage protect the crown.
layer 5
6
Assume breach
Each layer assumes the previous one failed — detection everywhere.
posture
Each layer assumes the previous one failed — depth is the strategy.
Defense in Depth — Five Aligned Layers. 1. Identity: Phishing-resistant MFA, PIM, conditional access gate everything. — 2. Endpoint: Compliance, EDR sensors, ASR, WDAC, encryption at the device. — 3. Application: Safe Links, app control, least-privilege app consents. — 4. Network: Firewall rules, tunnel, private endpoints segment the path. — 5. Data: DLP, sensitivity labels, immutable storage protect the crown. — 6. Assume breach: Each layer assumes the previous one failed — detection everywhere.
Migrating GPO firewall rules
The migration has three honest steps:
Inventory from the GPO itself. From a machine (or PS session) with the GPO applied, enumerate the rules with their source store so you know what you're porting:
PowerShell
1
2
3
4
5
6
7
8
9
10
# Rules living in a domain GPO (run from a GPO-applied host, or target the GPO store)
Get-NetFirewallRule -PolicyStore'contoso.com\FW-Servers-Standard' |
ForEach-Object {
$app = ($_ | Get-NetFirewallApplicationFilter).Program
$port = ($_ | Get-NetFirewallPortFilter) | Select-Object Protocol, LocalPort
[pscustomobject]@{
Name = $_.DisplayName; Action = $_.Action; Enabled = $_.Enabled
Program = $app; Protocol = $port.Protocol; LocalPort = $port.LocalPort
}
} | Export-Csv .\gpo-firewall-rules.csv -NoTypeInformation
Triage hard. Expect to delete 40–60%: rules for decommissioned apps, duplicates, allow-any rules that exist only because someone got tired. Migration is the cheapest cleanup you will ever run.
Rebuild into the target channel — Intune Windows Firewall Rules profiles for clients, Defender Microsoft Defender Firewall Rules security profiles for servers. Group Policy Analytics in the Intune admin center can assess your exported GPOs for MDM support and help generate configuration profiles; treat its output as a draft, not gospel, and reconcile against your triaged CSV.
Cut over per GPO: deploy the replacement profiles to the same population, verify, then unlink the GPO firewall node — not before. A week of both applying is fine (block wins, merging holds); a GPO silently reintroduced after cleanup is how you re-import the rot.
Monitoring and proving it works
Three surfaces keep the whole stack honest:
Intune's Windows Firewall report (Endpoint security > Firewall) shows per-device firewall state and configuration freshness for MDM-managed clients — make it a weekly glance.
Defender device pages show configuration profile status and firewall posture for security-profile-managed devices, including servers.
Advanced hunting catches actual traffic behavior, which is the point of all this:
KQL
1
2
3
4
5
6
// Top blocked inbound connections by rule — GPO/MDM applied
DeviceNetworkEvents
| where Timestamp > ago(7d) and ActionType == "FirewallInboundConnectionBlocked"
| summarize Blocks = count(), Devices = dcount(DeviceId)
by RemotePort, LocalPort
| order by Blocks desc
Pair that with the host event log (Microsoft-Windows-Windows Firewall With Advanced Security/Firewall, plus the Security log's 5152/5157 drop events where auditing is enabled) when a rule change needs attribution. The KQL rollup answers "is the new server policy blocking anything the app teams care about?" before they find out via a P1.
Key takeaways
One primary authority per device population: Intune for enrolled clients, Defender security profiles for servers and non-Intune endpoints, GPO scheduled for deletion.
Intune's base firewall profile sets profile-level defaults (including rule merging); Rules profiles carry the per-app and per-port rules that replace the GPO estate.
Block beats allow, and merge settings decide whether local rules count — most "works on my machine" firewall tickets are shadowed rules from a second policy source.
Defender security profiles (CSPM) deliver firewall policy to devices tagged MDE-SecurityConfiguration; the tag is your pilot and blast-radius control.
When both Intune and Defender manage a device, Intune wins for the settings it manages — never define the same setting in both channels for one population.
Migrate GPO rules by exporting, triaging aggressively, and rebuilding in the target channel before unlinking the GPO; Group Policy Analytics drafts, you verify.
Monitor with the Intune firewall report, Defender device configuration pages, and advanced hunting on firewall block events — posture reports plus real traffic beats either alone.
Frequently asked questions
Do Defender security profiles replace Intune for firewall management?
No — they complement it. Intune remains the authority for enrolled clients; Defender security profiles shine for servers and devices you won't or can't enroll. The precedence rule (Intune wins where it manages a setting) keeps the two channels from fighting when a device sits in both worlds.
Why did an application break right after we moved firewall rules to Intune?
Look for a second policy source first: a still-linked GPO shipping a shadowing block rule, a duplicate setting across two Intune profiles, or rule merging turned off so local exceptions stopped applying. The device's policy conflict report plus Get-NetFirewallRule -PolicyStore ActiveStore on the affected host usually names the culprit in minutes.
Can we manage servers through Intune instead of Defender security profiles?
You can enroll servers in Intune (MDM on Windows Server is supported in recent versions), but many server teams won't accept an MDM agent on production boxes. Defender security profiles exist precisely for that reality — configuration through the already-present Defender sensor, no MDM enrollment, staged via the security-configuration tag.
Comments
0No comments yet — be the first to share your thoughts.