Azure Security Best Practices: A Complete Configuration Guide for 2026
Microsoft Azure operates under a shared responsibility model: Microsoft secures the physical infrastructure, hypervisor, and underlying platform services, but the configuration of everything you deploy inside Azure is your responsibility. That boundary is where most Azure security incidents originate. Misconfigured identities, overly permissive network rules, unencrypted data stores, and absent monitoring are not platform failures; they are configuration choices that expose workloads to attack.
This guide covers the configuration controls that Microsoft and the security community consistently identify as highest-impact across the layers of an Azure environment: identity and access management, network security, data protection, monitoring and threat detection, governance and compliance, container security, and DevSecOps integration. The goal is not to replicate Microsoft documentation but to distill the practitioner-level decisions that matter most when you are building or hardening an Azure environment under real operational constraints.
Identity and Access: Entra ID, PIM, and Conditional Access
Identity is the most common attack vector in Azure environments. The Microsoft Digital Defense Report consistently identifies credential compromise and identity misconfiguration as the root cause of the majority of Azure security incidents. Securing identity means enforcing MFA universally, limiting standing privilege, and implementing Conditional Access policies that evaluate risk signals before granting access to resources.
Microsoft Entra ID Conditional Access policies are the primary mechanism for enforcing context-aware authentication requirements. At minimum, every production environment should have a policy requiring MFA for all users when accessing Azure portal and Microsoft 365 resources, a policy blocking legacy authentication protocols (Basic Auth, IMAP, POP3) which cannot satisfy MFA challenges, and a policy requiring compliant or Hybrid Azure AD joined devices for administrator access. Microsoft Entra ID Protection provides risk-based Conditional Access policies that automatically step up authentication requirements when the sign-in risk score is elevated based on signals like anonymous IP, atypical travel, or leaked credentials.
Privileged Identity Management (PIM) eliminates standing administrative privilege by converting permanent role assignments to eligible assignments that require activation. When a user needs to perform an administrative action, they activate their eligible role through PIM, triggering an approval workflow if configured, receiving a time-limited active assignment (typically 1-8 hours), and generating an audit record of the activation. PIM is available for both Azure RBAC roles and Microsoft Entra ID directory roles. Organizations using PIM typically reduce standing Owner and Global Administrator assignments to near zero for human accounts, reserving permanent assignments only for break-glass emergency accounts.
For application and service identities, Managed Identities are the preferred authentication mechanism over service principals with client secrets. Managed Identities are automatically provisioned and managed by Azure, with token rotation handled by the platform and no secrets that can be exfiltrated. System-assigned Managed Identities are tied to a specific resource's lifecycle; user-assigned Managed Identities can be shared across multiple resources. Service principals with client secrets should be used only when Managed Identities are not supported, and in that case the secrets should be stored in Key Vault, rotated on a defined schedule, and never committed to source code repositories.
Network Security: NSGs, Azure Firewall, and DDoS Protection
Azure network security operates in layers. Network Security Groups provide stateful packet filtering at the subnet and NIC level, while Azure Firewall provides centralized layer-7 inspection with application-level filtering, threat intelligence, and TLS inspection. DDoS Protection Standard adds volumetric attack mitigation. Together these layers implement network defense in depth for Azure workloads.
NSG design should follow a deny-all default posture: the built-in DenyAllInBound default rule blocks all inbound traffic unless explicitly allowed by higher-priority rules. Teams frequently undermine this posture by adding AllowAnyAnyInbound rules with broad source ranges during troubleshooting and failing to remove them afterward. NSG rule reviews should be part of periodic security assessments, with particular focus on rules allowing port 22 (SSH), 3389 (RDP), or database ports from source 0.0.0.0/0. Azure Security Center (now Defender for Cloud) automatically flags internet-exposed management ports as high-severity recommendations.
Azure Firewall should be deployed in a hub VNet in a hub-and-spoke topology, with all spoke VNets routing internet-bound and cross-spoke traffic through the hub. Azure Firewall Premium adds IDPS signatures, TLS inspection, and URL filtering beyond the Standard tier's FQDN and IP-based rules. Private Endpoints are the correct mechanism for eliminating public internet exposure of PaaS services: by creating a Private Endpoint for a storage account, Key Vault, SQL Database, or other PaaS service, you bind the service to a private IP address in your VNet, making the public endpoint unnecessary. Organizations should combine Private Endpoints with network rules that deny public network access at the service level.
Azure DDoS Network Protection (formerly DDoS Standard) provides adaptive tuning based on your specific application's traffic baselines, automatic attack mitigation, telemetry during attacks, and access to the DDoS Rapid Response team. It is priced per protected VNet per month and covers all resources in the VNet. For public-facing applications processing significant traffic or handling regulated data, DDoS Network Protection reduces the operational risk of volumetric attack impact. Basic DDoS protection is built into the Azure platform at no charge but provides no application-specific tuning or attack telemetry.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Data Protection: Encryption, Key Vault, and Storage Security
Azure encrypts all data at rest by default using AES-256 with Microsoft-managed keys. This default encryption protects against physical media theft but provides no protection against a threat actor who has obtained valid Azure credentials to access the data. Customer-managed keys (CMK) via Azure Key Vault add an additional control layer: the encryption keys are stored and managed in Key Vault under your control, meaning that revoking a key or restricting Key Vault access can prevent data access even by someone with storage or database credentials.
Azure Key Vault stores secrets, keys, and certificates and provides a centralized, audited access control point for sensitive configuration values. Key Vault access policies (the legacy model) grant a principal access to all secrets, keys, or certificates in a vault; the newer RBAC-based access model is preferred because it allows fine-grained role assignments at the individual secret level and integrates with Microsoft Entra ID Access Reviews for periodic review. Applications should be granted only the specific operations they need: a web application retrieving a database connection string needs SecretGet and SecretList permissions, not the full SecretsOfficer role. Enable Key Vault soft delete and purge protection on all production vaults; purge protection prevents permanent deletion of keys and secrets for the configured retention period even by vault administrators, which is critical for recovering from ransomware or accidental deletion.
Storage account security requires several baseline controls applied at account creation rather than retrofitted later. Public network access should be disabled or restricted to specific VNets. The Secure Transfer Required setting rejects unencrypted HTTP connections and requires HTTPS or SMB with encryption. Allow Blob Public Access should be disabled at the account level so that no container within the account can be configured for anonymous public access regardless of container-level settings. Blob soft delete retains deleted blobs for a configurable period (recommend 30 days minimum) enabling recovery from accidental deletion or ransomware encryption that targets blob data.
For secrets in application code, the non-negotiable baseline is that no credentials, connection strings, API keys, or certificates should ever be committed to source code repositories. Azure Key Vault References allow Azure App Service and Azure Functions to retrieve secrets directly from Key Vault using Managed Identity authentication without the secret ever appearing in application configuration files or environment variables in plaintext. GitHub Advanced Security and Azure DevOps secret scanning detect common credential patterns in commits and pull requests before they reach the repository history.
Monitoring and Threat Detection: Defender for Cloud and Sentinel
Defender for Cloud provides two core functions: cloud security posture management (CSPM) through the secure score and recommendations system, and cloud workload protection (CWPP) through the workload protection plans that add runtime threat detection to specific resource types. The secure score aggregates compliance with security recommendations into a percentage, with each recommendation weighted by its impact on security posture. Teams should treat the secure score as a lagging indicator of configuration quality and prioritize remediating Critical and High severity recommendations before optimizing the score number itself.
The Defender for Cloud workload protection plans add threat detection capabilities that the free tier does not provide. Defender for Servers enables Microsoft Defender for Endpoint integration on Azure VMs, just-in-time VM access to restrict management port exposure, file integrity monitoring, adaptive application controls, and network map visualization. Defender for Storage detects anomalous access patterns, malware uploads, and sensitive data exposure in storage accounts. Defender for Key Vault alerts on unusual access patterns such as a high volume of operations from a new IP address or access from a Tor exit node. Defender for Containers provides vulnerability assessment for container images and runtime threat detection for Kubernetes clusters.
Microsoft Sentinel serves as the SIEM and SOAR layer, receiving alerts from Defender for Cloud and direct log ingestion from Azure and non-Azure sources. Diagnostic Settings must be configured on each Azure resource to route logs to a Log Analytics workspace; this is not automatic. Critical log sources for a baseline Sentinel deployment include Microsoft Entra ID sign-in and audit logs, Azure Activity Log, Defender for Cloud alerts, Azure Firewall logs, and Key Vault diagnostic logs. Sentinel's analytics rules correlate these signals into incidents with attached evidence, while automation rules and playbooks can trigger response actions such as blocking a user, isolating a VM, or creating a ServiceNow ticket automatically.
Alert tuning is an ongoing operational requirement rather than a one-time configuration task. Sentinel deployments commonly generate high volumes of low-fidelity alerts in early stages when rules are running against a new environment. Teams should instrument alert fatigue metrics (alerts per analyst per day, mean time from alert to closure), suppress known-benign activity patterns using watchlists and entity-based exceptions, and escalate suppression decisions through a documented approval process to prevent legitimate detections from being silenced inappropriately.
Governance and Compliance: Azure Policy and Management Groups
Azure Policy provides preventive and detective controls that operate across subscriptions at scale. Deny policies block non-compliant resource configurations at the time of creation or modification, functioning as guardrails that prevent misconfigurations from being deployed regardless of which team or automation process initiates the deployment. Audit policies identify existing non-compliant resources without blocking new deployments. The combination of deny policies for the highest-risk controls (blocking storage accounts with public access enabled, requiring secure transfer, preventing VMs without disk encryption) and audit policies for lower-urgency controls provides coverage without blocking legitimate development velocity.
Management Groups provide a hierarchy above the subscription level where policies can be assigned once and inherited by all child subscriptions and resource groups. A typical Management Group hierarchy places production subscriptions under a Production Management Group with strict deny policies, development subscriptions under a Development Management Group with audit policies and fewer restrictions, and a dedicated Management Group for landing zone infrastructure subscriptions. Policies assigned at the Management Group level cannot be overridden at the subscription or resource group level without an explicit exemption, which provides consistent baseline enforcement across all environments.
Microsoft provides built-in policy initiatives aligned to regulatory frameworks including the CIS Azure Foundations Benchmark, NIST SP 800-53, PCI DSS, ISO 27001, and SOC 2. Enabling these initiatives in Defender for Cloud's regulatory compliance dashboard generates a compliance assessment against each framework's controls, with each control linked to the specific Azure policy definition evaluating it. This is useful for generating audit evidence but should be supplemented with manual review, as automated policy compliance does not capture all aspects of a regulatory requirement. Azure Blueprints (now largely superseded by deployment stacks and Bicep templates) historically allowed organizations to package policy assignments, role assignments, and ARM templates into a repeatable compliant environment definition that could be applied to new subscriptions during provisioning.
Container and Kubernetes Security: AKS Hardening
Azure Kubernetes Service (AKS) clusters require hardening beyond default settings to meet production security requirements. The most impactful cluster-level controls are enabling Azure RBAC for Kubernetes authorization (replacing legacy ABAC which is coarser-grained and deprecated), disabling public access to the Kubernetes API server by enabling private cluster mode, and enabling network policy enforcement to control pod-to-pod communication within the cluster. Private cluster mode routes API server communication through a private endpoint in your VNet, eliminating the public IP address that would otherwise be a target for authentication brute-force and API exploitation.
Workload Identity for AKS is the current recommended pattern for allowing pods to authenticate to Azure services, replacing the older AAD Pod Identity approach. Workload Identity uses federated identity credentials to allow Kubernetes service accounts to obtain short-lived tokens for specific Azure Managed Identities, eliminating the need to store Azure credentials in Kubernetes secrets. This provides the same credential-free authentication benefits as Managed Identities for standard Azure VMs applied to containerized workloads.
Microsoft Defender for Containers provides vulnerability assessment for container images stored in Azure Container Registry, runtime threat detection for AKS clusters using eBPF-based sensor technology, Kubernetes control plane audit log analysis, and node-level threat detection. Enabling Defender for Containers on all production AKS clusters is a baseline recommendation rather than an optional enhancement. Pod Security Admission (which replaced Pod Security Policy in Kubernetes 1.25+) should be configured with the Baseline or Restricted profile for production namespaces, blocking pods that request elevated privileges, host network access, or host path mounts without explicit exception. Node pool OS patching should be configured with automatic node image upgrades on a weekly schedule to ensure kernel and OS-level patches are applied promptly without requiring manual intervention.
DevSecOps Integration: Shifting Security Left in Azure
Security controls applied at deployment time are far more expensive to remediate than the same controls applied at the code or infrastructure-as-code authoring stage. Integrating security scanning into Azure DevOps pipelines and GitHub Actions workflows allows teams to catch misconfigurations, vulnerable dependencies, and leaked credentials before they reach a deployed environment.
Defender for DevOps (part of Microsoft Defender for Cloud) integrates with Azure DevOps and GitHub to provide security posture visibility across repositories, pipelines, and infrastructure-as-code templates. It surfaces findings from GitHub Advanced Security (secret scanning, dependency review, CodeQL code scanning) within the Defender for Cloud interface alongside cloud workload findings, providing a unified view of risks from code through to runtime. GitHub Advanced Security secret scanning detects over 200 credential patterns from cloud providers, SaaS platforms, and security tools, and can be configured to block pushes that contain detected secrets through push protection.
Infrastructure-as-code scanning tools including Checkov, tfsec, and the built-in scanning in Defender for DevOps analyze Terraform, Bicep, ARM templates, and Kubernetes manifests for security misconfigurations before they are deployed. Common findings include storage accounts with public access not explicitly disabled, NSG rules allowing unrestricted inbound access, Key Vaults without soft delete enabled, and Log Analytics workspaces without the required data retention period. These findings are faster and cheaper to remediate in a pull request than in a deployed environment where changing the configuration may require downtime or redeployment.
Deployment gates in Azure DevOps release pipelines can require that infrastructure-as-code scans pass before a deployment proceeds to production. Combining automated IaC scanning gates with a policy-as-code approach (using Azure Policy in Deny mode to block non-compliant deployments) creates two independent enforcement points: the pipeline gate prevents the deployment from being triggered, and the Azure Policy deny effect prevents the API call from succeeding even if the gate is bypassed. This layered approach provides defense in depth in the deployment pipeline that mirrors the defense-in-depth approach applied to the runtime environment.
The bottom line
Azure security is a configuration discipline. The platform provides the tools to implement strong identity controls, network segmentation, data protection, and continuous monitoring, but none of these controls are enabled at their most secure settings by default. Teams that accept Azure defaults often discover the gap only after an incident.
The highest-return investments are MFA enforcement through Conditional Access, eliminating standing privileged role assignments through PIM, disabling public access on storage accounts, enabling Defender for Cloud with workload protection plans on production subscriptions, and routing logs to Sentinel with a baseline set of detection rules active. These five areas address the root causes of the majority of documented Azure security incidents. Everything else in this guide builds on that foundation.
Frequently asked questions
What is the Azure Security Benchmark and how do I use it?
The Azure Security Benchmark (ASB) is Microsoft's curated set of security recommendations mapped to industry frameworks including CIS Controls, NIST SP 800-53, and PCI DSS. It is organized into control domains covering network security, identity management, privileged access, data protection, asset management, logging and threat detection, incident response, and posture and vulnerability management. Each control includes an Azure-specific implementation guide and maps to Defender for Cloud policy initiatives so you can measure compliance automatically. The best starting point is to enable the ASB policy initiative in Defender for Cloud, review your secure score, and prioritize remediating the findings in the highest-weighted control categories. Microsoft publishes the full benchmark at the link above and updates it roughly annually as cloud services evolve.
Should I use Azure Firewall or Network Security Groups?
Network Security Groups (NSGs) and Azure Firewall serve different scopes and should be used together rather than treated as alternatives. NSGs are distributed, stateful packet filters applied to subnet or NIC level that control east-west traffic between resources in your VNet and basic inbound and outbound filtering. Azure Firewall is a managed, centralized layer-7 firewall with FQDN filtering, threat intelligence-based blocking, TLS inspection, and IDPS capabilities. The standard architecture uses Azure Firewall in a hub VNet to inspect and control all traffic leaving the environment to the internet or crossing between VNets, while NSGs provide fine-grained subnet-level segmentation within spoke VNets. Using only NSGs without Azure Firewall leaves you without application-layer inspection and threat intelligence feeds. Using only Azure Firewall without NSGs means lateral movement within a subnet is unrestricted. Both layers together provide defense in depth.
What is Microsoft Defender for Cloud and is it worth the cost?
Microsoft Defender for Cloud is a cloud security posture management (CSPM) and cloud workload protection platform (CWPP) built into Azure. The free tier provides security recommendations, secure score tracking, and basic policy compliance monitoring at no charge for all Azure subscriptions. The enhanced workload protection plans (Defender for Servers, Defender for Storage, Defender for SQL, Defender for Containers, Defender for Key Vault, and others) add runtime threat detection, file integrity monitoring, adaptive application controls, and just-in-time VM access, with pricing per resource per month. For production environments handling sensitive data or regulated workloads, the workload protection plans are generally worth the cost: the threat detection capabilities reduce mean time to detect significantly compared to relying on Azure Monitor alerts alone, and the regulatory compliance dashboard simplifies audit evidence collection for frameworks like PCI DSS and ISO 27001. Organizations can enable plans per subscription selectively, so a common approach is to enable Defender for Servers on production workloads while leaving development subscriptions on the free tier.
How do I implement least privilege in Azure RBAC?
Start by auditing current role assignments using the Azure portal Access Control (IAM) blade at the subscription and resource group level, looking for Owner and Contributor assignments to individual user accounts that should instead use narrower roles or be scoped to specific resources. Replace broad subscription-level Owner assignments with resource-group-scoped Contributor assignments wherever possible, and use built-in purpose-specific roles (Storage Blob Data Reader, Key Vault Secrets User, Virtual Machine Contributor) instead of Contributor when the workload only needs specific permissions. For human administrative access to privileged roles, enable Privileged Identity Management (PIM) so that Owner and User Access Administrator rights are activated on-demand with approval workflow and time-limited sessions rather than permanently assigned. For automation and application identities, use Managed Identities instead of service principals with client secrets, since Managed Identities require no credential management and rotate tokens automatically. Review role assignments quarterly using Microsoft Entra ID Access Reviews to identify and remove stale assignments for users who have changed roles or left the organization.
What are the most common Azure misconfigurations attackers exploit?
The most consistently exploited Azure misconfigurations include storage accounts with public blob access enabled, which allows unauthenticated read access to any blob in public containers; management ports (RDP 3389, SSH 22) open to the internet via NSG rules with source 0.0.0.0/0; service principals with client secrets rather than certificates or Managed Identities, where the secret has been committed to source control or stored in plaintext configuration; missing MFA enforcement through Conditional Access, particularly for privileged roles and administrative consoles; and overly permissive Key Vault access policies granting full secret and key permissions to application identities that only need Get and List. A secondary cluster involves Defender for Cloud disabled or on the free tier with no workload protection, leaving runtime threats undetected; Log Analytics workspace retention set to the 30-day default with no export to long-term storage; and Azure Active Directory guest accounts with excessive permissions inherited from group membership. Microsoft Defender for Cloud's recommendations list, filtered by severity Critical and High, surfaces the highest-priority misconfigurations in your specific environment.
How do I secure Azure storage accounts?
The baseline configuration for any Azure storage account used in production should include: public network access disabled (set to Disabled or restricted to specific VNet subnets via service endpoints or private endpoints); Secure Transfer Required enabled, which rejects HTTP connections and requires HTTPS or SMB 3.0; Allow Blob Public Access disabled at the account level, overriding any container-level public access setting; Azure Active Directory authentication as the preferred method rather than account keys, which should be rotated regularly or disabled in favor of RBAC-based access; and blob soft delete and versioning enabled with a retention period of at least 30 days to enable recovery from accidental deletion or ransomware encryption. For highly sensitive data, use customer-managed keys via Azure Key Vault instead of the default Microsoft-managed keys. Enable diagnostic logging for read, write, and delete operations and route logs to a Log Analytics workspace. Storage account keys grant full access to all data in the account; if keys cannot be eliminated, lock them in Key Vault and access them only through the Key Vault API rather than embedding them in application configuration.
What logs should I be forwarding to Microsoft Sentinel?
The highest-priority log sources for a Sentinel deployment are Microsoft Entra ID sign-in logs and audit logs (connected via the Entra ID data connector and covering authentication events, MFA failures, Conditional Access outcomes, and directory changes); Microsoft Defender for Cloud alerts (which surface runtime threats across your Azure workloads); Azure Activity Log at the subscription level (covering resource create, modify, and delete operations, role assignment changes, and policy changes); Microsoft Defender for Endpoint alerts if you have the MDE connector enabled; and Azure Firewall logs if Azure Firewall is deployed. Secondary priority sources include Azure Key Vault diagnostic logs (covering secret access and policy changes), Storage Account diagnostic logs for accounts holding sensitive data, Azure Kubernetes Service audit logs for container workloads, and network flow logs via Traffic Analytics for east-west visibility. Avoid ingesting high-volume low-signal sources like verbose IIS access logs or raw VM system logs without filtering at the collection point, as ingestion cost scales linearly with data volume and noise degrades analyst throughput.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, weekly, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals weekly.
The Mythos Brief is free.
AI that finds 27-year-old zero-days. What it means for your security program.