VM Security: Disk Encryption, Bastion, JIT, Secure Boot…

VM hardening in one module

Simple explanation

Azure VMs are still the workhorse for plenty of production systems — and SC-500 expects you to lock them down end-to-end. Five controls show up over and over on the exam:

Disk encryption — every disk encrypted at rest, using platform-managed keys by default and customer-managed keys (CMK) or confidential disks for higher-assurance scenarios.
Azure Bastion — the managed jump-host that lets admins RDP/SSH into VMs through the Azure portal over TLS, with no public IP on the VMs themselves.
Just-in-time (JIT) VM access — VMs are not reachable on management ports until an admin requests time-bounded access; the NSG opens for the configured port for the configured duration.
Trusted Launch features — secure boot (firmware verifies the OS bootloader), virtual TPM (a vTPM device for in-guest attestation and key sealing), and integrity monitoring (detection of boot-time tampering). Combined under the VM “security type” setting.
Azure Machine Configuration — Azure Policy’s in-guest configuration extension: define desired OS configurations (e.g. “Windows password policy at least 14 chars”, “TLS 1.2 minimum”) and have Azure audit or enforce them across hundreds of VMs.

Disk encryption — three flavours to know

Disk encryption options on Azure — pick by assurance level and key custody requirements
Encryption type	Where keys live	Best for
Platform-managed keys (PMK)	Microsoft-managed inside Azure	Default — covers all managed disks at rest with zero configuration
Customer-managed keys (CMK) via Key Vault	Customer Key Vault (Standard or Premium HSM); rotation by customer	Regulated workloads requiring CMK; central key control via Key Vault rotation policy
Encryption at host	Platform-managed or CMK; encryption happens on the host hypervisor before data reaches storage	When you also need to encrypt the ephemeral cache, temp disk, and intra-VM volumes — full coverage including cache that PMK alone misses
Azure Disk Encryption (ADE)	In-guest BitLocker (Windows) or DM-Crypt (Linux), keys in Key Vault	Legacy compatibility; new deployments prefer host-side encryption + CMK
Confidential disks (on confidential VMs)	Keys bound to the TEE (TPM-backed); cannot leave the encrypted environment	Confidential VM workloads where encryption-in-use is required

For SC-500, the most-tested combination is CMK + encryption at host for regulated environments where the customer must own the key AND the encryption must extend to the host-level cache.

Azure Bastion — kill the public IP on management ports

The “before Bastion” pattern: VMs have public IPs, RDP/SSH ports open to the internet (or to a corporate VPN range), and admins connect directly. Every public IP is a target for brute-force and credential-stuffing scanners.

The “with Bastion” pattern:

VMs have no public IPs.
Azure Bastion is deployed in a dedicated AzureBastionSubnet in the VNet.
Admins connect via the Azure portal (or the Bastion-native client) over TLS to Bastion; Bastion establishes the RDP/SSH session to the VM over the VNet.
NSG rules allow Bastion → VM management ports; nothing else can reach those ports.

Bastion SKUs

Developer — for dev/test, single-VM, single-region; not for production
Basic — production-grade RDP/SSH from portal
Standard — adds native client support, host scaling, IP-based connection, peer VNet connectivity, custom port configurations
Premium — adds session recording, private-only Bastion (no public IP on Bastion itself, accessible via Private Endpoint), and other regulated-environment features

For SC-500, know that Premium is the SKU when you need session recording and a Bastion that doesn’t itself have a public IP.

Just-in-time (JIT) VM access

JIT is a Microsoft Defender for Cloud (Defender for Servers plan) feature. With JIT:

Management ports (3389, 22) on covered VMs are closed by default in the NSG.
An authorised user requests access via Defender for Cloud (or the JIT API), specifying:
- Which port(s) to open
- How long (typical 3 hours, up to 24)
- Source IP (their current IP)
Defender for Cloud verifies RBAC and (configurable) Conditional Access, then adds a time-bounded NSG rule allowing the request.
When the time expires, the rule is removed automatically.
Every request is audited with user, source IP, duration, port, justification.

JIT requires Defender for Servers

JIT is a Defender for Servers Plan 2 feature (Plan 1 doesn’t include it). The covered VMs must be onboarded to Defender for Cloud, which uses Microsoft Defender for Endpoint integration on the VM where applicable.

