Compliance

Restrict virtual machine network exposure

One capability across every VM in the estate: make sure no machine has its management ports open to the internet, that every internet-facing VM sits behind a network security group, and that the ports you do need to reach are opened only when someone is using them.

14 min·10 sections·AZURE

Last reviewed 18 June 2026

Remediates Microsoft Defender for Cloud: azure-internet-facing-vm-nsg azure-jit-vm-access azure-non-internet-vm-nsg-protected azure-nsg-all-network-ports-restricted azure-subnet-nsg-associated azure-vm-attack-vector-ports-closed azure-vm-ip-forwarding-disabled azure-vm-management-ports-closed

Restricting VM network exposure: the basics

What does an over-exposed virtual machine actually look like?

A virtual machine becomes attack surface the moment one of its ports answers from the public internet, and the exposure shows up in a few distinct shapes rather than one setting. A management port can be open: RDP on 3389 or SSH on 22 reachable from any address, which is a standing invitation to credential brute force. An internet-facing VM can have no network security group at all, so nothing filters inbound traffic before it reaches the operating system. Or a VM can have a network security group that exists but is too permissive, with an inbound rule that allows a management port from 'Any' or 'Internet'. Each is its own Defender for Cloud recommendation, but the underlying risk is the same: a machine that more of the internet can reach than you meant.

Microsoft Defender for Cloud turns each of these into its own recommendation, which is why one VM-heavy subscription can fail several network checks at once. 'Management ports should be closed on your virtual machines' and 'Management ports of virtual machines should be protected with just-in-time network access control' are the two that close the widest doors on the management plane, and they pair with 'Internet-facing virtual machines should be protected with network security groups' to form a single capability. They read as separate problems on the report, but they are one job: stop machines being reachable on ports you did not mean to expose, and gate the management ports you do need behind access that opens on request and closes again.

Most of this exposure is drift, not intent. A VM spun up with the portal default that opens 3389 to the world for a quick login, a subnet that never had a network security group attached, a test rule that allowed SSH from anywhere and was never tightened. The work is to find every machine that is reachable more widely than intended, attach and tighten the network security groups that filter inbound traffic, and replace standing open management ports with just-in-time access so the port is shut by default and opened only for the minutes someone actually needs it.

In this lesson you will learn how Azure expresses virtual-machine network exposure, how to find every over-exposed machine in a subscription, and how to lock them down with network security groups and just-in-time access without losing the management access your team needs. The Controls this lesson covers section lists every Defender for Cloud recommendation in this capability, each linking to a deep page with the exact check and a copy-and-paste fix.

Fun fact

The port the whole internet is already knocking on

Point a fresh virtual machine at the internet with RDP open and you do not have to wait long for the first login attempt. Internet-wide scanners catalogue millions of open RDP and SSH endpoints, and automated brute-force tooling works through them constantly, which is why a VM with 3389 open to 'Any' typically starts seeing failed logins within minutes of going live. Just-in-time access flips the default: the management port stays shut, an authorised user requests access for a bounded window, often up to three hours, and Defender for Cloud opens a temporary, source-scoped rule that closes itself again when the window expires. The attacker scanning the internet finds a closed port the rest of the time.

Finding VM network exposure across a subscription

Sam is the security lead at a scale-up preparing for its first ISO 27001 audit. Defender for Cloud shows VM network findings spread across a dozen machines in two subscriptions that pre-date the team's current guardrails.

Rather than work the findings one by one, Sam starts by listing which network security group rules still allow a management port from the internet, so the genuinely exposed machines can be separated from drift before anything changes.

Start by listing the network security group rules that allow RDP or SSH from any internet source. These are the widest-open doors.

$ az network nsg rule list -g prod-rg --nsg-name prod-nsg \ --query "[?access=='Allow' && (sourceAddressPrefix=='*' || sourceAddressPrefix=='Internet') && (destinationPortRange=='3389' || destinationPortRange=='22')].{rule:name, port:destinationPortRange, src:sourceAddressPrefix}" -o table

