Azure Security Fundamentals

Reviewed by the Fully Compliance editorial team

Short answer: Azure provides the cloud platform, but securing what you build on it is entirely your responsibility. Security starts with identity management through Microsoft Entra ID and least-privilege RBAC, extends through restrictive network security groups and hardened virtual machines, and requires active use of Defender for Cloud and Azure Policy. Default configurations are permissive, not secure — intentional configuration is mandatory.

Azure is Microsoft's infrastructure-as-a-service platform, and it gives you the flexibility to build nearly anything on it. That flexibility is also a responsibility. You can spin up virtual machines, create databases, build containerized applications, and have a full environment running in hours. What takes much longer is understanding how to secure it. According to Gartner, through 2025, 99% of cloud security failures are the customer's fault — and Azure is no exception. Organizations deploy infrastructure in Azure thinking that being in Microsoft's cloud automatically makes them secure. It doesn't. Security starts at the foundation — identity and access management — and flows through every layer you build. Get that foundation wrong and everything above it is compromised.

Identity Management Is the Single Most Important Layer

Azure security begins with identity. Every user, application, and service that interacts with Azure has an identity, and permissions are attached to that identity. Identity management in Azure happens through Azure Active Directory — now called Microsoft Entra ID — the same system that powers Microsoft 365. Through Entra ID, you define who users are and what permissions they have using role-based access control, called RBAC.

RBAC works by assigning roles to users, and roles grant specific permissions. A virtual machine contributor role can create and manage virtual machines. A reader role can view resources but can't create or modify anything. You can create custom roles for specific needs. The critical principle is least privilege: every identity gets the minimum permissions needed to do their job, nothing more. Additional permissions are granted only when explicitly requested and justified.

In practice, many organizations make everyone with any administrative responsibility a subscription owner, the highest permission level in Azure. This creates a massive security gap. If anyone with owner permissions gets compromised — their account is stolen, their credentials are exposed, they're socially engineered — the attacker has full access to everything in that subscription. Instead, assign owner permissions carefully and sparingly. Use contributor roles for people who need to manage resources. Use reader roles for people who need to see what exists but not change it. Create custom roles when you need specific permission sets. This approach is more work upfront but creates a significantly more secure environment.

A practical structure: subscription owners are a small group of senior IT leadership, never used for day-to-day work. Resource group owners manage specific groups of related resources. Contributors manage specific types of resources. Readers have visibility but no modification rights. Every user falls into one of these categories based on what they actually need to do. When someone's role changes, their permissions change immediately. When someone leaves the organization, you disable their identity and they lose all access.

Network Security Groups Are Your Perimeter — Treat Them That Way

Once identities are managed, network security is the next layer. Azure virtual networks are your network infrastructure. You create virtual networks, define IP address ranges within them, create subnets, and attach resources to those subnets. Virtual networks isolate your resources from each other and from the public internet by default, which is good. You then control what traffic can flow in and out through network security groups, which are essentially firewalls with inbound and outbound rules.

A network security group rule might allow HTTP and HTTPS from the internet to a web server — that traffic is necessary for your application. But you'd also want to block SSH (remote terminal access) except from your office IP address. A rule allowing SSH from anywhere on the internet means attackers can try to break into that server. The guiding principle should be zero trust: assume nothing is trusted by default, require explicit allow rules. Everything is blocked except what you specifically allow.

In practice, many organizations start with permissive network security groups because restrictive rules are harder to design initially. You don't know exactly what needs to access what, so you make broad rules. This is a security gap that often goes unnoticed until a breach happens. Start restrictive — only allow what you know is needed — and add exceptions as required. Document why each exception exists. Review your rules regularly. As your infrastructure evolves and services move or change, old rules might still be in place allowing access that's no longer needed.

Beyond network security groups, Azure also offers Network Access Control Lists — NACLs — which provide additional network-layer control at the subnet level. Most organizations rely on security groups and skip NACLs. For additional defense, configure both. The effort to set up both properly is worth the reduced attack surface.

