Configure Microsoft Entra for Zero Trust: Protect networks

The "Protect networks" pillar of the Secure Future Initiative emphasizes the critical importance of securing network access and implementing network-based controls to prevent unauthorized access to organizational resources. The best practices in this pillar focus on actions such as establishing network boundaries, controlling traffic flows, and implementing location-based access policies that verify the trustworthiness of network connections before granting access.

Zero Trust security recommendations

Named locations are configured

Without named locations configured in Microsoft Entra ID, threat actors can exploit the absence of location intelligence to conduct attacks without triggering location-based risk detections or security controls. When organizations fail to define named locations for trusted networks, branch offices, and known geographic regions, Microsoft Entra ID Protection can't assess location-based risk signals. Not having these policies in place can lead to increased false positives that create alert fatigue and potentially mask genuine threats. This configuration gap prevents the system from distinguishing between legitimate and illegitimate locations. For example, legitimate sign-ins from corporate networks and suspicious authentication attempts from high-risk locations (anonymous proxy networks, Tor exit nodes, or regions where the organization has no business presence). Threat actors can use this uncertainty to conduct credential stuffing attacks, password spray campaigns, and initial access attempts from malicious infrastructure without triggering location-based detections that would normally flag such activity as suspicious. Organizations can also lose the ability to implement adaptive security policies that could automatically apply stricter authentication requirements or block access entirely from untrusted geographic regions. Threat actors can maintain persistence and conduct lateral movement from any global location without encountering location-based security barriers, which should serve as an extra layer of defense against unauthorized access attempts.

Remediation action

Tenant restrictions v2 policy is configured

Tenant Restrictions v2 (TRv2) allows organizations to enforce policies that restrict access to specified Microsoft Entra tenants, preventing unauthorized exfiltration of corporate data to external tenants using local accounts. Without TRv2, threat actors can exploit this vulnerability, which leads to potential data exfiltration and compliance violations, followed by credential harvesting if those external tenants have weaker controls. Once credentials are obtained, threat actors can gain initial access to these external tenants. TRv2 provides the mechanism to prevent users from authenticating to unauthorized tenants. Otherwise, threat actors can move laterally, escalate privileges, and potentially exfiltrate sensitive data, all while appearing as legitimate user activity that bypasses traditional data loss prevention controls focused on internal tenant monitoring.

Implementing TRv2 enforces policies that restrict access to specified tenants, mitigating these risks by ensuring that authentication and data access are confined to authorized tenants only.

If this check passes, your tenant has a TRv2 policy configured but more steps are required to validate the scenario end-to-end.

Remediation action

External collaboration is governed by explicit cross-tenant access policies

When default outbound B2B collaboration settings allow all users to access all applications in any external Microsoft Entra organization, organizations can't control where corporate data flows or who employees collaborate with. Users might intentionally or accidentally upload sensitive data to external tenants, accept invitations from spoofed or malicious tenants designed for phishing, or grant OAuth consent to risky applications that compromise corporate data.

For regulated industries, unrestricted external collaboration might violate data residency requirements or prohibitions on sharing data with unapproved organizations.

By blocking default outbound B2B collaboration, organizations enforce a deny-by-default posture that restricts external relationships to vetted partners, protects intellectual property, and ensures visibility over every cross-tenant collaboration.

Remediation action

Outbound traffic from VNet integrated workloads is routed through Azure Firewall

Azure Firewall provides centralized inspection, logging, and enforcement for outbound network traffic. When you don't route outbound traffic from virtual network (VNet) integrated workloads through Azure Firewall, traffic can leave your environment without inspection or policy enforcement. VNet integrated workloads include virtual machines, AKS node pools, App Service with VNet integration, and Azure Functions in VNet.

Without routing outbound traffic through Azure Firewall:

  • Threat actors can use uninspected outbound paths for data exfiltration and command-and-control communication.
  • Organizations lose consistent enforcement of egress security controls such as threat intelligence filtering, intrusion detection and prevention, and TLS inspection.
  • Security teams lack visibility into outbound traffic patterns, which makes it difficult to detect and investigate suspicious network activity.

Remediation action

Threat intelligence is enabled in deny mode on Azure Firewall

Azure Firewall threat intelligence-based filtering alerts on and denies traffic to and from known malicious IP addresses, fully qualified domain names (FQDNs), and URLs sourced from the Microsoft Threat Intelligence feed. When you don't enable threat intelligence in Alert and deny mode, Azure Firewall doesn't actively block traffic to known malicious destinations.

If you don't enable threat intelligence in Alert and deny mode:

  • Threat actors can communicate with known malicious infrastructure, enabling data exfiltration and command-and-control communication without active blocking.
  • Organizations that use Alert only mode can see threat activity in logs but can't prevent connections to known bad destinations.
  • All firewall policy tiers remain exposed to threats that the Microsoft Threat Intelligence feed already identified.

Remediation action

IDPS inspection is enabled in deny mode on Azure Firewall

Azure Firewall Premium provides signature-based intrusion detection and prevention (IDPS) that identifies attacks by detecting specific patterns in network traffic, such as byte sequences and known malicious instruction sequences used by malware. IDPS applies to inbound, east-west (spoke-to-spoke), and outbound traffic across Layers 3-7. When IDPS isn't configured in Alert and deny mode, Azure Firewall only logs detected threats without blocking them.

Without IDPS enabled in Alert and deny mode:

  • Threat actors can send traffic that matches known attack signatures without being blocked.
  • Organizations running IDPS in Alert only mode gain visibility into threats but can't prevent intrusion attempts from reaching their workloads.
  • Lateral movement and exfiltration traffic that matches known attack signatures passes through the firewall without active intervention.

Remediation action

Application Gateway WAF is enabled in prevention mode

Azure Application Gateway Web Application Firewall (WAF) protects web applications from common exploits and vulnerabilities, including SQL injection, cross-site scripting, and other OWASP Top 10 threats. WAF operates in two modes: Detection and Prevention. Detection mode logs matched requests but doesn't block traffic, while Prevention mode actively blocks malicious requests before they reach the backend application. When WAF is in Detection mode, web applications remain exposed to exploitation even though threats are being identified.

Without WAF in Prevention mode:

  • Threat actors can exploit web application vulnerabilities such as SQL injection and cross-site scripting, because matched requests are only logged, not blocked.
  • Organizations lose the active protection that managed and custom WAF rules provide, which reduces WAF to an observability tool rather than a security control.

Remediation action

Azure Front Door WAF is enabled in prevention mode

Azure Front Door Web Application Firewall (WAF) protects web applications from common exploits and vulnerabilities, including SQL injection, cross-site scripting, and other OWASP Top 10 threats. WAF operates in two modes: Detection and Prevention. Detection mode evaluates and logs requests that match WAF rules but doesn't block traffic, while Prevention mode actively blocks malicious requests before they reach the backend application. When WAF is in Detection mode, web applications remain exposed to exploitation even though threats are being identified.

Without WAF in Prevention mode:

  • Threat actors can exploit web application vulnerabilities because matched requests are only logged, not blocked.
  • Organizations lose active protection at the global edge that managed and custom WAF rules provide, which reduces WAF to an observation tool rather than a security control.

Remediation action

  • Last updated on