About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not lab validation. Check the stated versions and your own requirements before making changes.
Direct answer: Before any routine firewall or NSG change in a hosted estate, operators need a documented port baseline for each application (source, destination, protocol, direction, justification) and a bounded validation pass from the actual application context. The result covers only the tested flows and transactions, not every possible dependency. “We only removed an old rule” is a common cause of silent failure when that rule still carried integration traffic the spreadsheet forgot.
This is change verification for live operations, not rebuilding firewall policy after a ransomware restore (addressed in separate recovery articles).
Why it matters
Hosted stacks combine Windows host firewalls, hypervisor or cloud network security groups, perimeter firewalls, and partner IP allow lists. Application owners think in URLs; network teams think in ruleset tickets. A narrow deny or a lost “any to app subnet on 1433” rule breaks SQL-backed LOB features while ICMP ping to the web tier still works.
Keep evidence of controlled change, including the validation results, alongside the approval record (editorial recommendation). A port matrix tied to application names makes rollback and communication faster when verification fails.
How it works
Microsoft documents Windows Defender Firewall with Advanced Security as a stateful host firewall with inbound/outbound rules, profiles (domain/private/public), and rule merging with Group Policy. Cloud-hosted VMs add distributed ACLs (vendor NSG or security list concepts) evaluated before packets reach the guest OS—both layers must appear in the baseline.
A practical baseline row (editorial template):
| Application | From zone | Destination host/interface | Proto/port | Purpose | Owner |
|---|---|---|---|---|---|
| LOB API | app subnet | db-01 | TCP/1433 | SQL | DBA |
Review each independently initiated inbound or outbound connection and the effective policy at every layer. Windows Firewall allows outbound traffic by default unless blocked; an outbound default-deny deployment instead needs the appropriate explicit allows. Stateful return traffic is part of an established flow and does not inherently require a symmetric reverse allow rule. This is distinct from a peer initiating a new connection back.
Pre-change review: export current effective rules (host + cloud) and diff against baseline; flag removals not matched to a decommissioned dependency.
Post-change validation: test from the actual application host and runtime context. A jump host in the same subnet is not sufficient unless its source address/NIC, identity, effective policies and route are demonstrably equivalent and those limits are recorded. Open fresh connections: Azure NSG changes apply to new connections and can leave established flows uninterrupted. Pair transport checks with a bounded application transaction using synthetic data or a read-only operation; successful TCP connection alone does not establish TLS, authorisation or business success.
What to choose and why
Maintain the port matrix as a living dependency artefact updated when applications ship new integrations—the same ownership model as application DNS names.
Use time-bound change windows and reviewed rollback exports for rule sets. Record source/destination coverage, expected application results, untested flows and protocol-specific checks, including UDP where used. Define abort triggers such as a newly failing required fresh connection or controlled transaction; restore the approved prior rules and retest if a trigger is reached. Pair network change records with the application owner.
Separate perimeter publishing (load balancer VIP, RD Gateway) from east–west rules so a public hardening change does not strip internal worker traffic.
For Windows hosts, understand profile context: the same rule can apply differently on session hosts versus workers.
Risks and limits
Application-layer TLS or mTLS failures are invisible to port-open tests; follow with app health checks. UDP requirements (RDP UDP, some voice/video) are easy to omit from TCP-only matrices.
No firewall rule export or Test-NetConnection was executed here (untested). Vendor cloud consoles differ; steps are not universal.
Sources
Primary sources checked 14 November 2026. Procedures remain source-researched, not lab validated.
- Windows Firewall Overview | Microsoft Learn
- Configure Firewall Rules With Group Policy | Microsoft Learn
- Windows Firewall Rules | Microsoft Learn
- Azure network security groups overview | Microsoft Learn
- SP 800-41 Rev. 1, Guidelines on Firewalls and Firewall Policy | CSRC — abstract/background scope only
Related future topics
Load balancer health checks; outbound email dependency. VPC networking — related only.
Learning notes
- Port baselines are application artefacts, not only firewall team inventories.
- Cloud NSG and guest OS firewall both need to be in scope.
- Windows defaults to outbound allow unless blocked; default-deny policy needs explicit allows for required new flows.
- Fresh connections from the actual runtime context and bounded transactions provide evidence for tested paths only.
- Record untested dependencies and rollback triggers alongside successful checks.
This article was originally published on .