Virtual Machine Security Is Your Responsibility From the OS Up

Virtual machines in Azure are your responsibility to secure from the operating system upward. This is where many organizations stumble. The platform provides the virtual machine, but securing it is your job. Patching is your responsibility. If a security vulnerability exists in the operating system and you don't install the patch, that's on you. Backups are your responsibility — Azure can store them, but you have to configure them. Monitoring is your responsibility. Hardening is your responsibility.

The 2024 Verizon DBIR found that exploitation of vulnerabilities as an initial access path increased 180% year-over-year — and unpatched VMs with public exposure are a primary target. Azure provides tools to make patching easier. Update Management automates patch deployment if you configure it. Desired State Configuration lets you define how a server should be configured and automatically enforces that configuration. But these tools exist only if you enable and configure them. Organizations that deploy virtual machines, skip auto-patching, and leave those VMs running for months with known vulnerabilities are creating open doors for attackers.

Beyond patching, hardening includes removing unnecessary services. If a virtual machine doesn't need RDP (remote access), disable it. Every running service is a potential attack surface. Unnecessary services are security gaps. Manage local access carefully. If the VM has local user accounts, use strong credentials. Encrypt sensitive data stored on the VM. Azure provides managed disks with built-in encryption, which should be enabled. You cannot deploy a virtual machine and expect it to be secure just because it's in Azure. The platform provides the foundation, but building something secure on that foundation is your responsibility.

Storage Accounts Need Access Control and Encryption — Not Public Exposure

Azure Storage Accounts hold your data — files, blobs, databases. Securing them means controlling who can access them and encrypting the data. Access control uses Azure AD identities or access keys. The best practice is using Azure AD identities whenever possible, because then access is managed through your identity system. Never hardcode storage account keys directly in applications. Instead, use managed identities, which allow an application running in Azure to authenticate to storage without any credentials embedded anywhere.

Encryption comes in two flavors. Azure-managed encryption is straightforward — Azure handles the encryption keys. This is secure and requires minimal configuration. Customer-managed encryption gives you control over the encryption keys. You manage the keys and can prevent Azure from accessing your data if needed. This provides additional control but adds operational complexity. For most organizations, Azure-managed encryption is appropriate.

A common security gap is public access. Blob storage can be configured to allow public read access, which is useful for some scenarios like serving images for a website. But it's easy to misconfigure. Someone creates blob storage for a temporary data transfer, forgets to restrict public access, and sensitive data is exposed to the internet. Public access should be the exception, not the default. Assume storage accounts should be private. Explicitly allow access for what needs it. Review your storage accounts regularly to verify they're not unintentionally public.

Defender for Cloud and Azure Policy Give You Visibility and Enforcement

Azure provides Security Center — now part of Defender for Cloud — which monitors your Azure resources for security issues. It identifies virtual machines without current patches, storage accounts with public access, network security groups that are overly permissive, and other misconfiguration. Security Center provides recommendations and can sometimes auto-remediate issues. This visibility is valuable because it shows you your security posture across resources.

But Security Center is a tool that identifies problems. It doesn't automatically fix everything. You have to act on its recommendations. Some organizations enable Security Center, get bombarded with recommendations, and don't know where to start. The approach is to prioritize: focus on high-risk findings first, work through them systematically, remediate. As you fix issues, your security posture improves. Security Center also integrates with Azure Defender, which provides threat detection on top of configuration assessment.

Azure Policy enforces governance rules. You can define policies like "all virtual machines must have encryption enabled" or "all network security groups must deny all inbound access by default." Azure Policy automatically prevents configurations that violate policies. This prevents compliance drift where resources gradually become misconfigured over time. You define the policy, Azure enforces it. This requires initial planning — you need to determine what compliance means for your organization — but once defined, enforcement is automatic.

Proportional Security Beats Uniform Security