Rule Port Src

---------------- ------ --------

allow-rdp-any 3389 *

allow-ssh-office 22 Internet

# allow-rdp-any opens RDP to the whole internet. Close it, then gate 3389 behind JIT.

A rule that allows a management port from '*' or 'Internet' is the highest-value target in this group. Close these first, then put the ports you genuinely need behind just-in-time access.

How Defender for Cloud decides a virtual machine is over-exposeddeep dive

Most VM network recommendations resolve to the relationship between a machine's network interface, its subnet and the network security group rules that govern inbound traffic. A network security group is an ordered list of rules evaluated by priority; each rule matches on source, source port, destination, destination port and protocol, and either allows or denies. Defender for Cloud flags 'Management ports should be closed' when an effective inbound rule allows 3389, 22 or another management port from a broad source such as '*' or the 'Internet' service tag. It flags 'Internet-facing virtual machines should be protected with network security groups' when a VM it has identified as reachable from the internet has no network security group filtering its traffic at all.

Just-in-time access changes the steady state rather than the rule logic. When you enable it on a VM, Defender for Cloud ensures a deny rule covers the protected management ports, so they are closed by default. When an authorised user requests access, Defender for Cloud inserts a temporary, higher-priority allow rule scoped to that user's source address and the requested ports for a bounded time window, then removes it when the window expires. The recommendation 'Management ports should be protected with just-in-time network access control' clears once that protection is in place. Just-in-time access requires Microsoft Defender for Servers Plan 2 on the subscription.

Defender for Cloud evaluates these against the Microsoft Cloud Security Benchmark, mapping management-port closure and just-in-time access to control PA-2 (avoid standing access for user accounts and permissions), the benchmark control that ties the Defender for Cloud just-in-time VM access feature to restricting inbound traffic on management ports, and internet-facing network security group coverage to NS-1 (establish network segmentation boundaries). Assessment runs on a periodic cycle, so a fix does not flip the recommendation to Healthy instantly; the control-plane change is immediate, but the posture catches up on the next assessment. The strongest position combines the per-machine fix with an Azure Policy backstop that audits or denies VMs left without network security group protection or just-in-time control, so no machine can be created back into the open state unnoticed.

What is the impact of leaving virtual machines exposed?

The direct impact is compromise. A management port open to the internet is found within minutes by automated scanners and ground against by brute-force tooling until a weak or reused credential gives way. Once an attacker has a session on the VM, the machine becomes a foothold: its data is readable, its identity and any attached managed identity can be abused, and it becomes a launch point for lateral movement into the rest of the network. The overwhelming majority of these incidents start with an accident, a port that could be left open was left open by a portal default or a test rule nobody intended.

The second-order impact is blast radius. Every machine reachable on a management port, and every internet-facing machine with no network security group filtering its traffic, is attack surface that has to be defended continuously. Locking VM exposure down shrinks that surface to the handful of front doors you actually operate and the bounded windows in which management ports are open, which are the ones you can monitor, source-scope and time-box.

On the compliance side, every modern framework, ISO 27001, SOC 2, HIPAA, PCI DSS and the UK and EU data-protection regimes, expects evidence that management interfaces are not exposed to the internet and that internet-facing systems are segmented behind network controls. A passing set of VM network recommendations across every subscription, with just-in-time access in place for the management ports you do need, is the cheapest and most defensible artefact you can hand an auditor.

How do you lock virtual machine exposure down safely?

Work the capability as one loop rather than chasing individual findings. The order matters: identify the management access your team genuinely needs before you start closing things, so you do not lock yourself out of a machine you still have to administer.

1. Inventory every machine by exposure

List the network security group rules that allow a management port from '*' or 'Internet', the internet-facing machines with no network security group attached, and the machines whose management ports are not yet protected by just-in-time access. Treat this inventory as the source of truth, not the Defender finding count, because one machine can trigger several recommendations at once.

