Cross-Region Zero Trust: Connecting Power Platform to Azure PaaS across different regions

In the modern enterprise cloud landscape, data rarely sits in one place. You might face a scenario where your Power Platform environment (Dynamics 365, Power Apps, or Power Automate) is hosted in Region A for centralized management, while your sensitive SQL Databases or Storage Accounts must reside in Region B due to data sovereignty, latency requirements, or legacy infrastructure.

Connecting these two worlds usually involves traversing the public internet - a major "red flag" for security teams.

The Missing Link in Cloud Security

When we talk about enterprise security, "Public Access: Disabled" is the holy grail. But for Power Platform architects, this setting is often followed by a headache.

The challenge is simple but daunting: How can a Power Platform Environment (e.g., in Region A) communicate with an Azure PaaS service (e.g., Storage or SQL in Region B) when that resource is completely locked down behind a Private Endpoint?

Existing documentation usually covers single-region setups with no firewalls. 

This post details a "Zero Trust" architecture that bridges this gap. This is a walk through for setting up a Cross-Region Private Link that routes traffic from the Power Platform in Region A, through a secure Azure Hub, and down the Azure Global Backbone to a Private Endpoint in Region B, without a single packet ever touching the public internet.

1. Understanding the Foundation: VNet Support

Before we build, we must understand what moves: Power Platform VNet integration is an "Outbound" technology. It allows the platform to connect to data sources secured within an Azure Virtual Network and "inject" its traffic into your Virtual Network, without needing to install or manage an on-premises data gateway.

According to Microsoft's official documentation, this integration supports a wide range of services:

• Dataverse: Plugins and Virtual Tables.
• Power Automate: Cloud Flows using standard connectors.
• Power Apps: Canvas Apps calling private APIs.

This means once the "tunnel" is built, your entire Power Platform ecosystem can reach your private Azure universe.

Source: Virtual Network support overview – Power Platform | Microsoft Learn

 

 

 

 

 

 

 

 

 

 

 

 

 

 

2. The Architecture: A Cross-Region Global Bridge

Based on the Hub-and-Spoke topology, this architecture relies on four key components working in unison:

1. Source (Region A): The Power Platform environment utilizes VNet Injection. This injects the platform's outbound traffic into a dedicated, delegated subnet within your Region A Spoke VNet.
2. The Hub: A central VNet containing an Azure Firewall. This acts as the regional traffic cop and DNS Proxy, inspecting traffic and resolving private names before allowing packets to traverse the global backbone.
3. The Bridge (Global Backbone): We utilize Global VNet Peering to connect Region A to the Region B Spoke. This keeps traffic on Microsoft's private fiber backbone.
4. Destination (Region B): The Azure PaaS service (e.g. Storage Account) is locked down with Public Access Disabled. It is only accessible via a Private Endpoint.

The Architecture: Visualizing the Flow

As illustrated in the diagram below, this solution separates the responsibilities into two distinct layers: the Network Admin (Azure Infrastructure) and the Power Platform Admin (Enterprise Policy). 

3. The High Availability Constraint: Regional Pairs

A common pitfall of these deployments is configuring only a single region. Power Platform environments are inherently redundant. In a geography like Europe, your environment is actually hosted across a Regional Pair (e.g., West Europe and North Europe).

Why? If one Azure region in the pair experiences an outage, your Power Platform environment will failover to the second region. If your VNet Policy isn't already there, your private connectivity will break.

To maintain High Availability (HA) for your private tunnel, your Azure footprint must mirror this:

• Two VNets: You must create a Virtual Network in each region of the pair.
• Two Delegated Subnets: Each VNet requires a subnet delegated specifically to Microsoft.PowerPlatform/enterprisePolicies.
• Two Network Policies: You must create an Enterprise Policy in each region and link both to your environment to ensure traffic flows even during a regional failover.
• Ensure your Azure subscription is registered for the Microsoft.PowerPlatform resource provider by running the SetupSubscriptionForPowerPlatform.ps1 script.

4. Solving the DNS Riddle with Azure Firewall

In a Hub-and-Spoke model, peering the VNets is only half the battle. If your Power Platform environment in Region A asks for mystorage.blob.core.windows.net, it will receive a public IP by default, and your connection will be blocked.

To fix this, we utilize the Azure Firewall as a DNS Proxy:

1. Link the Private DNS Zone: Ensure your Private DNS Zones (e.g., privatelink.blob.core.windows.net) are linked to the Hub VNet.
2. Enable DNS Proxy: Turn on the DNS Proxy feature on your Azure Firewall.
3. Configure Custom DNS: Set the DNS servers of your Spoke VNets (Region A) to the Firewall’s Internal IP.

Now, the DNS query flows through the Firewall, which "sees" the Private DNS Zone and returns the Private IP to the Power Platform.

5. Secretless Security with User-Assigned Managed Identity

Private networking secures the path, but identity secures the access. Instead of managing fragile Client Secrets, we use User-Assigned Managed Identity (UAMI).

Phase A: The Azure Setup

1. Create the Identity: Generate a User-Assigned Managed Identity in your Azure subscription.
2. Assign RBAC Roles: Grant this identity specific permissions on your destination resource. For example, assign the Storage Blob Data Contributor role to allow the identity to manage files in your private storage account.

Phase B: The Power Platform Integration

To make the environment recognize this identity, you must register it as an Application User:

1. Navigate to the Power Platform Admin Center.
2. Go to Environments > [Your Environment] > Settings > Users + permissions > Application users.
3. Add a new app and select the Managed Identity you created in Azure.
   

