# Resynchronize Azure peering after changing a member's address space

> Include the peering connection in the address-space change rather than closing the work at the VNet update.

- Canonical URL: https://update.dsesecurity.com/updates/dse-20260909-226-resynchronize-azure-peering-after-changing-a-member-s-address-space/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-09-10T00:28:10+00:00
- Modified: 2026-09-10T01:20:46+00:00
- Last reviewed by DSE: 2026-09-09
- Resource type: Guide
- DSE priority: Information
- Topics: Cybersecurity, Networks & Infrastructure
- Reading time: 2 minutes

## What you need to know

Include the peering connection in the address-space change rather than closing the work at the VNet update.

## Potentially affected

Peered Azure virtual networks, including networks in different subscriptions or Entra tenants.

## DSE recommendation

Include connection resynchronization and tests of the changed prefixes in the address-space change record.

## Article

## Source facts

Microsoft’s cross-subscription peering guidance requires resynchronizing a connection after changing a member network’s address space. The synchronization reflects the changed prefixes in the peering relationship.

The same procedure considers peering established when both networks show Connected. It supports peering Resource Manager virtual networks across different subscriptions and Entra tenants. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/virtual-network/create-peering-different-subscriptions).

## Applicability

Identify the network being changed and every peering relationship that depends on its address space. Record the old and proposed ranges, the owner of each peer and the application paths that must use the new range.

## DSE recommendation

DSE recommends making synchronization a named task with an owner in the address-change plan. Coordinate the two network owners before the change window and retain the original prefix map for comparison. Do not close the change solely because the VNet’s address-space field displays the intended value. Keep unrelated routing or access-policy changes separate so failures can be attributed accurately.

## Verification

After an approved change and synchronization, inspect both peering states and compare the resulting configuration with the planned prefix map. Exercise a representative permitted connection using the changed range, as well as a path that should remain restricted. Record the addresses actually tested and any unresolved discrepancy. Treat Connected as one configuration check, not a substitute for validating the intended application path.

## Official references

[Microsoft Learn: Create Virtual Network Peering Between Different Subscriptions](https://learn.microsoft.com/en-us/azure/virtual-network/create-peering-different-subscriptions). Source retrieved September 9, 2026.

## Primary reference

- Name: Create Virtual Network Peering Between Different Subscriptions - Azure Virtual Network | Microsoft Learn
- Authority: Microsoft Learn
- URL: https://learn.microsoft.com/en-us/azure/virtual-network/create-peering-different-subscriptions
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Resynchronize Azure peering after changing a member's address space,” DSE Security, https://update.dsesecurity.com/updates/dse-20260909-226-resynchronize-azure-peering-after-changing-a-member-s-address-space/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.