2. Attach a default-deny network security group to anything without one

Every internet-facing machine needs a network security group filtering its inbound traffic. Attach one to each machine or subnet that has none, allowing only the application ports the workload genuinely serves (for example 443 on a web server) and denying the rest. This closes the 'internet-facing VMs should be protected with network security groups' finding directly.

3. Close standing open management ports, highest impact first

Remove or tighten any rule that allows 3389, 22 or another management port from a broad source. Prioritise production machines and anything that can reach sensitive systems over isolated test boxes. Each change is a single rule update and takes effect immediately. Where the workload never needs inbound management access at all, leave the port denied entirely and use Azure Bastion or a private path instead.

4. Gate the management ports you do need behind just-in-time access

For the machines an operator still has to log in to, enable just-in-time network access control so the management port stays shut by default and opens only on an authorised, time-boxed, source-scoped request. Then assign an Azure Policy that audits or denies any VM left without network security group protection or just-in-time control, so the safe configuration is enforced rather than merely encouraged.

# 1. Close the highest-impact exposure first: delete any rule that
#    allows a management port from the whole internet.
for rule in $(az network nsg rule list -g prod-rg --nsg-name prod-nsg \
    --query "[?access=='Allow' && (sourceAddressPrefix=='*' || sourceAddressPrefix=='Internet') && (destinationPortRange=='3389' || destinationPortRange=='22')].name" -o tsv); do
  az network nsg rule delete -g prod-rg --nsg-name prod-nsg -n "$rule"
  echo "$rule: open management-port rule removed"
done

# 2. Add an explicit deny on the management ports as a backstop.
az network nsg rule create -g prod-rg --nsg-name prod-nsg \
  --name deny-mgmt-ports --priority 4000 --access Deny --direction Inbound \
  --protocol Tcp --source-address-prefixes Internet \
  --destination-port-ranges 22 3389

# 3. Gate the ports you still need behind just-in-time access.
#    JIT is configured via PowerShell or the portal; request access with the CLI:
az security jit-policy list -o table   # confirm the JIT policy is in place

# 4. Ratchet it shut: audit any VM left without an NSG (Defender built-in policy).
az policy assignment create \
  --name audit-internet-facing-nsg \
  --policy f6de0be7-9a8a-4b8a-b349-43cf02d22f7c \
  --scope "/subscriptions/00000000-0000-0000-0000-000000000000"

Quick quiz

Question 1 of 5

Defender for Cloud shows VM network findings across open management ports, missing network security groups and just-in-time access on several machines. What is the most efficient way to think about them?

Keep learning

Go deeper on how Azure filters virtual-machine traffic and how just-in-time access gates the management ports in this capability.

You can now treat virtual-machine network exposure as one capability rather than a scatter of findings: inventory what is reachable too widely, attach a network security group to every internet-facing machine, close standing open management ports highest-impact first, gate the ports you genuinely need behind just-in-time access, and ratchet the estate shut with an Azure Policy backstop. The Controls this lesson covers section below links every recommendation in this group to its deep page and fix.

Back to the library

Restricting VM network exposure: the cost and risk view

A near-zero-cost capability that removes the largest class of VM compromise risk

Open management ports are the single most common entry point for VM compromise in Azure, and almost every control in this group costs nothing in Azure spend to fix. Attaching a network security group, tightening an over-permissive inbound rule or closing an unused management port does not change your bill. The one cost to be aware of is that just-in-time network access control is a feature of Microsoft Defender for Servers Plan 2, so enabling it carries the per-server Defender plan charge, which is a security investment rather than a remediation cost and usually already in place where Defender for Cloud is reporting at all.

