How Azure network security can help you meet NIS2 compliance
With the adoption of the NIS2 Directive EU 2022 2555, cybersecurity obligations for both public and private sector organizations have become more strict and far reaching. NIS2 aims to establish a higher common level of cybersecurity across the European Union by enforcing stronger requirements on risk management, incident reporting, supply chain protection, and governance. If your organization runs on Microsoft Azure, you already have powerful services to support your NIS2 journey. In particular Azure network security products such as Azure Firewall, Azure Web Application Firewall WAF, and Azure DDoS Protection provide foundational controls. The key is to configure and operate them in a way that aligns with the directive’s expectations. Important note This article is a technical guide based on the NIS2 Directive EU 2022 2555 and Microsoft product documentation. It is not legal advice. For formal interpretations, consult your legal or regulatory experts. What is NIS2? NIS2 replaces the original NIS Directive 2016 and entered into force on 16 January 2023. Member states must transpose it into national law by 17 October 2024. Its goals are to: Expand the scope of covered entities essential and important entities Harmonize cybersecurity standards across member states Introduce stricter supervisory and enforcement measures Strengthen supply chain security and reporting obligations Key provisions include: Article 20 management responsibility and governance Article 21 cybersecurity risk management measures Article 23 incident notification obligations These articles require organizations to implement technical, operational, and organizational measures to manage risks, respond to incidents, and ensure leadership accountability. Where Azure network security fits The table below maps common NIS2 focus areas to Azure network security capabilities and how they support compliance outcomes. NIS2 focus area Azure services and capabilities How this supports compliance Incident handling and detection Azure Firewall Premium IDPS and TLS inspection, Threat Intelligence mode, Azure WAF managed rule sets and custom rules, Azure DDoS Protection, Azure Bastion diagnostic logs Detect, block, and log threats across layers three to seven. Provide telemetry for triage and enable response workflows that are auditable. Business continuity and resilience Azure Firewall availability zones and autoscale, Azure Front Door or Application Gateway WAF with zone redundant deployments, Azure Monitor with Log Analytics, Traffic Manager or Front Door for failover Improve service availability and provide data for resilience reviews and disaster recovery scenarios. Access control and segmentation Azure Firewall policy with DNAT, network, and application rules, NSGs and ASGs, Azure Bastion for browser based RDP SSH without public IPs, Private Link Enforce segmentation and isolation of critical assets. Support Zero Trust and least privilege for inbound and egress. Vulnerability and misconfiguration defense Azure WAF Microsoft managed rule set based on OWASP CRS. Azure Firewall Premium IDPS signatures Reduce exposure to common web exploits and misconfigurations for public facing apps and APIs. Encryption and secure communications TLS policy: Application Gateway SSL policy; Front Door TLS policy; App Service/PaaS minimum TLS. Inspection: Azure Firewall Premium TLS inspection Inspect and enforce encrypted communication policies and block traffic that violates TLS requirements. Inspect decrypted traffic for threats. Incident reporting and evidence Azure Network Security diagnostics, Log Analytics, Microsoft Sentinel incidents, workbooks, and playbooks Capture and retain telemetry. Correlate events, create incident timelines, and export reports to meet regulator timelines. NIS2 articles in practice Article 21 cybersecurity risk management measures Azure network controls contribute to several required measures: Prevention and detection. Azure Firewall blocks unauthorized access and inspects traffic with IDPS. Azure DDoS Protection mitigates volumetric and protocol attacks. Azure WAF prevents common web exploits based on OWASP guidance. Logging and monitoring. Azure Firewall, WAF, DDoS, and Bastion resources produce detailed resource logs and metrics in Azure Monitor. Ingest these into Microsoft Sentinel for correlation, analytics rules, and automation. Control of encrypted communications. Azure Firewall Premium provides TLS inspection to reveal malicious payloads inside encrypted sessions. Supply chain and service provider management. Use Azure Policy and Defender for Cloud to continuously assess configuration and require approved network security baselines across subscriptions and landing zones. Article 23 incident notification Build an evidence friendly workflow with Sentinel: Early warning within twenty four hours. Use Sentinel analytics rules on Firewall, WAF, DDoS, and Bastion logs to generate incidents and trigger playbooks that assemble an initial advisory. Incident notification within seventy two hours. Enrich the incident with additional context such as mitigation actions from DDoS, Firewall and WAF. Final report within one month. Produce a summary that includes root cause, impact, and corrective actions. Use Workbooks to export charts and tables that back up your narrative. Article 20 governance and accountability Management accountability. Track policy compliance with Azure Policy initiatives for Firewall, DDoS and WAF. Use exemptions rarely and record justification. Centralized visibility. Defender for Cloud’s network security posture views and recommendations give executives and owners a quick view of exposure and misconfigurations. Change control and drift prevention. Manage Firewall, WAF, and DDoS through Network Security Hub and Infrastructure as Code with Bicep or Terraform. Require pull requests and approvals to enforce four eyes on changes. Network security baseline Use this blueprint as a starting point. Adapt to your landing zone architecture and regulator guidance. Topology and control plane Hub and spoke architecture with a centralized Azure Firewall Premium in the hub. Enable availability zones. Deploy Azure Bastion Premium in the hub or a dedicated management VNet; peer to spokes. Remove public IPs from management NICs and disable public RDP SSH on VMs. Use Network Security Hub for at-scale management. Require Infrastructure as Code for all network security resources. Web application protection Protect public apps with Azure Front Door Premium WAF where edge inspection is required. Use Application Gateway WAF v2 for regional scenarios. Enable the Microsoft managed rule set and the latest version. Add custom rules for geo based allow or deny and bot management. enable rate limiting when appropriate. DDoS strategy Enable DDoS Network Protection on virtual networks that contain internet facing resources. Use IP Protection for single public IP scenarios. Configure DDoS diagnostics and alerts. Stream to Sentinel. Define runbooks for escalation and service team engagement. Firewall policy Enable IDPS in alert and then in alert and deny for high confidence signatures. Enable TLS inspection for outbound and inbound where supported. Enforce FQDN and URL filtering for egress. Require explicit allow lists for critical segments. Deny inbound RDP SSH from the internet. Allow management traffic only from Bastion subnets or approved management jump segments. Logging, retention, and access Turn on diagnostic settings for Firewall, WAF, DDoS, and Application Gateway or Front Door. Send to Log Analytics and an archive storage account for long term retention. Set retention per national law and internal policy. Azure Monitor Log Analytics supports table-level retention and archive for up to 12 years, many teams keep a shorter interactive window and multi-year archive for audits. Restrict access with Azure RBAC and Customer Managed Keys where applicable. Automation and playbooks Build Sentinel playbooks for regulator notifications, ticket creation, and evidence collection. Maintain dry run versions for exercises. Add analytics for Bastion session starts to sensitive VMs, excessive failed connection attempts, and out of hours access. Conclusion Azure network security services provide the technical controls most organizations need in order to align with NIS2. When combined with policy enforcement, centralized logging, and automated detection and response, they create a defensible and auditable posture. Focus on layered protection, secure connectivity, and real time response so that you can reduce exposure to evolving threats, accelerate incident response, and meet NIS2 obligations with confidence. References NIS2 primary source Directive (EU) 2022/2555 (NIS2). https://eur-lex.europa.eu/eli/dir/2022/2555/oj/eng Azure Firewall Premium features (TLS inspection, IDPS, URL filtering). https://learn.microsoft.com/en-us/azure/firewall/premium-features Deploy & configure Azure Firewall Premium. https://learn.microsoft.com/en-us/azure/firewall/premium-deploy IDPS signature categories reference. https://learn.microsoft.com/en-us/azure/firewall/idps-signature-categories Monitoring & diagnostic logs reference. https://learn.microsoft.com/en-us/azure/firewall/monitor-firewall-reference Web Application Firewall WAF on Azure Front Door overview & features. https://learn.microsoft.com/en-us/azure/frontdoor/web-application-firewall WAF on Application Gateway overview. https://learn.microsoft.com/en-us/azure/web-application-firewall/overview Examine WAF logs with Log Analytics. https://learn.microsoft.com/en-us/azure/application-gateway/log-analytics Rate limiting with Front Door WAF. https://learn.microsoft.com/en-us/azure/web-application-firewall/afds/waf-front-door-rate-limit Azure DDoS Protection Service overview & SKUs (Network Protection, IP Protection). https://learn.microsoft.com/en-us/azure/ddos-protection/ddos-protection-overview Quickstart: Enable DDoS IP Protection. https://learn.microsoft.com/en-us/azure/ddos-protection/manage-ddos-ip-protection-portal View DDoS diagnostic logs (Notifications, Mitigation Reports/Flows). https://learn.microsoft.com/en-us/azure/ddos-protection/ddos-view-diagnostic-logs Azure Bastion Azure Bastion overview and SKUs. https://learn.microsoft.com/en-us/azure/bastion/bastion-overview Deploy and configure Azure Bastion. https://learn.microsoft.com/en-us/azure/bastion/tutorial-create-host-portal Disable public RDP and SSH on Azure VMs. https://learn.microsoft.com/en-us/azure/virtual-machines/security-baseline Azure Bastion diagnostic logs and metrics. https://learn.microsoft.com/en-us/azure/bastion/bastion-diagnostic-logs Microsoft Sentinel Sentinel documentation (onboard, analytics, automation). https://learn.microsoft.com/en-us/azure/sentinel/ Azure Firewall solution for Microsoft Sentinel. https://learn.microsoft.com/en-us/azure/firewall/firewall-sentinel-overview Use Microsoft Sentinel with Azure WAF. https://learn.microsoft.com/en-us/azure/web-application-firewall/waf-sentinel Architecture & routing Hub‑spoke network topology (reference). https://learn.microsoft.com/en-us/azure/architecture/networking/architecture/hub-spoke Azure Firewall Manager & secured virtual hub. https://learn.microsoft.com/en-us/azure/firewall-manager/secured-virtual-hubAzure Networking Portfolio Consolidation
Overview Over the past decade, Azure Networking has expanded rapidly, bringing incredible tools and capabilities to help customers build, connect, and secure their cloud infrastructure. But we've also heard strong feedback: with over 40 different products, it hasn't always been easy to navigate and find the right solution. The complexity often led to confusion, slower onboarding, and missed capabilities. That's why we're excited to introduce a more focused, streamlined, and intuitive experience across Azure.com, the Azure portal, and our documentation pivoting around four core networking scenarios: Network foundations: Network foundations provide the core connectivity for your resources, using Virtual Network, Private Link, and DNS to build the foundation for your Azure network. Try it with this link: Network foundations Hybrid connectivity: Hybrid connectivity securely connects on-premises, private, and public cloud environments, enabling seamless integration, global availability, and end-to-end visibility, presenting major opportunities as organizations advance their cloud transformation. Try it with this link: Hybrid connectivity Load balancing and content delivery: Load balancing and content delivery helps you choose the right option to ensure your applications are fast, reliable, and tailored to your business needs. Try it with this link: Load balancing and content delivery Network security: Securing your environment is just as essential as building and connecting it. The Network Security hub brings together Azure Firewall, DDoS Protection, and Web Application Firewall (WAF) to provide a centralized, unified approach to cloud protection. With unified controls, it helps you manage security more efficiently and strengthen your security posture. Try it with this link: Network security This new structure makes it easier to discover the right networking services and get started with just a few clicks so you can focus more on building, and less on searching. What you’ll notice: Clearer starting points: Azure Networking is now organized around four core scenarios and twelve essential services, reflecting the most common customer needs. Additional services are presented within the context of these scenarios, helping you stay focused and find the right solution without feeling overwhelmed. Simplified choices: We’ve merged overlapping or closely related services to reduce redundancy. That means fewer, more meaningful options that are easier to evaluate and act on. Sunsetting outdated services: To reduce clutter and improve clarity, we’re sunsetting underused offerings such as white-label CDN services and China CDN. These capabilities have been rolled into newer, more robust services, so you can focus on what’s current and supported. What this means for you Faster decision-making: With clearer guidance and fewer overlapping products, it's easier to discover what you need and move forward confidently. More productive sales conversations: With this simplified approach, you’ll get more focused recommendations and less confusion among sellers. Better product experience: This update makes the Azure Networking portfolio more cohesive and consistent, helping you get started quickly, stay aligned with best practices, and unlock more value from day one. The portfolio consolidation initiative is a strategic effort to simplify and enhance the Azure Networking portfolio, ensuring better alignment with customer needs and industry best practices. By focusing on top-line services, combining related products, and retiring outdated offerings, Azure Networking aims to provide a more cohesive and efficient product experience. Azure.com Before: Our original Solution page on Azure.com was disorganized and static, displaying a small portion of services in no discernable order. After: The revised solution page is now dynamic, allowing customers to click deeper into each networking and network security category, displaying the top line services, simplifying the customer experience. Azure Portal Before: With over 40 networking services available, we know it can feel overwhelming to figure out what’s right for you and where to get started. After: To make it easier, we've introduced four streamlined networking hubs each built around a specific scenario to help you quickly identify the services that match your needs. Each offers an overview to set the stage, key services to help you get started, guidance to support decision-making, and a streamlined left-hand navigation for easy access to all services and features. Documentation For documentation, we looked at our current assets as well as created new assets that aligned with the changes in the portal experience. Like Azure.com, we found the old experiences were disorganized and not well aligned. We updated our assets to focus on our top-line networking services, and to call out the pillars. Our belief is these changes will allow our customers to more easily find the relevant and important information they need for their Azure infrastructure. Azure Network Hub Before the updates, we had a hub page organized around different categories and not well laid out. In the updated hub page, we provided relevant links for top-line services within all of the Azure networking scenarios, as well as a section linking to each scenario's hub page. Scenario Hub pages We added scenario hub pages for each of the scenarios. This provides our customers with a central hub for information about the top-line services for each scenario and how to get started. Also, we included common scenarios and use cases for each scenario, along with references for deeper learning across the Azure Architecture Center, Well Architected Framework, and Cloud Adoption Framework libraries. Scenario Overview articles We created new overview articles for each scenario. These articles were designed to provide customers with an introduction to the services included in each scenario, guidance on choosing the right solutions, and an introduction to the new portal experience. Here's the Load balancing and content delivery overview: Documentation links Azure Networking hub page: Azure networking documentation | Microsoft Learn Scenario Hub pages: Azure load balancing and content delivery | Microsoft Learn Azure network foundation documentation | Microsoft Learn Azure hybrid connectivity documentation | Microsoft Learn Azure network security documentation | Microsoft Learn Scenario Overview pages What is load balancing and content delivery? | Microsoft Learn Azure Network Foundation Services Overview | Microsoft Learn What is hybrid connectivity? | Microsoft Learn What is Azure network security? | Microsoft Lea Improving user experience is a journey and in coming months we plan to do more on this. Watch out for more blogs over the next few months for further improvements.
Accelerate designing, troubleshooting & securing your network with Gen-AI powered tools, now GA.
We are thrilled to announce the general availability of Azure Networking skills in Copilot, an extension of Copilot in Azure and Security Copilot designed to enhance cloud networking experience. Azure Networking Copilot is set to transform how organizations design, operate, and optimize their Azure Network by providing contextualized responses tailored to networking-specific scenarios and using your network topology.
Best Practices for Securing Access to VMs
Azure Bastion and Microsoft Entra PIM work together to secure VM access by eliminating the need for public IPs, enabling identity-based authentication, and enforcing Just-In-Time (JIT) access. Bastion provides secure RDP/SSH connections through Entra ID without local credentials, while Entra PIM ensures that users only receive time-limited, approved access. This combination supports a Zero Trust model by minimizing persistent privileges and reducing the overall attack surface.
Automated Deployment of Cross-Tenant Azure Virtual Hubs Virtual Networks Connection
In modern cloud infrastructure, interconnecting resources across different Azure tenants is essential for various business scenarios, such as mergers, acquisitions, or multi-departmental collaborations. This article will walk you through creating a Virtual Hub in a Virtual WAN and connecting to a Virtual Network in a different tenant from the hub using Bicep and Azure Pipelines. The pipeline will be using a Service Principal to create and access resources in the two Tenants. The client ID and secret need to be stored in a Key Vault, the details of which would be passed as parameters to the pipeline. Mutli-Tenant SPN Setup and Access As mentioned in the Azure Documentation, we would be using the below command in the pipeline to setup the connection between the hub and virtual network: az network vhub connection create --resource-group "[resource_group_name]" --name "[connection_name]" --vhub-name "[virtual_hub_name]" --remote-vnet "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/rgName/providers/Microsoft.Network/virtualNetworks/vnetName" Since a service principal is being used to run the pipelines, the SPN would need contributor access on the appropriate subscriptions on both the main tenant and the remote tenant. This can be achieved using the following steps: 1. Create Service Principal and Assign Roles We will use a single SPN for the creation of VWAN, Vhub and the connection to the remote virtual network. Create the service principal in the Tenant that will contain Virtual WAN and the hub and provide contributor access on the subscription level. 2. Setting Up Multi-Tenant SPN Run the URL below to create the SPN in the other tenant: https://login.microsoftonline.com/{organization}/adminconsent?client_id={client-id} Organization would be the Tenant ID of the remote Vnet, and client ID is the Application ID of the SPN. Assign the SPN Contributor access on the subscription where the Vnet resides. Note: The contributor access on the Subscription is the lowest possible access required for multi-tenant setup. Contributor access on the Resource Group level would not work. Code Explanation The code and parameter files can be found here. There are 3 main Azure Bicep files that manages the creation of the resources: Network.bicep The file retrieves the required modules to create a single VWAN and multiple hubs in the VWAN, along with a virtual network and resource group(s). The naming convention is fixed based on environment (TST, PROD etc.) and region of resource (west us, east us etc.) It also contains the following code to create a connection between the virtual network (either provide ID of the VNET or parameters for the creation of the VNET) in the same tenant as the hub. The parameter file used is ‘network.main.parameters.json’ The below code would only run if createHubVirtualNetworkConnection is set to True. By default, the parameter is set to False. module connectVnetHub '../Modules/VirtualHub/connectVnet.bicep' = if (createHubVirtualNetworkConnection){ name: 'connect-vnet-to-hub' scope: resourceGroup(vwan.subscriptionID, vwan.resourceGroupName) params: { vhubName: 'vwanhub-${env}-${stage}-${vnet.location}-001' virtualNetworkID: (createVnet) ? virtualnetwork.outputs.resourceId : vnet.id connectionName: '${purpose}-vnet-${env}' } dependsOn: [ vWan vwanHub virtualnetwork ] } The above module calls the below bicep file to create the connection: param vhubName string param virtualNetworkID string param connectionName string resource vhub 'Microsoft.Network/virtualHubs@2023-04-01' existing = { name: vhubName } resource connectVnet 'Microsoft.Network/virtualHubs/hubVirtualNetworkConnections@2023-04-01' = { name: connectionName parent: vhub properties: { remoteVirtualNetwork: { id: virtualNetworkID } } } RemoteVnetSubnet.bicep This Bicep file creates multiple Resource Groups, VNETs and Subnets as mentioned in the parameter file. Parameter file name is network.remote.parameters.json. VhubRemoteVnetMapping.bicep This file calls the module to connect the remote VNET(s) to the Vhub. The appropriate Virtual Hub is selected based on the region. For example, a VNET created in east us will be connected to the hub is east us. The multi-tenant SPN needs to be passed as a parameter which is required to run the PowerShell script in the module. The SPN details is stored in a Key Vault and the below code is used to retrieve the Client ID and secret: param keyVaultName string param keyVaultResourceGroup string param keyVaultSubscription string resource keyVault 'Microsoft.KeyVault/vaults@2023-02-01' existing = { name: keyVaultName scope: resourceGroup(keyVaultSubscription, keyVaultResourceGroup) } The following code can connect multiple VNETs to the right virtual hub: targetScope='subscription' param vnets object [] = [] param vwan object param env string = 'main' param stage string = 'prod' module connectRemoteVnetVhub '../Modules/VirtualHub/connectRemoteVnet.bicep' = [for i in range(0, length(vnets)): { name: 'connect-${vnets[i].vnetName}-to-vhub' scope: resourceGroup(vwan.subscriptionID, vwan.resourceGroupName) params: { remoteResourceGroup: vnets[i].resourceGroupName remoteSubscriptionID: vnets[i].subscriptionID remoteTenant: vnets[i].tenantID remoteVnetName: vnets[i].vnetName vhubName: 'vwanhub-${env}-${stage}-${vnets[i].location}-001' subscriptionID: vwan.SubscriptionID tenantID: vwan.tenantID clientID: keyVault.getSecret('clientid-Main') clientSecret: keyVault.getSecret('clientsecret-Main') connectionName: '${vnets[i].vnetName}-dns-connection' location: vnets[i].location } }] The module basically contains a deployment script resource that runs a bash script to connect the VNET and the hub. resource deploymentScript 'Microsoft.Resources/deploymentScripts@2023-08-01' = { name: 'connectRemote${remoteVnetName}toVhub' location: location kind: 'AzureCLI' properties: { arguments: '${tenantID} ${remoteTenant} ${remoteSubscriptionID} ${subscriptionID} ${remoteResourceGroup} ${remoteVnetName} ${connectionName} ${vhubName}' environmentVariables: [ { name: 'parentResourceGroupName' value: resourceGroup().name } { name: 'clientID' value: clientID } { name: 'clientSecret' value: clientSecret } ] azCliVersion: '2.54.0' scriptContent: ''' az login --service-principal -u $clientID -p $clientSecret --tenant $2 az account set --subscription $3 az login --service-principal -u $clientID -p $clientSecret --tenant $1 az account set --subscription $4 az extension add --name virtual-wan -y --version 0.3.0 az network vhub connection create --resource-group $parentResourceGroupName --name $7 --vhub-name $8 --remote-vnet "/subscriptions/${3}/resourceGroups/${5}/providers/Microsoft.Network/virtualNetworks/${6}" ''' retentionInterval: 'P1D' } } Azure Pipeline Explanation Even though the SPN created earlier has access to both the main and remote Tenant, it would be a much more secure option to minimize the use of the multi-tenant SPN to just create the VHUB VNET connection due to its elevated access. Hence, we need to create an additional SPN that has the required access only on the remote Tenant. This new SPN then should be used to deploy only the remote VNET(s) and subnets and use the Multi-tenant SPN to create the main tenant resources and the connection. The pipeline will retrieve the SPN Client ID and secret from the Key Vault, run a validation on the Bicep code and deploy the resources. Appropriate parameters need to be passed to the pipeline to run the appropriate bicep file. It has to be run 3 times by selecting the following values: Iteration 1 (To deploy VWAN, VHUB in Main Tenant): Tenant Name: Main Purpose of Deployment: Main Network Deployment Subscription ID: Details of the subscription where the VWAN, VHUB and VNET will reside in the Main Tenant. Iteration 2 (To deploy Remote VNET): Tenant Name: Remote Purpose of Deployment: Remote Network Deployment Subscription ID: Details of the subscription where the remote VNET will reside in the remote Tenant. Iteration 3 (To create the cross-tenant VHUB VNET Connection): Tenant Name: Main Purpose of Deployment: Vnet-Hub-Connection Subscription ID: Details of the subscription where the VWAN, VHUB and VNET will reside in the Main Tenant. Note: Ensure that the Tenant ID for the main and remote Tenant, Client ID and Client Secret of the SPNs created are stored in the Key Vault before running the pipeline. The below format should be followed while creating the secrets in the key vault: $clientIDSecretName = "clientid-${{ parameters.tenantName }}" $clientSecretSecretName = "clientsecret-${{ parameters.tenantName }}" $tenantIDSecretName = "tenantid-${{ parameters.tenantName }}" where the Parameter 'tenantName' would be either 'Main' or 'Remote'. All the above-mentioned code and parameter files can be found here. Azure Documentation References Process: https://learn.microsoft.com/en-us/azure/virtual-wan/cross-tenant-vnet-az-cli Multi-Tenant SPNs: https://learn.microsoft.com/en-us/entra/identity-platform/howto-convert-app-to-be-multi-tenant Tenant wide Admin Consent: Grant tenant-wide admin consent to an application - Microsoft Entra ID | Microsoft Learn
Issue with Azure VM Conditional Access for Office 365 and Dynamic Public IP Detection
Hi all, I have a VM in Azure where I need to allow an account with MFA to bypass the requirement on this specific server when using Office 365. I've tried to achieve this using Conditional Access by excluding locations, specifically the IP range of my Azure environment. Although I’ve disconnected any public IPs from this server, the Conditional Access policy still isn’t working as intended. The issue seems to be that it continues to detect a public IP, which changes frequently, making it impossible to exclude. What am I doing wrong?
