SC-500 Server and VM Security: Disk Encryption, Bastion, JIT, Arc and Defender for Servers

Every Azure managed disk is already encrypted at rest by server-side encryption (SSE); the decision is what else has to be encrypted and who holds the key. SSE covers persisted OS and data disks, snapshots and images, but it never encrypts the temporary disk or the OS and data disk caches. Encryption at host closes that gap: the VM host encrypts temp disks, caches and the data flowing to storage, so no guest CPU is spent and nothing runs inside the VM. It is Microsoft's recommended option for new VMs.

Azure Disk Encryption (ADE) runs BitLocker (Windows) or DM-Crypt (Linux) inside the guest, with keys and optional key encryption keys (KEKs) in Key Vault. It uses the VM's own CPU and is scheduled for retirement on 15 September 2028, so it is a migration source, not a design choice for new workloads. Confidential disk encryption is for confidential VMs: the OS disk keys are bound to the VM's vTPM, which is only meaningful together with the hardware-based protection of data in use that confidential computing provides.

Double encryption and customer-managed keys still protect only persisted disks; neither adds temp-disk or cache coverage, and neither protects memory. When the requirement says data in use must be shielded from the cloud operator and host, only a confidential VM meets it; Trusted launch and encryption at host protect boot integrity and data at rest respectively.

Moving from ADE to encryption at host

There is no in-place migration. Encryption at host can't be enabled on a VM whose disks have ever used ADE, because the disks keep ADE metadata (the UDE flag) even after full decryption, and snapshots or the disk Copy option carry that flag with them. Microsoft's supported path is: disable ADE and confirm the volumes are fully decrypted, create new empty managed disks with the Upload method, copy each disk's data into them (for example with AzCopy), then create a new VM with encryption at host and attach the new disks. A Linux VM whose OS disk is ADE-encrypted can't decrypt that disk at all, so it needs a fresh VM and a data copy.

Customer-managed keys through a disk encryption set

A disk encryption set (DES) is the Azure resource that links managed disks to a customer-managed key in Key Vault or Managed HSM. Disks use envelope encryption: each disk has a data encryption key, and the storage service wraps and unwraps it with your key by calling Key Vault as the DES's managed identity (system-assigned by default). That identity, not the VM and not the administrator, is what needs key access.

• Key Vault using Azure RBAC: assign Key Vault Crypto Service Encryption User to the DES identity. It grants only get, wrap and unwrap on keys, which is least privilege. Key Vault Crypto User would also work but adds encrypt, decrypt, sign and verify; Key Vault Crypto Officer is a key-management role.
• Key Vault using access policies: grant the DES identity the Get, Wrap Key and Unwrap Key key permissions. Access policies are ignored once a vault uses the RBAC permission model.
• The key vault needs soft delete and purge protection, so a key can't be destroyed by accident.

Rotation

A DES that references a specific key version stays on that version. A Key Vault rotation policy creates new key versions, but on its own it changes nothing on the disks. Turn on automatic key rotation on the disk encryption set, and Azure moves every disk, snapshot and image that references the DES to the latest key version within about an hour, without rebooting VMs. Any approach that tracks new key versions yourself, by hand or with custom automation, can work, but it is repeated work or code to maintain; the DES setting is the built-in way to keep disks on the latest version.

Revocation is a shutdown

If the key is disabled, deleted or expires, the storage service can no longer unwrap the disks' data keys. VMs whose OS or data disks use that key are shut down automatically and won't start until the key is re-enabled or a new key is assigned. The effect is immediate and total: the disks stay encrypted with the unavailable key, so the only recovery is restoring access to that key or assigning another one. This is the point of customer-managed keys, and also why key vault permissions need the same care as the VMs themselves.

Azure Bastion is a managed service that gives RDP and SSH to VMs over TLS through the Azure portal or a native client, so the VMs need no public IP address and no management ports open to the internet. Bastion connects to each target on its private IP. The SKU decides which features are available, and you can upgrade a SKU but not downgrade it.

Pick the lowest SKU that covers every stated requirement: native client or file transfer means Standard at least; session recording or a bastion host with no public IP means Premium. Diagnostic logs on any dedicated SKU record who connected and when, but they are not a playable recording. IP-based connection is about how Bastion reaches targets by private IP (including on-premises addresses), not about how users reach Bastion.