Frame each failing recommendation as a line on the risk register rather than a compliance checkbox. A production jump box with RDP open to the internet carries a far higher expected loss than an isolated test VM behind a deny-all rule, yet both can surface as a single red finding. Map the failures to what each machine can reach if it is compromised, its data, its lateral movement into the rest of the network, and prioritise by blast radius, not by recommendation count.

The insurance arithmetic is one-sided. The remediation is engineering time plus, where you adopt just-in-time, the Defender for Servers plan you most likely run already. The downside of leaving it is the documented cost of a VM breach: ransomware, lateral movement into the wider estate, incident response, breach notification and downtime.

This lesson is for the finance partner who sees a cluster of VM network findings on the security report and wants to know what the right response is and what it costs. It covers why most of these controls are free to fix, where the one real cost sits (the Defender for Servers plan that powers just-in-time access), and how to turn a list of red findings into a risk-ordered remediation plan.

Fun fact

The port the whole internet is already knocking on

How a finance partner frames the VM exposure decision

Sam is the finance partner supporting the platform team's ISO 27001 push. The security report lands with eleven VM network findings spread across a dozen machines in two older subscriptions. The instinct is not to wave through a blanket remediation budget; it is to ask what is actually behind each red finding. Closing an open management port, attaching a network security group or tightening an over-permissive rule changes nothing on the Azure bill, so the spend question is narrow: only the move to just-in-time access touches cost, and only because it rides on Microsoft Defender for Servers Plan 2, which the team most likely already runs given Defender for Cloud is reporting at all.

Sam asks the team to map each failing machine to what it can reach if it is compromised. Two are production jump boxes with RDP open to the internet, one is a public web server that is meant to be reachable on 443 but has SSH open too, and the rest are test machines with no network security group attached. The list is reframed on the risk register: the two jump boxes are high blast-radius items to close today at zero Azure cost and then gate behind just-in-time access, the web server needs its management port closed while 443 stays open, and the test machines are low-value drift to sweep up with a default-deny network security group. The finance pack reads: 'Every finding closes at no incremental Azure spend; just-in-time access uses the Defender plan we already pay for; the only thing standing between us and a clean posture is engineering time, not budget.'

Why VM network exposure belongs on the risk register

The cost model here is asymmetric in a way that is rare for security work. Closing ports and attaching network security groups costs nothing in Azure spend, and the one feature that does carry a charge, just-in-time access, rides on a Defender for Servers plan the team most likely already runs. Leaving exposure open creates an unbounded tail risk: each failing recommendation is a machine where a brute-force success could mean ransomware or lateral movement, and while the probability per event is low, the probability across all exposed machines over years is not.

The documented cost of a VM breach includes incident response and forensics that routinely run into six and seven figures, ransomware payments or rebuild costs, mandatory breach notification within tight regulatory windows, and downtime while the estate is contained and cleaned. Against that, the remediation is engineering time plus a Defender plan you most likely already pay for. The finance role is to attach expected loss to each failing machine, weighted by what it can reach if compromised, so the work is prioritised by blast radius, not by the order the report lists it.

What finance can do about the VM exposure gap

Finance cannot close a port or attach a network security group, but it owns the framing that turns a scatter of red findings into a risk-ordered plan with almost no incremental Azure spend and one clearly identified cost line. Three levers.

1. Separate the zero-cost closures from the one real cost line

Make explicit that closing management ports, attaching network security groups and tightening over-permissive rules cost nothing in Azure spend: they do not move the bill. The only cost line is just-in-time access, which rides on Microsoft Defender for Servers Plan 2, and that is almost certainly already running wherever Defender for Cloud is reporting at all. Budget it as a security investment, not a remediation cost, and treat everything else as engineering time so nobody can claim the whole capability is a spending decision.

2. Order the work by blast radius, not by finding count

A production jump box with RDP open to the internet and an isolated test VM with no network security group both show up as a single red finding, but what they can reach if compromised differs by orders of magnitude. Ask the team to map each failing machine to its blast radius, what data and what onward network access a foothold would grant, and prioritise the high-blast-radius machines first. The metric that belongs on the cost-and-security review is the count of VM network findings weighted by blast radius, not the raw total.

