Direct answer
Review each Windows Firewall profile and its effective policy, then compare the result with the device's network context and approved baseline. An enabled profile is a starting point, not proof that every inbound rule is appropriately restricted.
Identify the profiles and network context
Windows Firewall has Domain, Private and Public profiles. The active network category matters: a laptop can move from an office network to a public hotspot, so a single profile's state does not describe every situation.
Record the device, assessment time, network context and expected policy. On a managed device, ask the administrator which management system owns the policy before making changes.
Reference: Microsoft: Windows Firewall profiles.
Inspect the effective profile settings
In PowerShell, run Get-NetFirewallProfile -PolicyStore ActiveStore and review the Name, Enabled, DefaultInboundAction and DefaultOutboundAction values. ActiveStore represents effective policy; the default query uses the persistent store, so the two can differ.
A report that says a profile is off identifies a condition to investigate. Confirm the result locally and check whether the disabled profile is expected under the organization's approved configuration.
- Record all three profile states, including a profile not currently in use.
- Compare with the approved baseline and the active network category.
- Treat missing or inaccessible data as unknown, not as an enabled firewall.
Reference: Microsoft: Get-NetFirewallProfile.
Review the exception, not just the switch
An enabled profile can still allow a service through an inbound rule. Review the rule's program or port, protocol, profiles and remote address scope alongside the service's business need. A broad rule on a public network may need a narrower scope even when the firewall is on.
Test access from an authorized network location and retain the expected allowed case as well as the denied case. Changes to remote access rules can interrupt administration, so agree a recovery route before changing managed systems.
Restore and retest
If an off profile is unintended, correct the owning policy or use the approved local management procedure. Microsoft documents Set-NetFirewallProfile for local configuration; do not assume a local change will persist if management policy overrides it.
After the change, inspect ActiveStore again and test the required connection from the intended network. Record the applied rule, evidence and any exception owner.
Reference: Microsoft: Manage Windows Firewall with the command line.
Assessment limits
A point-in-time scan does not prove network reachability or inspect every effective firewall rule. Permissions, third-party firewall software and management policies can affect visibility and the appropriate fix.
Frequently asked questions
Does an enabled firewall profile mean a port is unreachable?
No. An applicable allow rule, network location and service binding can still permit access. Check effective rules and test reachability from an authorized location.
Why might a local setting differ from the active policy?
The active policy combines applicable policy sources, while the default profile query reads the persistent store. Group Policy or other management can change the effective result.
Should every inbound rule be removed?
No. Some services need inbound access. Keep approved access as narrow as practical and verify required workflows after changing a rule.
Primary sources and further reading
These guides combine published security guidance with practical assessment planning. Adapt checks to the owner's policy, environment, and authorized scope.
This guide was prepared with AI assistance using the linked sources and illustrative examples. Check current vendor guidance and your environment before making changes.