NSG rules

Bastion is deployed into a subnet named exactly AzureBastionSubnet (/26 or larger). If you attach an NSG to it, it must carry every rule below, or Bastion stops working, reports as unhealthy or misses platform updates.

The target VMs' subnet needs only an inbound allow for 3389 (Windows) or 22 (Linux) from the AzureBastionSubnet address range. Scoping the source that narrowly lets Bastion in and keeps everything else out; RDP and SSH ports are never needed inbound on AzureBastionSubnet itself.

Just-in-time (JIT) VM access is a Defender for Cloud feature that keeps management ports such as RDP and SSH closed by default and opens them only when an authorised user requests access, for a limited time and from a specified source IP. It is part of Defender for Servers Plan 2; Plan 1 and Defender CSPM don't include it.

When you enable JIT on a VM, Defender for Cloud adds deny rules for the selected ports to the VM's NSG (and, if the VM sits behind one, to an Azure Firewall). Defender for Cloud proposes ports 22, 3389, 5985 and 5986; the defaults are a three-hour maximum request time and any source IP (enabling JIT from the VM's own Configuration page covers just 3389 on Windows or 22 on Linux). You can change the ports, the time limit and the allowed source IPs. JIT also extends, in preview, to AWS EC2 instances connected to Defender for Cloud. An approved request adds a time-limited allow rule with higher priority than the deny rule, for the requester's IP (or the range you allowed), and removes it when the time expires.

• Existing rules win. JIT doesn't rewrite rules that were already there. A standing allow rule for a JIT port keeps priority over the deny rule JIT adds, so the port stays open without any request. To make every connection go through JIT, remove the old allow rule; a new deny rule at a lower priority is evaluated after it and changes nothing.
• Azure Firewall: JIT can manage an Azure Firewall only when it uses classic rules. A firewall governed by Azure Firewall Manager through a firewall policy isn't supported, at any tier, so a VM protected only that way shows as unsupported. JIT on a firewall uses DNAT rules, so the VM doesn't need its own public IP.
• A VM with no NSG and no supported firewall in front of it can't use JIT until one of those is in place.

JIT controls when a port is open; it is not a connection path. Users still need network reachability, and pairing JIT with Bastion (no public exposure at all) is a common design.

Least privilege separates requesting JIT access from configuring it. Microsoft documents the actions each job needs, so a custom role can grant exactly one of them.

Requesters don't need NSG permissions, because Defender for Cloud edits the NSG or firewall on their behalf. Microsoft.Compute/virtualMachines/login/action is unrelated: it governs Microsoft Entra ID sign-in to a VM, not JIT, and isn't needed when people sign in with local accounts.

Finding VMs that should use JIT

Defender for Cloud lists every VM that supports JIT but doesn't have it as an unhealthy resource of the recommendation Management ports of virtual machines should be protected with just-in-time network access control, across all subscriptions in scope. Selecting unhealthy VMs there lets you enable JIT directly. Other recommendations remediate differently: Management ports should be closed on your virtual machines wants the ports closed, and Internet-facing virtual machines should be protected with network security groups flags VMs with no NSG at all. On the Just-in-time VM access page, the Configured tab shows VMs already protected, Not configured shows candidates, and Unsupported shows VMs JIT can't manage, with the reason.

Auditing

Each JIT request is an Azure operation, so it is recorded in the Activity log. From the Configured tab, the VM's menu opens the Activity log already filtered to that VM, showing who requested access and when, and the view can be downloaded as CSV. Approved requests are normal operations and don't raise security alerts; NSG flow logs show packets, not who requested access.

Azure Arc-enabled servers project on-premises and other-cloud machines into Azure as resources, so Azure Policy, machine configuration, Defender for Cloud and VM extensions can target them like Azure VMs. Onboarding installs the Azure Connected Machine agent on each server; the agent already includes the machine configuration (guest configuration) agent.

Onboarding at scale with least privilege

For scripted onboarding of many servers, create a service principal and assign it Azure Connected Machine Onboarding, scoped to the target resource group. That role can only connect new machines, so a secret stored on a deployment server can't be used to change existing machines or deploy extensions. Azure Connected Machine Resource Administrator (and the older Hybrid Server Resource Administrator) also manage existing machines and extensions, and Kubernetes Cluster - Azure Arc Onboarding is for clusters, not servers. An Azure Arc private link scope keeps agent traffic on private endpoints; it controls connectivity, not what runs on the server.

