Skip to content

Portal Walkthrough: Control 1.20 — Network Isolation and Private Connectivity

Last Updated: April 2026 Portals: Power Platform Admin Center (PPAC), Azure Portal Estimated Time: 30–45 minutes for IP firewall + cookie binding; 4–8 hours end-to-end for full VNet + Private Endpoint deployment (excluding Azure platform-team change windows)

Audience and Scope

This walkthrough is for M365 administrators in US financial services who own Power Platform governance for Copilot Studio agents. Azure resource provisioning steps assume coordination with your Azure platform team (Network Contributor on the target subscription/resource group). PPAC steps are owned by the Power Platform Admin.

Use this playbook when implementing Control 1.20 for a Zone 2 (recommended) or Zone 3 (mandatory) environment. For Zone 1, only the documentation step at the end applies.

Prerequisites

  • Managed Environment enabled on the target environment (Control 2.1). IP firewall, cookie binding, and VNet support are Managed-Environment features.
  • Power Platform Admin role for PPAC steps.
  • Azure Network Contributor (or equivalent) on the target Azure subscription / resource group for VNet, subnet, private endpoint, and DNS zone steps.
  • AI Administrator awareness — the agent inventory in the affected environment should be confirmed before Enforce.
  • Power Platform region of the environment confirmed, and the Azure region paired to it identified for both primary and failover Azure regions (subnets are required in both).
  • CIDRs of the firm's egress IPs (proxy, VPN, ZTNA egress) confirmed with the network team — not internal RFC1918 ranges unless those actually egress directly.
  • Change ticket open with reviewers from Security and Compliance assigned.

