Azure Virtual Network Security: NSGs and Private Endpoints

Most Azure network exposure comes from a small set of design gaps: subnets with no deny-by-default boundary, PaaS services that still accept public traffic after a private endpoint is added, and outbound internet access nobody chose. This guide covers Azure Virtual Network (VNet) security in depth: network security groups (NSGs), application security groups (ASGs), Azure Virtual Network Manager security admin rules, private endpoints, service endpoints, private DNS, outbound control and flow logging. It is written for cloud platform engineers, Azure architects and security reviewers who already know the basics. For the cross-cloud picture, see the Cloud Network Security Guide; this page goes deeper on Azure only.

Key takeaways

NSGs are the baseline, not the boundary. Default rules allow all traffic inside the VirtualNetwork tag and all outbound internet, so a subnet with only default rules is flat. Add explicit deny rules above priority 65000.
A private endpoint does not close the public door. Microsoft states that private endpoints do not restrict public access on their own; set Public network access to Disabled on the target resource as well.
Private DNS is where private endpoints break. Clients must resolve the normal service name to the private IP through a linked privatelink zone, or traffic silently goes to the public endpoint or fails.
Central guardrails belong in Virtual Network Manager. Security admin rules are evaluated before NSGs, so a Deny on ports such as 22, 3389 and 445 holds even when an application team opens them in an NSG.
Plan the flow log migration now. NSG flow logs can no longer be created and retire on 30 September 2027; virtual network flow logs are the replacement and also record encryption status.

How identity and access work in Azure Virtual Network

A VNet has no user sign-in of its own. Access to change it is governed by Azure RBAC on the Azure Resource Manager control plane, and access to services through it is governed by a mix of network rules and the target service's own authentication. Keep the two layers separate in your design: network position should reduce exposure, never replace authentication.

The building blocks

Control	Scope	What it enforces	Key facts
Network security group (NSG)	Subnet or network interface	Stateful allow and deny on the five-tuple	Custom priorities 100 to 4096, first match wins; default rules at 65000, 65001 and 65500 cannot be deleted; rule changes apply only to new connections
Application security group (ASG)	Group of NICs	Rules by workload role instead of IP	Used as NSG source or destination; one ASG per rule side; keep private endpoint ASGs to 50 members or fewer
Security admin rules (Azure Virtual Network Manager)	Network groups of VNets	Organisation-wide Allow, Always allow or Deny	Evaluated before NSGs; Deny and Always allow stop evaluation
Private endpoint (Azure Private Link)	A NIC in your subnet	Private IP for one PaaS resource subresource	Only Approved connections pass traffic; needs a private DNS record
Service endpoint	Subnet	Backbone route plus VNet rule on the PaaS firewall	Service still resolves to its public IP; no on-premises coverage
Service endpoint policy	Subnet	Which specific storage resources the subnet may reach	Limits exfiltration to arbitrary accounts over service endpoints
Azure Firewall or NVA with user defined routes	Hub VNet	Central egress, FQDN filtering, IDPS (Premium)	MCSB NS-3 and NS-4

Default rules you must override

Every NSG carries three inbound and three outbound default rules. AllowVNetInBound (65000) and AllowVnetOutBound (65000) permit any traffic whose source and destination are in the VirtualNetwork service tag, which includes peered VNets and connected on-premises ranges. AllowAzureLoadBalancerInBound (65001) admits load balancer probes. AllowInternetOutBound (65001) permits all outbound internet. DenyAllInbound and DenyAllOutBound sit at 65500. To segment, add your own deny rules for VirtualNetwork-to-VirtualNetwork traffic at a priority such as 4000, then allow only the flows each tier needs above it.

Platform addresses

NSGs do not filter traffic to 168.63.129.16 (DHCP, DNS and health probes) or 169.254.169.254 (Instance Metadata Service) by default. If you need to block these, use the AzurePlatformDNS, AzurePlatformIMDS and AzurePlatformLKM service tags. Blocking IMDS breaks managed identity token requests from the VM, so test first. The metadata endpoint matters because stolen metadata tokens are a common route from a web flaw to cloud credentials (MITRE ATT&CK T1552.005, Cloud Instance Metadata API).

Admin roles and privileged access