6. Creating Enterprise Policy using PowerShell Scripts

One of the most important things to realize is that Enterprise Policies cannot be created manually in the Azure Portal UI. They must be deployed via PowerShell or CLI.

While Microsoft provides a comprehensive official GitHub repository with all the necessary templates, it is designed to be highly modular and granular. This means that to achieve a High Availability (HA) setup, an admin usually needs to execute deployments for each region separately and then perform the linking step.

To simplify this workflow, I have developed a Simplified Scripts Repository on my GitHub. These scripts use the official Microsoft templates as their foundation but add an orchestration layer specifically for the Regional Pair requirement:

• Regional Pair Automation: Instead of running separate deployments, my script handles the dual-VNet injection in a single flow. It automates the creation of policies in both regions and links them to your environment in one execution.
• Focused Scenarios: I’ve distilled the most essential scripts for Network Injection and Encryption (CMK), making it easier for admins to get up and running without navigating the entire modular library.

The Goal: To provide a "Fast-Track" experience that follows Microsoft's best practices while reducing the manual steps required to achieve a resilient, multi-region architecture.

Owning the Keys with Encryption Policies (CMK)

While Microsoft encrypts Dataverse data by default, many enterprise compliance standards require Customer-Managed Keys (CMK).
This ensures that you, not Microsoft, control the encryption keys for your environments. - Manage your customer-managed encryption key - Power Platform | Microsoft Learn

Key Requirements:

• Key Vault Configuration: Your Key Vault must have Purge Protection and Soft Delete enabled to prevent accidental data loss.
• The Identity Bridge: The Encryption Policy uses the User-Assigned Managed Identity (created in Step 5) to authenticate against the Key Vault.
• Permissions: You must grant the Managed Identity the Key Vault Crypto Service Encryption User role so it can wrap and unwrap the encryption keys.

7. The Final Handshake: Linking Policies to Your Environment

Creating the Enterprise Policy in Azure is only the first half of the process. You must now "inform" your Power Platform environment that it should use these policies for its outbound traffic and identity.

Linking the Policies to Your Environment:

1. For VNet Injection: In the Admin Center, go to Security > Data and privacy > Azure Virtual Network Policies. Select your environment and link it to the Network Injection policies you created.
2. For Encryption (CMK): Go to Security > Data and privacy > Customer-managed encryption Key.
   • Add the Select the Encryption Enterprise Policy -Edit Policy - Add Environment.
   • Crucial Step: You must first grant the Power Platform service "Get", "List", "Wrap" and "Unwrap" permissions on your specific key within Azure Key Vault before the environment can successfully validate the policy.

Verification: The "Smoking Gun" in Log Analytics

After successfully reaching a Resource from one of the power platform services you can check if the connection was private.
How do you prove its private? Use KQL in Azure Log Analytics to verify the Network Security Perimeter (NSP) ID.
The Proof: When you see a GUID in the NetworkPerimeter field, it is cryptographic evidence that the resource accepted the request only because it arrived via your authorized private bridge.

In Azure Portal - Navigate to your Resource for example KeyVault - Logs - Use the following KQL: 

AzureDiagnostics | where ResourceProvider == "MICROSOFT.KEYVAULT" | where OperationName == "KeyGet" or OperationName == "KeyUnwrap" | where ResultType == "Success" | project TimeGenerated, OperationName, VaultName = Resource, ResultType, CallerIP = CallerIPAddress, EnterprisePolicy = identity_claim_xms_mirid_s, NetworkPerimeter = identity_claim_xms_az_nwperimid_s | sort by TimeGenerated desc

 Result: 

 

By implementing the Network, and Encryption Enterprise policy you transition the Power Platform from a public SaaS tool into a fully governed, private extension of your Azure infrastructure. You no longer have to choose between the agility of low-code and the security of a private cloud.

To summarize the transformation from public endpoints to a complete Zero Trust architecture across regions, here is the end-to-end workflow:

PHASE 1: Azure Infrastructure Foundation

1. Create Network Fabric (HA): Deploy VNets and Delegated Subnets in both regional pairs.
2. Deploy the Hub: Set up the Central Hub VNet with Azure Firewall.
3. Connect Globally: Establish Global VNet Peering between all Spokes and the Hub.
4. Solve DNS: Enable DNS Proxy on the Firewall and link Private DNS Zones to the Hub VNet. ↓

PHASE 2: Identity & Security Prep

1. Create Identity: Generate a User-Assigned Managed Identity (UAMI).
2. Grant Access (RBAC): Give the UAMI permissions on the target PaaS resource (e.g., Storage Contributor).
3. Prepare CMK: Configure Key Vault access policies for the UAMI (Wrap/Unwrap permissions). ↓

PHASE 3: Deploy Enterprise Policies (PowerShell/IaC)

1. Deploy Network Policies: Create "Network Injection" policies in Azure for both regions.
2. Deploy Encryption Policy: Create the "CMK" policy linking to your Key Vault and Identity. ↓

PHASE 4: Power Platform Final Link (Admin Center)

1. Link Network: Associate the Environment with the two Network Policies.
2. Link Encryption: Activate the Customer-Managed Key on the environment.
3. Register User: Add the Managed Identity as an "Application User" in the environment. ↓

PHASE 5: Verification

1. Run Workload: Trigger a Flow or Plugin.
2. Audit Logs: Use KQL in Log Analytics to confirm the presence of the NetworkPerimeter ID.