Azure Virtual Machines remain one of the most heavily used IaaS resources in the cloud. They power everything from production workloads and CI/CD runners to data analytics pipelines. But with great flexibility comes a sprawling attack surface, and misconfigurations are still the leading cause of cloud security incidents.
According to multiple industry reports, the majority of cloud breaches stem not from zero-day exploits but from preventable configuration mistakes. This article covers the top 10 Azure VM misconfigurations that security teams and DevOps engineers should actively detect and remediate.
Each misconfiguration below includes an explanation of the risk, how to detect it, and the recommended remediation steps.
What Are Azure Virtual Machines?
Azure Virtual Machines (VMs) are on-demand, scalable compute resources that let you run workloads without buying physical hardware. You choose the OS, configure networking, attach storage, and control the software stack. Azure handles the underlying infrastructure — but the responsibility for configuring VMs securely falls squarely on you under the shared responsibility model.
The Top 10 Azure VM Misconfigurations
1. Trusted Launch Not Enabled
The Risk: Trusted Launch is Azure’s foundational security feature for Generation 2 VMs. It combines Secure Boot, a virtual Trusted Platform Module (vTPM), and boot integrity monitoring to protect against bootkits, rootkits, and firmware-level malware. VMs deployed without Trusted Launch are exposed to attacks that execute before the OS kernel loads; invisible to traditional endpoint protection.
Why It Matters: Microsoft now recommends Trusted Launch as the default for all new VM deployments. The CIS Microsoft Azure Foundations Benchmark v4.0 explicitly calls for Secure Boot and vTPM to be enabled on all virtual machines.
How to Detect:
az vm show --resource-group <rg-name> --name <vm-name> --query "securityProfile"If securityProfile.securityType is not TrustedLaunch, the VM is misconfigured.
Remediation:
- For new VMs: Always select “Trusted Launch” as the security type during provisioning.
- For existing Gen2 VMs: Use the in-place upgrade path to enable Trusted Launch without redeploying.
- Enable Boot Integrity Monitoring via Microsoft Defender for Cloud to receive alerts on boot chain failures.
2. Management Ports Open to the Internet (RDP/SSH)
The Risk: Leaving port 3389 (RDP) or port 22 (SSH) open to 0.0.0.0/0 in your Network Security Group (NSG) rules is one of the most common and dangerous Azure VM misconfigurations. Attackers continuously scan the internet for open management ports and use brute-force and credential-stuffing attacks to gain access.
Why It Matters: Microsoft’s own telemetry shows that VMs with open management ports receive thousands of unauthorized connection attempts per day. A successful breach can give attackers full control over the VM and lateral movement into your network.
How to Detect:
az network nsg rule list --resource-group <rg-name> --nsg-name <nsg-name> \
--query "[?destinationPortRange=='3389' || destinationPortRange=='22'].{Name:name, Access:access, Source:sourceAddressPrefix}"Look for rules where sourceAddressPrefix is * or 0.0.0.0/0 and access is Allow.
Remediation:
- Remove all NSG rules that allow inbound access to ports 22 or 3389 from the internet.
- Enable Just-in-Time (JIT) VM Access through Microsoft Defender for Cloud. JIT keeps management ports closed by default and opens them only for a specified duration, from approved IPs, after an authorized request.
- Use Azure Bastion for browser-based RDP/SSH access without exposing a public IP.
- For programmatic SSH access, consider solutions like Cloudanix VM JIT which provides identity-stamped, time-bound SSH sessions.
3. Missing or Inadequate Disk Encryption
The Risk: Azure managed disks are encrypted at rest by default using platform-managed keys (SSE). However, this alone does not encrypt the VM host cache, temporary disks, or data in transit between the VM and Azure Storage. Without enabling Encryption at Host or using customer-managed keys (CMK), sensitive data may be recoverable from temporary storage or host-level caches.
Why It Matters: Azure Disk Encryption (ADE) using BitLocker (Windows) or dm-crypt (Linux) is being retired on September 15, 2028. Microsoft now recommends migrating to Encryption at Host, which provides end-to-end encryption without guest-OS agents. Organizations still running ADE without a migration plan face a ticking clock.
How to Detect:
# Check if encryption at host is enabled
az vm show --resource-group <rg-name> --name <vm-name> \
--query "securityProfile.encryptionAtHost"
# Check disk encryption status
az vm encryption show --resource-group <rg-name> --name <vm-name>Remediation:
- Enable Encryption at Host on all VMs. This encrypts temporary disks, OS/data disk caches, and ensures data flows encrypted to Azure Storage.
- For compliance-sensitive workloads, use customer-managed keys (CMK) stored in Azure Key Vault with automatic rotation.
- For highly confidential workloads, evaluate Confidential VMs with OS disk confidential encryption.
- Begin migrating ADE-encrypted VMs to Encryption at Host before the 2028 retirement deadline.
4. Azure Backup Not Configured
The Risk: Virtual machines without Azure Backup configured have no recovery point in the event of data corruption, ransomware, accidental deletion, or regional outages. This is not just a data-loss risk, it is a direct threat to business continuity.
Why It Matters: Azure Backup provides application-consistent snapshots, cross-region restore, and integration with soft-delete and immutable vaults to protect against ransomware that targets backup infrastructure. The CIS Azure Foundations Benchmark recommends enabling backup for all production VMs.
How to Detect:
az backup protection check-vm --vm-id $(az vm show -g <rg-name> -n <vm-name> --query id -o tsv)Remediation:
- Enable Azure Backup with a Recovery Services Vault for all production VMs.
- Define backup policies with appropriate retention (daily, weekly, monthly) based on RPO requirements.
- Enable soft delete on the vault to protect backups from malicious deletion (enabled by default with a 14-day retention).
- Enable cross-region restore for disaster recovery readiness.
- Periodically test restore operations to validate backup integrity.
5. Microsoft Defender for Servers Not Enabled
The Risk: Without Microsoft Defender for Servers (part of Microsoft Defender for Cloud), your VMs lack vulnerability assessment, endpoint detection and response (EDR), adaptive application controls, and security recommendations. You are effectively flying blind on threats targeting your compute layer.
Why It Matters: Defender for Servers integrates Microsoft Defender for Endpoint directly into your Azure VMs, providing real-time threat detection, attack surface reduction, and automated investigation. Plan 2 adds agentless vulnerability scanning, file integrity monitoring, and adaptive network hardening. Without it, you have no centralized visibility into VM security posture.
How to Detect: Check in the Azure Portal under Microsoft Defender for Cloud → Environment Settings → your subscription → Defender plans. Verify that “Servers” shows as “On.”
az security pricing show --name VirtualMachines --query "pricingTier"If the result is Free, Defender for Servers is not enabled.
Remediation:
- Enable Defender for Servers Plan 2 at the subscription level for comprehensive protection.
- At minimum, enable Plan 1 for EDR coverage via Microsoft Defender for Endpoint.
- Review and remediate all recommendations surfaced by Defender for Cloud’s Secure Score.
- Enable adaptive application controls to whitelist known-good processes on production VMs.
6. No Managed Identity Assigned (Using Credentials in Code)
The Risk: VMs that access other Azure resources (Key Vault, Storage, SQL Database) using hardcoded credentials, environment variables with secrets, or service principal client secrets stored on disk are a breach waiting to happen. Leaked or exposed credentials are the top initial access vector in cloud attacks.
Why It Matters: Azure Managed Identities eliminate the need to store any credentials on the VM. Azure automatically manages the identity lifecycle, rotates tokens, and provides short-lived OAuth tokens at the Instance Metadata Service endpoint. There are no secrets to leak, rotate, or accidentally commit to source control.
How to Detect:
az vm identity show --resource-group <rg-name> --name <vm-name>If no identity is returned, the VM is not using managed identity.
Remediation:
- Assign a System-assigned Managed Identity to the VM (automatically deleted when the VM is deleted).
- Use User-assigned Managed Identities when the same identity must be shared across multiple VMs.
- Grant the managed identity only the minimum RBAC roles required (principle of least privilege).
- Remove all hardcoded secrets, environment variables, and on-disk credential files from the VM.
- Update application code to use Azure SDK credential chains that automatically pick up managed identity tokens.
7. VM Extensions Installed Without Review
The Risk: Azure VM extensions are small applications that provide post-deployment automation — agent installations, monitoring, diagnostics, and more. Every extension runs with elevated (root/admin) privileges and can access anything on the VM. Unvetted or unnecessary extensions expand the attack surface and can introduce vulnerabilities, exfiltrate data, or serve as persistence mechanisms.
Why It Matters: The CIS Microsoft Azure Foundations Benchmark recommends auditing all installed extensions and removing those not explicitly required. Community or third-party extensions that are no longer maintained can carry unpatched vulnerabilities.
How to Detect:
az vm extension list --resource-group <rg-name> --vm-name <vm-name> -o tableReview the output against your approved extension list.
Remediation:
- Maintain an allowlist of approved VM extensions for your organization.
- Use Azure Policy to deny installation of unapproved extensions (
Microsoft.Compute/virtualMachines/extensionsdeny effect). - Regularly audit installed extensions and remove any that are unused or unrecognized.
- Keep approved extensions updated to the latest versions.
- Consider using Adaptive Application Controls in Defender for Cloud to detect unauthorized software installations.
8. Automatic OS Patching Not Enabled
The Risk: Unpatched VMs are one of the most exploited entry points in any environment. Without automatic patching, VMs accumulate known vulnerabilities that attackers actively exploit — often within days of a CVE disclosure.
Why It Matters: Azure Update Manager (the successor to Azure Automation Update Management) provides a unified patching experience for Azure VMs and Arc-enabled servers. Combined with Automatic VM Guest Patching, Azure can automatically apply Security and Critical patches during off-peak hours with availability-first orchestration — no manual maintenance windows required.
How to Detect:
az vm show --resource-group <rg-name> --name <vm-name> \
--query "osProfile.windowsConfiguration.patchSettings" # Windows
az vm show --resource-group <rg-name> --name <vm-name> \
--query "osProfile.linuxConfiguration.patchSettings" # LinuxCheck that patchMode is set to AutomaticByPlatform and assessmentMode is AutomaticByPlatform.
Remediation:
- Enable Automatic VM Guest Patching for all VMs. Set
patchModetoAutomaticByPlatform. - Enable Periodic Assessment so Azure evaluates patch status every 24 hours.
- For workloads requiring controlled change windows, use Maintenance Configurations in Azure Update Manager to schedule patches during approved times.
- Monitor patch compliance via Azure Update Manager dashboards and set alerts for VMs that miss critical patches.
9. Public IP Assigned Directly to VM
The Risk: Assigning a public IP address directly to a VM exposes it to the internet without any intermediary protection layer. This bypasses Azure Firewall, Application Gateway, and load balancer security features. Combined with weak NSG rules, it creates a directly addressable target for attackers.
Why It Matters: Best practice architectures place VMs in private subnets behind a load balancer, NAT gateway, or Azure Firewall. Direct public IP exposure is rarely necessary and dramatically increases the blast radius if the VM is compromised.
How to Detect:
az vm list-ip-addresses --resource-group <rg-name> --name <vm-name> \
--query "[].virtualMachine.network.publicIpAddresses[].ipAddress"If this returns an IP address, the VM has a directly assigned public IP.
Remediation:
- Remove the public IP from the VM’s NIC unless there is a documented business justification.
- Place VMs behind Azure Load Balancer or Azure Application Gateway for internet-facing workloads.
- Use Azure Bastion for management access instead of public IPs.
- Use Azure NAT Gateway for outbound internet access from private VMs.
- If a public IP is required, apply restrictive NSG rules and enable DDoS Protection Standard on the VNet.
10. Using Non-Standard or Premium SKUs Without Cost-Performance Justification
The Risk: This is both a cost misconfiguration and a security-adjacent issue. VMs running on Premium SSD when Standard SSD is sufficient waste budget that could be allocated to security tooling. Conversely, using Standard HDD for mission-critical workloads introduces performance risks that can lead to availability failures and SLA breaches.
Why It Matters: Properly sizing VMs and choosing appropriate disk tiers is a governance discipline. Over-provisioned VMs are often neglected in patching and monitoring (because “they’re expensive enough to be important”). Under-provisioned VMs may experience IO throttling that causes application failures interpreted as attacks.
How to Detect:
az disk list --resource-group <rg-name> \
--query "[].{Name:name, SKU:sku.name, Size:diskSizeGb}" -o tableReview disk SKUs against workload performance requirements.
Remediation:
- Audit all VM disk SKUs quarterly. Use Standard SSD for general-purpose workloads where consistent performance at lower IOPS is acceptable.
- Reserve Premium SSD or Ultra Disks only for mission-critical, latency-sensitive workloads (databases, real-time analytics).
- Use Azure Advisor cost recommendations to identify over-provisioned or idle VMs.
- Implement Azure Policy to enforce approved VM sizes and disk SKUs per environment (dev/staging/prod).
- Right-size VMs using Azure Monitor metrics (CPU, memory, disk IO utilization patterns).
How Cloudanix Helps
Detecting and remediating Azure VM misconfigurations manually is time-consuming and error-prone, especially across multiple subscriptions and resource groups. Cloudanix provides automated, continuous posture assessment for your Azure environment, including all the misconfigurations covered in this article.
With Cloudanix, you can:
- Detect misconfigurations in real time: Continuous monitoring across your Azure VMs flags issues like open management ports, missing encryption, and disabled Trusted Launch the moment they appear.
- Audit against CIS Azure Foundations Benchmark: Pre-built rules mapped to CIS v4.0, Azure Security Benchmark, and other compliance frameworks.
- Auto-remediate with confidence: One-click and automated remediation workflows fix misconfigurations before they become incidents.
- Visualize blast radius: Understand which resources are downstream of a misconfigured VM using Cloudanix’s attack path analysis.
Explore Cloudanix’s Azure VM and compute security audits:
Start a free trial and secure your Azure VMs in minutes.
Conclusion
Azure VM misconfigurations are not exotic edge cases. They are the common, everyday mistakes that lead to breaches, data loss, and compliance failures. The ten issues covered here represent the most impactful findings that security teams should prioritize:
- Enable Trusted Launch on all Gen2 VMs.
- Lock down management ports with JIT access.
- Implement end-to-end disk encryption.
- Configure Azure Backup for every production VM.
- Enable Microsoft Defender for Servers.
- Use Managed Identities instead of stored credentials.
- Audit and control VM extensions.
- Automate OS patching.
- Avoid direct public IP assignment.
- Right-size VMs and storage tiers.
A CSPM tool like Cloudanix gives you continuous visibility into these risks across your entire Azure estate, and helps you remediate them before attackers exploit them.
People Also Read
- Top 15 Cloud Misconfigurations in 2026 - How to Fix Them?
- Top 13 AWS EC2 Misconfigurations To Avoid in 2022
- A Complete List of AWS S3 Misconfigurations
- How to use CSPM to detect and remediate cloud misconfigurations
- Top 18 Challenges of Cloud Security in 2026
- Top 10 Challenges of Cloud Security Posture Management
- Configuration Drift Management: How to Detect Cloud Drift Before It Becomes an Incident
- CSPM vs. CNAPP: Navigating Cloud Security Evolution