Local agent security controls

Some protections must hold even against an Azure subscription Owner, so they live in the agent and can only be changed by running azcmagent config locally on the server:

• Extension allowlist / blocklist (extensions.allowlist, extensions.blocklist): only allowed extensions can be installed, or listed ones are refused, whatever is requested from Azure.
• Monitor mode (azcmagent config set config.mode monitor): a preset that allows only monitoring and security extensions (such as Azure Monitor Agent and Defender for Cloud's), blocks extensions that run scripts or change configuration (Custom Script, Run Command), disables the machine configuration agent, and freezes the allowlist and blocklist. It suits servers such as domain controllers that are onboarded only for monitoring and protection.
• Guest configuration switch (guestconfiguration.enabled): turns the machine configuration agent off or on.

Azure Policy deny assignments and RBAC changes can be undone by an Owner, so they can't meet a "block even Owners" requirement. If a monitor-mode server must also report machine configuration baselines, switch it back to full mode, set an extensions allowlist that still excludes script extensions, and set guestconfiguration.enabled to true. Custom machine configuration content runs with high privilege, so enable it only where the compliance need justifies it.

Microsoft Defender for Servers is the Defender for Cloud plan that protects Windows and Linux machines in Azure, on-premises and in AWS or Google Cloud. How a machine gets onboarded depends on where it runs and on which features it needs.

For AWS and GCP machines, agentless scanning works through the connector with no agent, which is why its results can appear before anything else. Features that run in the guest need the machine to be Arc-onboarded; letting the connector auto-provision Arc covers existing and future instances, where a manual Arc rollout has to be repeated. Creating the connectors themselves belongs to the multicloud posture topic.

Plan 1 vs Plan 2 and where to enable them

Scope matters for cost. Plan 1 can be enabled and disabled per resource, so a handful of VMs can be covered without paying for the whole subscription. Plan 2 is enabled only at subscription level; it can be disabled on individual resources afterwards. Enabling either plan on the subscription bills every machine in it; tags don't limit coverage.

Defender for Servers settings live in Defender for Cloud under Environment settings > the subscription > Defender plans > Servers > Settings, where each component (endpoint protection, vulnerability assessment, agentless scanning and others) is switched on or off.

Endpoint detection and response (Defender for Endpoint)

The Endpoint protection component deploys Microsoft Defender for Endpoint to Azure VMs and Arc-enabled machines (the MDE.Windows and MDE.Linux extensions), giving EDR, next-generation protection and alerts that flow into Defender for Cloud. It is on by default when the plan is enabled. Points that come up when configuring it:

• Unified solution for older Windows Server: subscriptions that turned on the integration before the unified Defender for Endpoint solution existed need a one-time opt-in. The component then shows Partial; selecting Fix and enabling the Unified solution makes Defender for Cloud deploy it to Windows Server 2016 and 2012 R2 machines.
• Linux update control: MDE.Linux keeps the Defender for Endpoint package up to date. Tag specific Azure VMs or Arc machines with ExcludeMdeAutoUpdate = true to manage their package versions manually; every other machine keeps automatic updates.
• Tenant association: machines are onboarded to the Defender for Endpoint tenant associated with the subscription's Microsoft Entra tenant. A machine that already reports to a different Defender for Endpoint tenant must be offboarded there first.
• Defender for Servers no longer uses the retired Log Analytics agent (MMA) for any of this.

Turning off the component, or disabling the plan on a VM, removes protection rather than adjusting it, so scoped behaviour changes are made with tags or per-machine settings.

Vulnerability assessment

The built-in vulnerability scanner is Microsoft Defender Vulnerability Management (MDVM). With the plan enabled, MDVM assessment is on by default for machines that run the Defender for Endpoint sensor, so software inventory and CVE-based findings appear in Plan 1 without anyone deploying a scanner. The older Qualys-based integrated scanner has been retired. Agentless scanning (Plan 2 or Defender CSPM) also feeds MDVM, from disk snapshots instead of the sensor. MDVM premium capabilities such as security baseline assessments, browser extension inventory and digital certificate inventory are included in Plan 2 and are viewed in the Microsoft Defender portal; no separate MDVM add-on licence is needed. Azure Update Manager reports missing patches, which is a different thing from a CVE-based inventory. Deeper configuration of vulnerability management findings belongs to the posture topic.

Agentless machine scanning takes snapshots of a VM's disks, analyses them out of band in Microsoft's scanning environment and deletes them, so nothing is installed or run on the machine and there is no performance impact on it. It reports software inventory, vulnerabilities (through Defender Vulnerability Management) and secrets, and with Defender for Servers Plan 2, malware found with Microsoft Defender Antivirus engines.

This makes agentless scanning the answer for appliances or machines whose support terms forbid an agent: Plan 2 gives malware detection with nothing installed. If agentless vulnerability results already appear on a Plan 1 subscription, they come from Defender CSPM, which never adds malware detection.

Managing it

• Enable it in the plan's settings (the Agentless scanning for machines component); you can exclude machines by tag.
• Schedule: scans run on a fixed daily (24-hour) cycle that you can't change. Only machines that are running during the scan are scanned, so a VM that is always deallocated then never reports.
• Unsupported disks: a VM with any Ultra Disk or Premium SSD v2 disk attached is skipped entirely, and VMs with more than 14 disks aren't supported. If a VM's disks total more than 4 TB, only the OS disk is scanned, and file systems such as ReFS, UFS, ZFS and RAID formats aren't scanned.
• Customer-managed keys: platform-managed-key disks need nothing extra. To copy CMK-encrypted disks, the Defender for Cloud Servers Scanner Resource Provider application needs get, wrap and unwrap on the key: on an RBAC vault assign it Key Vault Crypto Service Encryption User; on an access-policy vault give it those key permissions. The built-in VM Scanner Operator role covers reading disks and creating snapshots, not key access.

When most VMs report and a few don't, the plan and setting are fine; look at the machines (disk types, power state, CMK access) rather than the subscription.

A VM's security type sets its boot-level protection: Standard (no Secure Boot or vTPM), Trusted launch, or Confidential virtual machine. Trusted launch is the default for new Generation 2 VMs and needs a Gen2 image and a supported size, with no extra cost.

Secure Boot and vTPM are independent settings. If a workload needs an unsigned driver or kernel module, clear Enable Secure Boot only; the vTPM stays and keeps protecting keys. Attestation then fails by design whenever Secure Boot is off, raising a recurring alert, and Microsoft's guidance is to suppress that alert for the VM. Switching to the Standard type would remove the vTPM too.

Confidential VMs (for example DCasv5 or ECasv5 sizes) add hardware-based isolation of memory and state from the host and the cloud operator, plus a vTPM and optional confidential OS disk encryption. Choose them only when data in use must be protected; Trusted launch protects boot integrity on ordinary Gen2 sizes.

Upgrading an existing Generation 1 VM to Trusted launch

• The OS and size must support Trusted launch, and the OS disk must be converted to GPT first (for Windows, with MBR2GPT).
• If Azure Backup protects the VM with the Standard policy, move it to the Enhanced policy; Trusted launch can't be enabled under Standard.
• Turn off BitLocker (or other OS-volume encryption) inside Windows before the upgrade and re-enable it afterwards.
• Changing the security type to Trusted launch performs the Gen1-to-Gen2 change in one step; a Gen2 upgrade without Trusted launch isn't supported.

Azure Machine Configuration (formerly guest configuration) is the Azure Policy capability that audits and applies settings inside the operating system of Azure VMs and Arc-enabled servers, such as security baselines, registry values or installed software. Policy assignments deliver the configuration; an agent in the machine evaluates it and reports compliance.

Assignments that stay not started with no guest assignment results usually mean those prerequisites are missing. Azure Monitor Agent is unrelated: it collects logs, it doesn't evaluate configuration.

Assignment modes

For a custom package, the mode is chosen when you generate the policy definition with New-GuestConfigurationPolicy -Mode. Apply modes produce a DeployIfNotExists definition: new or updated machines get the guest assignment automatically, but machines that already exist are brought in only by a remediation task. A Deny effect evaluates Azure Resource Manager requests, so it can't block a setting changed inside the guest; drift inside the OS is corrected by ApplyAndAutoCorrect.