Some security features in Azure have costs. Extra storage for encrypted keys, Security Center licensing, managed identities, application gateways that provide additional security. For small deployments, these costs are negligible. For large deployments, they can be significant. The Ponemon Institute's 2024 Cost of a Data Breach report found the average breach cost reached $4.88 million — making security investment a clear financial imperative, not just a best practice. A breach costs exponentially more than security tools.

A development environment where developers experiment with new technologies doesn't need the same security as production systems handling customer data. Tailor your security investment to what you're protecting. Use strong authentication and least-privilege access everywhere. Apply encryption to sensitive data. Monitor for security issues. But don't require the same level of scrutiny and cost for development that you require for production. Proportional security is the right approach.

Resource Organization Enables Scalable Access Control

Azure hierarchy enables least-privilege access at scale. Resources are organized into subscriptions, which are billing boundaries and also access boundaries. You can assign different teams to different subscriptions, and their access is limited to their subscription. Within subscriptions, resources are organized into resource groups. You might have a resource group for production applications, another for development, another for testing. This hierarchy lets you grant teams access to what they need without giving everyone access to everything.

Azure Policy operates across subscriptions and resource groups. You can enforce tagging standards so costs can be allocated, enforce compliance with standards, prevent non-compliant resources from being created. This requires planning upfront — you need to determine your organizational structure and compliance requirements — but once established, it provides ongoing enforcement and visibility.

Security Is Foundational, Not Automatic

Azure security starts with understanding that Azure provides the platform, but you're responsible for securing what you build on it. Start with identity and access management — every identity gets minimum permissions needed. Configure network security restrictively. Harden virtual machines through patching and configuration. Secure storage accounts and encrypt data. Use Defender for Cloud and Azure Policy for visibility and compliance enforcement. None of these are complicated individually, but implementing them correctly across your Azure environment requires planning and execution.

When something goes wrong in Azure — a resource is compromised, data is lost, performance suffers — the responsibility is on your shoulders. Azure provides the tools, but you have to use them correctly. Approach Azure security with the assumption that the default configuration is not secure. Understand explicitly what you're responsible for. Execute intentionally on that responsibility. Get identity and access management right, and the rest of security becomes easier.

Frequently Asked Questions

Is my data automatically secure because it's in Azure?
No. Azure secures the physical infrastructure — data centers, hypervisors, network backbone. Everything from the operating system upward, including access controls, patching, encryption configuration, and network rules, is your responsibility. Default configurations are permissive, not hardened.

What is the most important Azure security control to get right first?
Identity and access management through Microsoft Entra ID. Implement least-privilege RBAC, restrict subscription owner access to a small group of senior IT leaders, and enforce multi-factor authentication for all accounts. Every other security control depends on a solid identity foundation.

How does Azure Defender for Cloud help with security?
Defender for Cloud continuously monitors your Azure resources for misconfigurations — unpatched VMs, public storage accounts, overly permissive network rules — and provides prioritized recommendations. It also integrates threat detection to identify active attacks. You still have to act on its findings, but it provides the visibility needed to understand your security posture.

Should I use Azure-managed encryption or customer-managed keys?
Azure-managed encryption is appropriate for most organizations and requires minimal configuration. Customer-managed keys are necessary when compliance mandates that your organization, not Microsoft, retains sole control over encryption keys. The added operational complexity of customer-managed keys is justified only when regulatory requirements demand it.

How do I prevent Azure configuration drift over time?
Use Azure Policy to define and enforce governance rules automatically. Policies can prevent non-compliant resources from being created — for example, requiring encryption on all VMs or blocking public access on storage accounts. Combined with regular Defender for Cloud reviews, this prevents gradual misconfiguration that creates security gaps.

Fully Compliance provides educational content about IT compliance and cybersecurity. This article reflects general information about Azure security fundamentals as of its publication date. Azure capabilities, features, and best practices evolve — consult with qualified cloud security architects for guidance specific to your environment and requirements.