3. Require documented exceptions for any port left open

Any management port left reachable on purpose, the one bastion host, the support jump box during a migration, should carry a recorded, finance-visible reason, a source restriction and ideally a just-in-time window. The distinction between 'we reviewed this and scoped it deliberately' and 'we never noticed it was open' is exactly what makes the posture defensible at audit and in the aftermath of any intrusion.

Quick quiz

Question 1 of 5

A security report shows eleven VM network findings. As the finance partner, what is the right starting assumption about their Azure-spend cost to remediate?

Keep learning

Go deeper on how Azure filters virtual-machine traffic and how just-in-time access gates the management ports in this capability.

You have finished the finance view of restricting VM network exposure. You know the cost model is one-sided: closing ports and attaching network security groups is free in Azure spend, the only cost line is just-in-time access on a Defender plan you most likely already pay for, and the downside of leaving exposure open is the documented and unbounded cost of a breach. Next time a cluster of VM network findings lands, you will order them by blast radius, ring-fence the real exceptions behind just-in-time access, and ask for them on the record rather than asking how much remediation will cost.

Back to the library

Restricting VM network exposure: the headline

Whether any machine in the estate can be reached and attacked from the internet by accident

An open management port is how most VM compromises start: an attacker scans the internet for machines answering on RDP or SSH, then grinds away at passwords until one works. The report shows this as a scatter of separate findings across the estate, but they all point at the same exposure.

The leadership question is not 'are we compliant today?' It is 'if a deployment opens a port tomorrow, can an attacker reach it from the internet?' The defensible end state is that every internet-facing machine sits behind a network security group, no management port is left standing open, and the ports the team genuinely needs are reachable only through just-in-time access that opens on request and closes on a timer.

None of this is a cost decision. Closing ports and attaching network security groups is essentially free in Azure terms, and just-in-time access rides on a Defender plan you most likely already run. It is a governance decision about whether exposure is prevented by design or only by everyone remembering to close the door behind them.

A short read for the leader who needs to know what an exposed virtual machine reveals, why locking it down is a governance decision rather than a budget one, and what a defensible end state looks like across the estate.

Fun fact

The port the whole internet is already knocking on

What it looks like when VM exposure is prevented by design, not luck

After a peer company was hit by ransomware that got in through an Azure VM with RDP open to the internet, the CEO asked the obvious question at the next review: could that happen to us? The honest answer at the time was that it depended on whether anyone had remembered to close the port, because management-port exposure across the estate was governed by habit rather than policy.

The team's response was to stop treating VM exposure as a per-machine cleanup and start treating it as a guardrail. They listed every network security group rule that allowed a management port from the internet, attached default-deny network security groups to the machines that had none, closed the standing open ports, and put the management access the team genuinely needed behind just-in-time access so the ports are shut by default and open only for the minutes someone is logged in. They then set an Azure Policy that audits for any VM whose management ports are not protected by just-in-time control. The next time the CEO asked the question, the answer had changed from 'we believe so' to 'no, the management ports are closed by default and only open on request, and that is enforced.' That shift, from relying on everyone remembering to close the door to making the door close itself, is the one-line confidence signal this capability delivers, and it costs nothing in Azure spend beyond a Defender plan we already run.

Why this is a board-level risk

Nearly every ransomware and intrusion case that started in a cloud VM came back to the same root cause: a management port that could be reached from the internet was, and an attacker walked in through it. Locking VM exposure down is the capability that makes that root cause structurally difficult, and just-in-time access plus an Azure Policy backstop makes it close to impossible.

The cost of getting this wrong is large and well documented, while the cost of fixing it is essentially engineering time plus a Defender plan you most likely already run. This is the rare class of control where the risk of inaction is severe and the cost of action is small, which is exactly the trade leadership should be quickest to approve.

