Azure Cloud Security: The Critical Vulnerabilities You’re Responsible For

It’s easy to assume that cloud security is “baked in” when using a provider like Microsoft Azure. But that misconception can leave serious security gaps. 

While Microsoft secures the physical servers in the datacenter, everything within an Azure environment - like sensitive data, applications, and access controls - is the customer’s responsibility. 

This guide walks through where your responsibility starts, what can go wrong, and how to avoid some common pitfalls.

Azure’s Shared Responsibility Model

Like most cloud providers, Azure has its own Shared Responsibility Model - a framework that outlines the division of security responsibilities between the customer and Microsoft. Microsoft is responsible for managing some elements of security for you, and you are responsible for others.

The table below shows the responsibilities split out between Microsoft and the customer, based on what type of service you are using.

SaaS

For SaaS services, Microsoft bears the most responsibility for security. An example of this type of service would be using Microsoft 365. In this scenario, Microsoft is responsible for securing web applications such as Outlook Web and Office 365 - but you are still responsible for securing the information and data those applications contain. If for example you add sensitive data to an Excel sheet, make it publicly shareable with anyone, and accidentally share that link - that’s your responsibility. 

PaaS

An example of a Platform-as-a-Service (PaaS) product is the Azure App Service. This service allows developers to build web apps or APIs without having to manage the infrastructure themselves. Notice that for this type of service, the security of the operating system (OS) is solely Microsoft’s responsibility. This service removes the need to build, scale and maintain servers that are running the application. Since this is all managed by Microsoft, they are clearly the ones who are responsible for vulnerabilities in the OS, such as updating packages in use which have known vulnerabilities.

IaaS

In contrast, an Infrastructure-as-a-Service (IaaS) product like Azure Virtual Machines (VMs) is a service where the customer manages VMs in the cloud, which includes the initial build and ongoing maintenance of all software on the server. Notice that for this type of service, the responsibility of the OS lies with the customer, so it’s up to you to keep the packages and software up to date.

On-prem

The final column in the table is on-prem, meaning you are hosting your own servers in your own datacenters or offices - Microsoft clearly has no responsibility here, you’re on your own!

Vulnerabilities You Are Responsible For in Azure

Let’s look at some vulnerabilities and misconfigurations that are the customer’s responsibility and what you can do to mitigate them.

The following examples focus on several key areas of Azure’s Shared Responsibility Model:

• Accounts and Identities
• Applications
• Network Controls
• Operating System

Accounts and Identities - Entra Policy and Access Controls

Azure Entra is Microsoft’s identity and access management (IAM) solution for your Azure tenant. It provides the customer with fine-grained controls for determining which resources within your tenant and its underlying subscriptions each user should have access to.

Microsoft is responsible for making sure those controls are robust and can’t be bypassed, but the customer is responsible for ensuring that users are not provided with permissions that overreach their responsibilities, and that their accounts are appropriately secured.

On the tenant-level, there are many key security policies which should be in place, such as: 

• Enforcing multi-factor authentication (MFA)
• Restricting who can invite guest accounts
• Ensuring that new accounts have minimal access to resources by default
• Restricting users from providing Entra data to untrusted applications without approval.

Your tenant can be as locked down or as open as you like, and many Entra defaults are overly permissive compared to best practices. Intruder’s cloud security solution for Azure provides detection for these types of mistakes, so you can continuously monitor and fix them as they occur. 

Managing which users can access resources within an Azure subscription, and which resources should be public, is also your responsibility. Azure Storage Account is a good example, where certain resources may be intended to be public and allow anonymous access (like media files), whereas others contain sensitive files which should only be accessible to specific internal users.

Azure provides the capability to lock down stored files or to make them fully public, and the responsibility sits with the customer to configure this correctly and monitor for mistakes.

Applications

With the exception of SaaS applications like Office 365, you are generally responsible for the security of your applications and the data they provide access to. Even when you are using a PaaS managed service like Azure App Service or Azure Functions, things can still go wrong in ways that aren’t Microsoft’s responsibility.

Take an example where you’ve deployed an API using Azure Functions which is publicly exposed. If an attacker discovers the API, enumerates its endpoints and discovers authorization weaknesses that provide access to sensitive data, this sits firmly within your security responsibilities. Though Microsoft should have you covered against infrastructure weaknesses, weaknesses in the code and functionality you deploy remains your responsibility. Intruder’s bug hunting team recently saw this exact vulnerability in an Azure Functions API - so watch out!

To protect against application layer weaknesses, regular web layer vulnerability scanning is recommended. Manual penetration tests are also essential on your most sensitive applications, to catch additional weaknesses that automated scanners miss.

Network Controls - Firewalls and Attack Surface

You control your own attack surface in Azure. That means deciding whether to place services behind private Azure Virtual Networks or leave them exposed to the internet.

For example, if you deploy a Splunk server on an Azure Virtual Machine, it’s your responsibility to secure it. This means layering it behind a VPN, using a firewall to block access from arbitrary hosts, and/or placing it inside a private network where it doesn’t have a public IP address using Azure Private Link. If a new zero-day vulnerability in Splunk drops tomorrow and your server is publicly exposed, you’ll quickly regret leaving it on the internet - and it won’t be Microsoft’s fault!

Intruder’s Enterprise plan helps customers mitigate this issue in three ways:

• Highlighting panels that shouldn’t be exposed
• Providing a holistic view of your external ports and services
• Detecting permissive firewall rules within Azure

That means no surprises, and no getting caught out, because you already took that sensitive server or panel off the internet.

Operating System - Patch Management

When you’re using an IaaS feature like Azure Virtual Machines, Microsoft will not patch your servers for you. If you deploy VM instances, the operating system and any software the server is running will develop vulnerabilities over time. Microsoft handles patching the firmware and keeps the hardware that your server is running on up to date, but the OS and software layers are your responsibility.

For example, if you deploy a machine running Windows Server 2025 that’s hosting your Gitlab Server, you are responsible for ensuring that Windows security patches are deployed, and for keeping your Gitlab version up to date and patched against the latest vulnerabilities. In this case, agent-based vulnerability scanning would help you find these issues. 

If regularly monitoring and patching software is too much of a burden for your organization, you could consider using a PaaS service instead, where Microsoft handles this for you. For example, instead of deploying your own Virtual Machine via Azure VMs and installing SQL Server - where you would be entirely responsible for patching - you could use the Azure SQL Database PaaS service. This can be configured to manage upgrades, security patches, and backups automatically - leaving the responsibility firmly in Microsoft’s court.

Azure Cloud Security: What It All Comes Down To

These are just a few examples of the common security gaps teams face in Azure - and they all point to one thing: Microsoft handles the infrastructure, but what happens inside your cloud environment is up to you.

That’s why having continuous visibility into your Azure security posture is so important - and exactly where Intruder can help.

Simple, Powerful Security For Azure

Intruder removes the complexity of managing your security responsibilities in Azure, combining cloud security, vulnerability management, and attack surface management in one powerful platform.

• Continuous protection: Daily, automated cloud scans detect misconfigurations, insecure permissions, exposed secrets, and more.
• Cut through the noise: Intruder doesn’t overwhelm you with alerts - it highlights the real issues that put your business at risk.
• Fixes made simple: No jargon - just clear explanations and actionable guidance to remediate issues fast.

Cloud Security is included in Cloud, Pro, and Enterprise plans at no extra cost. Check your Azure security today by starting a free trial.