Azure Default Outbound Access Retirement: Explicit Egress for New Virtual Networks

Azure virtual machines have long reached the internet through a Microsoft-owned public IP that nobody configured, nobody owns and nobody can filter, and Microsoft has now ended that default for new virtual networks. From the Azure API released after 31 March 2026, new virtual networks use private subnets by default, so a VM in them has no internet path until you build one. Existing networks keep working, which is exactly why many estates now run two egress models side by side. This guide gives the official status, who is affected, how to find VMs still using default outbound access, how to choose between NAT Gateway, load balancer outbound rules, public IPs and Azure Firewall, and how to switch subnets to private without breaking Windows activation or patching. It is for Azure network, platform and cloud security teams. For wider virtual network design, see the Azure Virtual Network Security Guide.

This is an independent guide from NHI Mgmt Group, based on Microsoft's public documentation as of November 2026. It is not sponsored or reviewed by Microsoft. Product features change, so confirm settings against Microsoft's current documentation.

Key takeaways

• New networks are private by default. Microsoft Learn states that for the API released after 31 March 2026, new virtual networks default to private subnets (defaultOutboundAccess set to false), and the Azure portal already creates private subnets.
• Existing networks are unchanged, not safe. Microsoft states existing VNets are not changed and both existing and new VMs in them can still receive default outbound IPs, an implicit internet path that conflicts with Zero Trust.
• Old templates keep the old behaviour. ARM templates on earlier API versions continue to set defaultOutboundAccess to null, which implicitly allows outbound access, so infrastructure as code needs an explicit value.
• NAT Gateway is Microsoft's default answer. Learn calls a NAT gateway the recommended method for most scenarios; Azure Firewall or a network virtual appliance behind a UDR is the choice when you must inspect and filter egress.
• Private subnets break things you forgot depended on the internet. Windows Activation, Windows Update and UDRs with next hop Internet fail without an explicit egress method, so build egress first and flip the subnet second.

What is changing and why

When a VM is deployed in a virtual network with no explicit outbound method, Azure assigns it an outbound public IP, the default outbound access IP. Microsoft's documentation states this IP "is owned by Microsoft and can change without notice." The change is controlled by a subnet property, defaultOutboundAccess. When it is false the subnet is a private subnet and VMs in it get no default outbound IP.

Microsoft gives three reasons for disabling default outbound access: security (default internet access contradicts Zero Trust principles), clarity (explicit connectivity is preferred to implicit access) and stability (the IP is not customer-owned and can change, and service updates may affect default outbound behaviour). Learn also lists configurations that do not work well with it: multiple NICs can produce inconsistent outbound IPs, scaling VM Scale Sets changes outbound IPs, IPs are not contiguous across scale set instances, and default outbound IPs support neither fragmented packets nor ICMP ping.

Official timeline and current status

As checked on 8 November 2026 on Microsoft Learn (page last updated 10 September 2026) and the Microsoft Tech Community post by a Microsoft engineer that tracked the change:

Microsoft Learn points to the Azure Updates retirement notice for the latest timeline; that page did not render its content when we checked. The matching Azure update, AZ515484 published 12 December 2025 (read via the mc.merill.net mirror of Microsoft's update feed, a secondary copy), states the retirement date was extended from 30 September 2025 to 31 March 2026, that from that date newly created VNets default to private subnets, and that default outbound access "will be disabled by default, but not removed". "Retirement" here means the default changed for new networks; Microsoft has not announced removal of default outbound IPs from existing networks. Watch Azure Service Health and Learn for any later change.

Who and what is affected

• New VNets from current tooling: created through the portal or the post-March 2026 API. VMs there cannot reach public endpoints, including Microsoft public endpoints, until an explicit method exists.
• Pipelines on old API versions: templates, Bicep or Terraform pinned to older API versions keep creating subnets with null, so new environments silently keep implicit egress. Set defaultOutboundAccess explicitly in code.
• VM Scale Sets in Flexible orchestration mode: Learn states instances created this way never receive a default outbound IP, so they always need an explicit method.
• Load balancer backends configured by IP address: Learn notes a known issue where such backends use default outbound access.
• UDR designs with next hop Internet: for example a 0.0.0.0/0 route to an NVA plus service tag routes with next hop Internet to bypass it. Learn states these break in a private subnet unless the source has an explicit outbound method. Service endpoints are not affected.
• Not applicable: Learn states private subnets do not apply to delegated or managed subnets that host PaaS services. VMs in a private subnet can still reach Azure Storage accounts in the same region.

Finding affected systems and identities

1. Azure Advisor: in Operational Excellence, look for "Add explicit outbound method to disable default outbound" and the Virtual Machine Scale Sets variant. Each lists the NICs of VMs or instances with default outbound enabled.
2. Subnet sweep: query every subnet across subscriptions (for example with Azure Resource Graph) and list those where defaultOutboundAccess is not false and that have no NAT gateway association. These subnets still hand out default outbound IPs.
3. NIC sweep: list NICs where defaultOutboundConnectivityEnabled is true and join them to their VM, subnet and owner tags.
4. Template sweep: search infrastructure as code repositories for Microsoft.Network/virtualNetworks API versions and subnets that omit defaultOutboundAccess.
5. Dependency discovery: before changing anything, capture what each VM actually connects to (NSG or VNet flow logs, firewall logs, application owners) so the explicit path allows what is needed and nothing more.

Microsoft explains a common confusion: a VM with an explicit method can still show the Advisor alert because a default IP remains assigned in a non-private subnet. That IP is not used for egress unless the explicit method is removed, but it remains a fallback until the subnet is private and the VM has been stopped and deallocated.

The identity angle: VMs, scale sets and their managed identities or service principals call Entra ID, Key Vault, package registries and third-party APIs. An unowned, changing egress IP makes it impossible to allow-list workload traffic at those destinations or to tie a call to a known network location. A stable, owned egress IP (NAT gateway or firewall) lets partners and your own SaaS tenants restrict API keys and workload identities to known addresses. See the Azure Managed Identities Security Guide.

Migration options

Combinations are common: a NAT gateway on the firewall's own subnet provides scalable, static IPs for the firewall's egress. Learn's NAT gateway overview states a NAT gateway takes precedence over load balancer outbound rules, instance-level public IPs and Azure Firewall for new connections on that subnet, so check routing intent before adding one to a subnet whose traffic should pass through a firewall. The Standard SKU NAT gateway is zonal or no zone; StandardV2 is zone redundant, supports IPv6 and flow logs, and cannot be reached by upgrading a Standard gateway.

Decision guidance: a small environment with a few VMs and no inspection requirement should put a NAT gateway on each workload subnet and make the subnets private. A larger or regulated estate should route all spoke egress to a central Azure Firewall or NVA, give that hub a NAT gateway, and use NSGs as the second layer. In both cases treat a NIC public IP as an exception needing approval. See the Cloud Egress Filtering guide.

Testing and rollback

1. Build the explicit path first: Microsoft's guidance for an existing non-private subnet is to plan and configure explicit outbound connectivity before changing the subnet to private.
2. Verify on a pilot subnet: confirm DNS, Windows Activation, Windows Update or Linux package mirrors, monitoring agents, backup agents and any third-party API calls succeed through the new path, and that the source IP seen externally is your owned IP.
3. Set the subnet private: portal, Virtual networks, Subnets, set Default outbound access to Disabled, or set defaultOutboundAccess to false in code.
4. Stop and deallocate: Learn states the change applies per VM only after a stop and deallocate. Schedule this in a maintenance window; a simple restart is not enough.
5. Confirm closure: the Advisor recommendation should clear for those NICs. Re-run the NIC sweep.
6. Rollback: per Learn, to return a VM to default outbound access you make the subnet non-private again and stop and deallocate the VM. Prefer fixing the explicit path instead; rolling back reintroduces the implicit IP.

Risks of doing nothing

• Uncontrolled egress: any process on a VM, including malware, can reach the internet from an IP you cannot filter or log at the edge, which eases exfiltration (ATT&CK T1048 Exfiltration Over Alternative Protocol) and command and control.
• Unexpected outages: the default IP can change without notice, breaking partner allow lists, and new VNets built by current tooling have no internet path at all.
• Configuration drift: old templates keep creating implicit egress, so the estate never converges and audits find two network models.
• Reduced workload identity controls: without owned egress IPs, network-based restrictions on API keys, storage firewalls and workload identities cannot be applied.
• Troubleshooting blind spots: no ICMP, no fragmented packets and changing IPs on scale sets make incidents slower to diagnose.

Framework mapping

Practitioner checklist

• Export Azure Advisor default outbound recommendations for every subscription and assign owners.
• Sweep subnets for defaultOutboundAccess not false and NICs with defaultOutboundConnectivityEnabled true.
• Set defaultOutboundAccess explicitly in every template and pin current API versions.
• Choose an egress pattern per landing zone: NAT gateway for simple egress, Azure Firewall or NVA for filtered egress.
• Review UDRs with next hop Internet and replace bypass routes before making subnets private.
• Test activation, patching, monitoring and backup agents on a pilot subnet first.
• Make subnets private, then stop and deallocate VMs in a maintenance window.
• Register owned egress IPs with partners and use them to restrict workload API access.

Standards and references

• Microsoft Learn: Default outbound access in Azure
• Microsoft Tech Community: default outbound access retirement for Azure VMs
• Microsoft Learn: What is Azure NAT Gateway?
• NIST: SP 800-207 Zero Trust Architecture
• NIST: SP 800-53 Rev 5 Security and Privacy Controls
• NIST: Cybersecurity Framework 2.0

Related NHI Mgmt Group resources: Azure Virtual Network Security Guide · Cloud Egress Filtering · Microsoft Azure Security Guide · Azure Policy and Management Groups Guide