The leadership move on VM exposure

The executive handle is not to approve each closure individually; it is to require that management ports are shut by default, that every internet-facing machine sits behind a network security group, and that the ports the team genuinely needs are gated behind just-in-time access, on the record.

1. Set a deadline to reach a backstopped end state

Ask for a date by which the estate is inventoried, every internet-facing machine has a network security group, standing open management ports are closed, the ports the team needs are behind just-in-time access, and Azure Policy audits or denies any VM left unprotected. A backstop that no individual machine can quietly escape is the difference between checking nothing is exposed today and guaranteeing nothing can be exposed tomorrow.

2. Ask for proof, not assurance

The proof that this is closed is not a verbal 'we are on it.' It is a passing set of VM network recommendations across every subscription plus evidence that just-in-time access is enabled on the machines that need management access and the audit policy is assigned. Because Defender for Cloud assesses on a periodic cycle, ask for that evidence with a little lead time before any audit deadline rather than the morning of.

3. Treat any open management port as a named, owned exception

A small number of machines may need management access for an operator, and that is fine: behind just-in-time access, that is not a standing open port. The leadership requirement is that any port left reachable is a deliberate, documented decision with an owner, a source restriction and a time bound, not an accident left open. The goal is not zero administrative access; it is zero standing open management ports.

Quick quiz

Question 1 of 5

At a board review you ask whether a ransomware incident like a competitor's, which got in through an open RDP port, could happen to your estate. What end state should you be looking for as the defensible answer?

Keep learning

Go deeper on how Azure filters virtual-machine traffic and how just-in-time access gates the management ports in this capability.

Two takeaways. VM network exposure is the rare control where the risk of inaction is severe and the cost of action is essentially engineering time plus a Defender plan you most likely already run, so it is the trade you should be quickest to approve. And the defensible end state is not 'we checked and nothing is open today'; it is management ports shut by default behind just-in-time access, every internet-facing machine behind a network security group, and an Azure Policy backstop, making accidental exposure structurally hard, with any deliberate access documented and owned.

Back to the library

Controls this lesson covers

One capability, many Microsoft Defender for Cloud recommendations. This lesson is the shared playbook; each control below keeps its own deep page with the exact check, severity and a copy-and-paste fix.

Azure Virtual Machines

Azure Virtual Network

(Enable if required) Subnets should be associated with a network security group Low Subnets without an NSG leave every resource in them open to unfiltered network traffic

Compute

Part of the learning path Close Azure network exposure

Restrict virtual machine network exposure

Restricting VM network exposure: the basics

The port the whole internet is already knocking on

Finding VM network exposure across a subscription

How Defender for Cloud decides a virtual machine is over-exposeddeep dive

What is the impact of leaving virtual machines exposed?

How do you lock virtual machine exposure down safely?

1. Inventory every machine by exposure

2. Attach a default-deny network security group to anything without one

3. Close standing open management ports, highest impact first

4. Gate the management ports you do need behind just-in-time access

Quick quiz

Keep learning

Restricting VM network exposure: the cost and risk view

The port the whole internet is already knocking on

How a finance partner frames the VM exposure decision

Why VM network exposure belongs on the risk register

What finance can do about the VM exposure gap

1. Separate the zero-cost closures from the one real cost line

2. Order the work by blast radius, not by finding count

3. Require documented exceptions for any port left open

Quick quiz

Keep learning

Restricting VM network exposure: the headline

The port the whole internet is already knocking on

What it looks like when VM exposure is prevented by design, not luck

Why this is a board-level risk

The leadership move on VM exposure

1. Set a deadline to reach a backstopped end state

2. Ask for proof, not assurance

3. Treat any open management port as a named, owned exception

Quick quiz

Keep learning

Controls this lesson covers

Azure Virtual Machines

Azure Virtual Network

Compute

Related compliance lessons