Sovereign clouds. PPAC URLs differ for GCC (https://gcc.admin.powerplatform.microsoft.us), GCC High (https://high.admin.powerplatform.microsoft.us), and DoD (https://admin.appsplatform.us). Use the matching portal for your tenant.

Step 1 — Configure IP Firewall (PPAC)

  1. Open the Power Platform Admin Center.
  2. Environments → select the in-scope environment (must be Managed).
  3. Settings → Privacy + Security → IP firewall.
  4. Toggle IP firewall to On.
  5. Mode: select Audit only for the initial rollout.
  6. Allowed IP ranges: add corporate egress CIDRs in IPv4 / IPv6 / CIDR form. Examples:
    • 203.0.113.0/24 (proxy egress)
    • 198.51.100.10/32 (single VPN exit)
  7. Apply IP-based cookie binding for non-interactive flows: keep enabled per Microsoft guidance.
  8. Save.

Limits: Up to 200 IP ranges per environment; the address field accepts up to 4,000 characters. Aggregate to CIDR where possible.

Audit-mode duration: Run for at least one full business cycle (typically 5–10 business days, longer if month-end batch jobs, off-shore handoffs, or quarterly reporting touches the environment). Review Dataverse Audit logs and PPAC analytics for IPFirewallAuditMode events before switching to Enforce.

After audit review:

  1. Return to Settings → Privacy + Security → IP firewall.
  2. Change Mode to Enforce and Save. Document the cutover time in the change ticket.
  1. Same blade: Settings → Privacy + Security → IP firewall (cookie binding is in the same area on current UI; on some tenants it appears under Privacy + Security → IP cookie binding).
  2. Toggle IP-address-based cookie binding to On.
  3. If your tenant terminates TLS at a reverse proxy before traffic reaches Microsoft endpoints:
    • Add proxy egress IPs under Reverse proxy IP addresses.
    • Confirm the proxy is configured to forward the original client IP via the standard X-Forwarded-For header (Microsoft-supported header).
  4. Save.

User impact. Users on networks with significant IP churn (consumer carrier-grade NAT, sudden VPN reconnects) may be re-prompted to authenticate. Communicate this expectation to end users and the help desk before enabling in production.

Step 3 — Provision VNet, Delegated Subnets, and Private DNS (Azure Portal)

Owned by the Azure platform team. Run in both the primary Azure region paired with your Power Platform region and the failover region. Microsoft requires both.

3a. Create the VNet

  1. Azure Portal → Virtual networks → + Create.
  2. Subscription / Resource group: per your landing-zone standard (e.g., rg-pp-network-prod-eastus).
  3. Region: the Azure region paired with the Power Platform environment region.
  4. Name: vnet-pp-prod-eastus (use your naming standard).
  5. IP Addresses: address space 10.100.0.0/16 (example).
  6. Subnets:
    • snet-pp-delegated (10.100.1.0/24) — for Power Platform delegation (/24 recommended for production).
    • snet-private-endpoints (10.100.2.0/24) — for the Key Vault / Storage / SQL private endpoints.
  7. Review + create → Create.

3b. Delegate the subnet

  1. Open the new VNet → Subnets → snet-pp-delegated.
  2. Subnet delegation → select Microsoft.PowerPlatform/enterprisePolicies.
  3. Save.

3c. Repeat for the failover region

Create an equivalent VNet (different address space, e.g., 10.101.0.0/16) and delegated subnet in the paired failover Azure region. Both subnets are referenced when you create the enterprise policy.

For each PaaS dependency, create or reuse a Private DNS zone and link it to both VNets:

Dependency Private DNS zone
Key Vault privatelink.vaultcore.azure.net
Azure SQL privatelink.database.windows.net
Storage (blob) privatelink.blob.core.windows.net
Azure Monitor (AMPLS) privatelink.monitor.azure.com, privatelink.oms.opinsights.azure.com, privatelink.ods.opinsights.azure.com, privatelink.agentsvc.azure-automation.net, privatelink.blob.core.windows.net

For each zone: Virtual network links → + Add → select the primary and failover VNets → enable Auto-registration: No (for PaaS Private Link zones).

Microsoft currently performs this step via PowerShell rather than the portal. The PowerShell setup playbook (companion file) provides the canonical scripted version. The PPAC UI shows the link result on the environment's History and Settings blades after the link is created.

In PPAC, after the PowerShell link step completes:

  1. PPAC → Environments → select the environment → Settings.
  2. Updates and policies → Network injection / VNet integration (label varies by tenant version).
  3. Confirm the linked enterprise policy GUID, primary subnet ID, and failover subnet ID match the values from your change ticket.

Step 5 — Create Private Endpoints for Dependencies (Azure Portal)

Repeat for each dependency the agent calls (Key Vault, Storage, Azure SQL, and AMPLS).

Example: Key Vault Private Endpoint

  1. Azure Portal → open the Key Vault.
  2. Networking → Private endpoint connections → + Create.
  3. Name: pe-kv-pp-eastus.
  4. Region: match the Key Vault region.
  5. Resource: target sub-resource = vault.
  6. Virtual network: the Power Platform VNet; Subnet: snet-private-endpoints.
  7. Private DNS integration: Yes → select the existing privatelink.vaultcore.azure.net zone.
  8. Review + create → Create.

After creation:

  1. Key Vault → Networking → Public access → Disable public access, or restrict to "Allow trusted Microsoft services" only if the firm's standard requires it.
  2. Confirm the firewall tab shows Allow public network access from specific virtual networks and IP addresses: Disabled (or the equivalent in the latest UI).

Repeat the pattern for Storage, Azure SQL (sub-resource sqlServer), and the AMPLS for Application Insights / Log Analytics. For AMPLS:

  • Create the Azure Monitor Private Link Scope resource.
  • Add the in-scope Application Insights components and Log Analytics workspaces.
  • Create a private endpoint targeting the AMPLS scope (sub-resource azuremonitor).
  • Set the AMPLS Access modes for ingestion and queries to Private Only for Zone 3 (use Open during initial migration to avoid telemetry gaps, then tighten).

Step 6 — Reconcile with Conditional Access (Control 1.11)

  1. Open the Microsoft Entra admin center → Protection → Conditional Access → Named locations.
  2. Confirm the same egress CIDRs used in Step 1 are represented as Trusted IPs named locations.
  3. If a Conditional Access policy gates Power Platform access by named location, ensure its IP set matches or is a subset of the IP firewall allowlist. Mismatches cause confusing user-facing errors that look like sign-in failures but are network rejections (or vice versa).

Step 7 — Document and Attest

  1. Update the environment's network architecture diagram (the firm's diagramming standard; Visio / draw.io / Mermaid). Include: agents in scope, environment, delegated subnet, VNet peering or links, private endpoints, dependency resources, AMPLS, and the egress proxy.
  2. Attach the diagram to the change record and the supervisory file.
  3. Capture screenshots of the IP firewall (Enforce mode), cookie binding toggle, subnet delegation, and at least one private endpoint in Approved state, plus an nslookup from a VM in the VNet showing the dependency FQDN resolving to a 10.x.x.x address.
  4. Record reviewer sign-offs from Security and Compliance in the change ticket.

Configuration by Governance Level

Setting Baseline (Zone 1) Recommended (Zone 2) Regulated (Zone 3)
Managed Environment Optional Required Required
IP firewall Off (documented) Enforce Enforce
Cookie binding Off On On (with reverse-proxy headers if applicable)
VNet integration Not required Recommended when calling Azure dependencies Mandatory (primary + failover)
Private Endpoints Not required Required for dependencies holding NPI Required for Key Vault, Storage, SQL, AMPLS
Public network access on dependencies Default Disable for NPI-bearing resources Disabled
NSG flow logs / Traffic Analytics Not required Recommended Required
Re-attestation cadence Annual Semi-annual Quarterly

Validation

After completing the steps above, the Verification & Testing playbook walks through the test cases. At minimum, before closing the change ticket:

  • IP firewall is in Enforce mode and a test from a non-allowlisted IP returns 403.
  • Cookie binding is on and a controlled cookie-replay test (non-production) is rejected.
  • Get-PowerAppEnvironmentEnterprisePolicy returns the linked policy with the expected primary and failover subnet IDs.
  • nslookup from a VM in snet-private-endpoints resolves Key Vault, SQL, and AMPLS FQDNs to 10.x.x.x.
  • Public network access is Disabled on all in-scope dependencies.
  • Architecture diagram and screenshots attached to the change ticket.

Back to Control 1.20 | PowerShell Setup | Verification & Testing | Troubleshooting