The built-in Network Contributor role grants Microsoft.Network/*. Microsoft describes it as managing networks but not access to them, which understates its reach: it can edit any NSG rule, create public IPs, add peerings, change route tables and approve private endpoint connections across the scope it is assigned. Treat it as privileged.

Scope it narrowly: assign Network Contributor at the hub or connectivity subscription for the network team, not at a management group that covers every workload subscription.
Split duties with custom roles: give application teams a custom role that can write NSG rules in their own resource group but cannot create publicIPAddresses, virtualNetworkPeerings or routeTables.
Control subnet join: deploying a resource into a subnet needs Microsoft.Network/virtualNetworks/subnets/join/action; using a service endpoint needs joinViaServiceEndpoint/action. Hold these at subnet scope so a team cannot place workloads into another tier's subnet.
Control private endpoint approval: connections auto-approve only when the requester holds Microsoft.<Provider>/<resource_type>/privateEndpointConnectionsApproval/action on the target. Everyone else lands in Pending. Review Pending requests on sensitive resources such as Key Vault and storage, because an approved endpoint from an unknown VNet is a private path into your data.
Private DNS Zone Contributor: this role can change privatelink zones and link them to VNets. Whoever controls those A records controls where clients send traffic.
Use PIM: make Network Contributor and Owner on connectivity subscriptions eligible through Microsoft Entra Privileged Identity Management rather than permanent. See the Azure RBAC and Service Principals Guide.

Administrative access to VMs should not depend on NSG holes. Azure Bastion gives RDP and SSH over TLS on port 443 to VMs by private IP with no public IP on the VM. The Premium SKU adds session recording and a private-only deployment with no public IP on Bastion itself. Bastion needs a dedicated subnet named AzureBastionSubnet.

Integrations, API tokens and service accounts

Network controls in Azure interact closely with the non-human identities that call PaaS services. Getting this layer right is what turns a private endpoint from a routing change into an access control.

Managed identities over keys: once traffic to Storage, Key Vault or SQL is private, remove shared keys and connection strings and authenticate the workload with a managed identity. A storage account key works from any network path the firewall allows. See the Azure Managed Identities Security Guide.
SAS tokens still work through private paths: private endpoints change routing, not authorisation. A leaked SAS token remains usable by anyone who can reach the endpoint. See the Azure SAS Tokens Security Guide.
Trusted services exceptions: PaaS firewalls offer an option to allow trusted Microsoft services to bypass network rules. Decide per resource whether you need it and record why.
Pipeline service principals: infrastructure as code pipelines usually hold Network Contributor or Contributor. Their credentials are effectively the keys to your network boundary. Prefer workload identity federation over client secrets. See the Azure Entra Client Secrets Security Guide.
Cross-tenant private endpoints: a partner can request a private endpoint to your resource from their tenant. Manual approval is the control; record the requesting subscription and business owner.

The lesson from the Microsoft Azure Storage exposure of 2024 is direct: credentials in readable files on an internet-reachable store, with mitigation that relied on the credentials only working from internal networks. Network position and authentication must both hold.

Private endpoints or service endpoints

Question	Private endpoint	Service endpoint
Where does the service name resolve?	Private IP via privatelink zone	Public IP; traffic takes the backbone route
Reachable from on-premises over VPN or ExpressRoute?	Yes, with DNS forwarding	No; only via public IP firewall rules
Scope of access	One resource and subresource	Whole service from the subnet, narrowed by service endpoint policies
Exfiltration risk	Low: the endpoint maps to one resource	Higher without policies: the subnet can reach any account of that service
Cost and effort	Charged per endpoint and data; DNS work	No extra charge; one subnet setting
Microsoft position	Recommended for secure private access to PaaS	Simpler option where private endpoints are not needed

Decision guidance: use private endpoints for regulated data, anything reached from on-premises, and services where you want to disable public network access entirely. Service endpoints remain reasonable for small estates or low-sensitivity storage reached only from Azure subnets, provided you add service endpoint policies. Small organisations with a handful of subscriptions can run a single hub with Azure Firewall and private DNS zones; large estates should centralise privatelink zones in a connectivity subscription and create records through Azure Policy so application teams cannot create conflicting zones.

Logging and detection

Network evidence in Azure comes from three sources: the Activity Log for control plane changes, virtual network flow logs for traffic, and service logs from Azure Firewall, Bastion and the PaaS resources themselves. Route all of them to a Log Analytics workspace or SIEM. See the Azure Monitor, Activity Log and Diagnostic Settings Guide.

Flow logs

Virtual network flow logs record layer 4 flows at one-minute intervals as JSON. Each flow tuple carries timestamp, source and destination IP and port, protocol, direction (I or O), flow state (B begin, C continuing, E end, D denied), encryption status (for example X encrypted, NX unencrypted) and packet and byte counts. They cover workloads and gateways that NSG flow logs miss, including traffic decided by security admin rules. The storage account must be in the same region, Standard tier, and in the same tenant. Rotating a customer-managed key on that account stops logging until flow logs are disabled and re-enabled. Microsoft advises disabling NSG flow logs on the same workloads to avoid duplicates. Note that NSG flow logs do not capture inbound traffic to a private endpoint.

What to alert on

Signal	Source	Why it matters	ATT&CK
NSG rule written with source Internet or * to 22, 3389, 445	Activity Log: `Microsoft.Network/networkSecurityGroups/securityRules/write`	Opens remote services to the internet	T1133, T1021.001, T1021.004
New public IP created or attached to a NIC	Activity Log: `Microsoft.Network/publicIPAddresses/write`	New exposure outside the hub	T1578
Peering, route table or UDR change	Activity Log	Can bypass the firewall	T1599
Private endpoint connection approved from unknown subscription	Activity Log on the target resource	Private path to data	T1530
Public network access re-enabled on Storage or Key Vault	Activity Log; Azure Policy compliance	Undoes private-only design	T1530
Denied flows (state D) from one source across many ports	VNet flow logs	Internal scanning	T1046
Large outbound volume to new destinations, unusual DNS	Flow logs, Azure Firewall, Defender for DNS	Exfiltration or tunnelling	T1048, T1572, T1071.004

Metrics that show it is working

Subnets with a non-default NSG: percentage of workload subnets with an NSG carrying explicit deny rules. Target 100%.
PaaS private-only rate: sensitive Storage, Key Vault and SQL resources with Public network access set to Disabled.
Management ports exposed: count of NSG rules allowing 22 or 3389 from Internet or *. Target zero.
Explicit egress coverage: subnets with defaultOutboundAccess false and a NAT gateway or firewall route.
Flow log coverage: VNets with virtual network flow logs enabled and ingested.
Pending endpoint age: median days private endpoint requests stay Pending on sensitive resources.

Hardening baseline

The Microsoft cloud security benchmark v2 Network Security domain (NS-1 to NS-10) is the reference baseline. The table maps its controls to concrete Azure settings and to other frameworks.

MCSB v2	Azure implementation	NIST SP 800-53 Rev. 5	CIS Controls v8.1
NS-1 Establish network segmentation boundaries	Non-overlapping VNets and subnets per trust zone, NSGs deny by default, ASGs, VNet flow logs	SC-7, SC-7(5), AC-4	12, 13
NS-2 Secure cloud native services with network controls	Private endpoints, privatelink zones, Public network access Disabled, Network Security Perimeter	SC-7, AC-4	12
NS-3 Deploy firewall at the edge	Hub and spoke with UDRs to Azure Firewall, FQDN filtering, TLS inspection on Premium	SC-7	13
NS-4 Deploy IDS/IPS	Azure Firewall Premium IDPS, Alert mode first then Alert and Deny	SI-4	13
NS-5 Deploy DDoS protection	DDoS Network Protection or DDoS IP Protection on internet-facing VNets	SC-5	13
NS-6 Deploy web application firewall	Application Gateway or Front Door WAF, detection then prevention	SC-7	13
NS-7 Manage network security centrally	AVNM security admin rules, Firewall Manager, IP Groups, Azure Policy	CM-6, CA-7	12
NS-8 Disable insecure services and protocols	Sentinel Insecure Protocol workbook; remove SMBv1, TLS 1.0, NTLMv1	CM-7	4
NS-9 Connect privately	ExpressRoute, site-to-site VPN, VNet peering	SC-8, AC-17	12
NS-10 Ensure DNS security	Azure DNS 168.63.129.16 or trusted resolvers, Private DNS zones, Defender for DNS	SC-20, SC-21	9

In NIST CSF 2.0 this work sits mainly in PR.IR-01 (networks protected from unauthorised logical access) and DE.CM-01 (networks monitored). In ISO/IEC 27001:2022 Annex A it maps to A.8.20 Networks security, A.8.21 Security of network services and A.8.22 Segregation of networks.

Rollout in phases

Inventory: export every VNet, subnet, NSG, public IP, peering and private endpoint. Flag subnets with no NSG and NSG rules from Internet or *.
Observe: enable virtual network flow logs on all VNets and collect at least two weeks of flows to see real dependencies before tightening rules.
Central guardrails: deploy AVNM security admin Deny rules for high-risk inbound ports (22, 3389, 445) from the internet, starting with a non-production network group. Note they do not apply to subnets holding Bastion, Azure Firewall or gateways, and they take effect with eventual consistency.
Segment: add explicit deny rules for VirtualNetwork-to-VirtualNetwork traffic per tier, then allow known flows by ASG. Roll out subnet by subnet; because rule changes only affect new connections, test with fresh sessions.
Private PaaS: create private endpoints and privatelink zones, confirm clients resolve to private IPs, then set Public network access to Disabled. Use Azure Policy in Audit before Deny.
Egress: set defaultOutboundAccess to false on subnets and add a NAT gateway or a UDR to Azure Firewall. Existing VMs keep their default outbound IP until stopped and deallocated, so schedule it.
Roll back: keep every NSG and admin rule change in infrastructure as code; rollback is a redeploy of the previous version. For admin rules, deleting the deployment from the network group removes the guardrail without touching NSGs.

Common misconfigurations

Private endpoint added, public access left on: the resource is reachable both ways. This is the most common gap in reviews because the private endpoint looks like the fix.
Relying on default rules: AllowVNetInBound lets every peered spoke and on-premises range talk to every subnet. Without explicit denies, one compromised VM can reach databases in another spoke (T1021).
Broken private DNS: privatelink zones not linked to the VNet the client uses, two services mixed in one zone, or on-premises DNS not forwarding privatelink names. Clients fall back to the public IP and fail closed only if public access is disabled. Use Fallback to Internet on the VNet link when some resources of a service have no private endpoint.
Unplanned outbound internet: default outbound access and AllowInternetOutBound give every VM a route out through an IP you do not own. Existing VNets keep this until you change them.
Management ports open "temporarily": RDP or SSH from * left after troubleshooting. Use Bastion or just-in-time VM access in Defender for Cloud and an AVNM Deny so the hole cannot reappear.
Service endpoints without policies: the subnet can write to any storage account in the region, including an attacker's, which makes exfiltration look like normal backbone traffic (T1567, T1048).
NVA without SNAT for private endpoint traffic: asymmetric routing breaks connections; Microsoft recommends SNAT on the NVA for traffic to private endpoints.

Practitioner checklist

Every workload subnet has an NSG with explicit deny rules above the 65000 defaults, and rules use ASGs and service tags rather than raw IPs.
AVNM security admin Deny rules block inbound 22, 3389 and 445 from the internet across all managed VNets.
Sensitive Storage, Key Vault and SQL resources use private endpoints with Public network access Disabled, enforced by Azure Policy.
Privatelink zones are centralised, one per service, linked to every VNet that needs them, with on-premises conditional forwarding tested.
Private endpoint approvals on sensitive resources are manual and reviewed; Disconnected endpoints are deleted.
Subnets have defaultOutboundAccess false and egress goes through a NAT gateway or Azure Firewall with FQDN rules.
Network Contributor is scoped to connectivity subscriptions, eligible through PIM, and pipelines use federated credentials.
Virtual network flow logs are enabled everywhere and NSG flow logs are migrated before 30 September 2027.
Alerts exist for NSG rule writes from Internet, new public IPs, peering and route changes, and public access re-enabled.
VM administration uses Azure Bastion; no VM has a public IP for RDP or SSH.

Azure Virtual Network Security Guide: NSGs, Private Endpoints and Service Endpoints