Trusted Launch and confidential VMs

Trusted Launch is a Generation-2-VM security profile that ships three boot-time integrity features:

Secure boot — UEFI firmware validates the boot loader and kernel signatures against Microsoft (or platform) signing keys before booting. Rejects unsigned or untrusted boot components.
Virtual TPM (vTPM) — virtualised TPM 2.0 device. Allows in-guest attestation, key sealing, BitLocker autounlock, Microsoft Defender for Endpoint sensor enrolment with verified boot integrity.
Integrity monitoring — when Defender for Servers is enabled, deviations in boot-time integrity raise alerts in Defender for Cloud.

These are surfaced as the VM’s security type setting: Standard (none), Trusted launch virtual machines (secure boot + vTPM + integrity monitoring), or Confidential virtual machines (Trusted Launch + hardware-based TEE encryption-in-use via AMD SEV-SNP or Intel TDX).

When 'Trusted Launch' is the right exam answer

SC-500 questions that hint at:

“Detect changes to the boot loader / kernel”
“Detect bootkit / rootkit installation”
“Verify integrity at boot”
“Bind BitLocker key release to a verified boot”

…are pointing at Trusted Launch — specifically the virtual TPM and integrity monitoring combination. If the question further specifies encryption-in-use against the hypervisor / Microsoft operator, escalate the answer to Confidential VM.

Wrong answers often suggest Defender for Servers alone or guest agents — Defender extends the detection surface, but the underlying boot-integrity primitives are Trusted Launch features that must be enabled on the VM’s security type at deployment (or by re-imaging for some configurations).

Azure Machine Configuration — in-guest enforcement

Azure Machine Configuration is the in-guest configuration management built into Azure Policy. It can:

Audit an in-guest configuration (e.g. “Windows password policy minimum length is at least 14”) and report compliance per VM.
Configure (“DeployIfNotExists” pattern but for guest OS) — apply the configuration to non-compliant VMs.
Cover Windows and Linux, both Azure-native VMs and Azure Arc-enabled servers (on-prem and other clouds).

Built-in policy definitions cover common Microsoft Cloud Security Benchmark (MCSB) in-guest controls. Custom Machine Configuration packages can extend coverage to your own configurations (delivered as PowerShell DSC v3 modules).

For SC-500, Azure Machine Configuration is the “how do I enforce in-guest settings consistently across a fleet” answer.

Scenario: Asha hardens Aurora’s regulated VM fleet

Aurora Health Service has ~120 VMs hosting hospital information systems across two regions. Asha’s hardening plan:

Disk encryption — every VM uses encryption at host with customer-managed keys in a regional Key Vault (Premium tier, HSM-backed). CMK rotation policy: annual auto-rotation with 30-day grace.
No public IPs on VMs, full stop. All admin access via Azure Bastion (Premium SKU) for session recording and private-only Bastion endpoint. Bastion subnet AzureBastionSubnet per VNet, peered to all spoke VNets.
JIT VM access enabled via Defender for Servers Plan 2 on all 120 VMs. Default JIT policy: 3389 (Windows) and 22 (Linux) closed by default; max activation 3 hours; requires JIT-Admin RBAC role + CA-required compliant device.
Trusted Launch + Trusted launch virtual machines security type on all VMs. Confidential VMs (AMD SEV-SNP) for the patient-records workloads where encryption-in-use is required (~15 VMs).
Azure Machine Configuration assignments at the management group:
- Built-in initiative Audit Windows machines on which the password policy doesn’t meet requirements — apply-mode auto-remediation.
- Built-in initiative Audit Windows machines that don’t have the specified Windows PowerShell execution policy — audit, alert.
- Custom DSC v3 module enforcing the hospital’s required TLS 1.2-minimum on outbound HTTPS clients.
Defender for Servers Plan 2 on the subscription enables JIT + integrity monitoring + Defender for Endpoint integration + agentless scanning of the VM disks (next module).

After rollout: zero public IPs on VMs, every admin session is recorded, JIT auditable per-request, disks encrypted with rotating CMKs, boot integrity validated, in-guest configurations enforced and audited.