Most Azure environments are beautifully segmented, on paper.

Prod, non‑prod, shared services, landing zones. Clean lines. Sensible colours. Everyone agrees where the trust boundaries are supposed to be.

Then a single workload gets compromised, and suddenly the attacker has options.

Not because anyone misconfigured a firewall.
Because the boundary never existed at runtime.

The Mental Model

Common assumption:

“Different subscriptions, VNets, or environments imply different trust levels.”

Why it breaks:
Azure does not enforce trust.
Azure enforces reachability.

A trust boundary only exists where no routable path exists at runtime.
If packets can flow, trust already exists regardless of ownership, intent, or documentation.

Everything else is risk management dressed up as segmentation.

How It Really Works

Azure networking behaves like software, not policy.

Once east–west reachability is present:

• The platform routes packets without regard for environment labels
• Subscriptions are ignored entirely by the data plane
• VNets become peers the moment routing allows it
• Workloads assume whatever the network allows them to see

What architects often describe as “implicit trust” is actually emergent trust — created unintentionally by routing decisions.

Three types of trust are routinely conflated:

Only one of these determines lateral movement potential: network reachability.

Real‑World Impact

This is why east–west traffic is the real attack surface.

In live Azure estates, “diagram‑only” boundaries collapse into:

• Shared services VNets acting as lateral movement bridges
• Hub‑and‑spoke designs where isolation is assumed, not enforced
• Environment separation that disappears once routing converges
• Legacy peerings that quietly expand blast radius year after year

From an attacker’s perspective, the estate is mapped by a single question:

“What IP space can I reach next?”

If the answer spans environments, subscriptions, or tiers — the boundary was imaginary.

How would this change something I design, deploy, or operate?
You stop asking who owns this network and start asking what can this workload actually reach at runtime.

Implementation Examples

The Invisible Trust of VNet Peering

Nothing here declares trust:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

resource spokeToHubPeering 'Microsoft.Network/virtualNetworks/virtualNetworkPeerings@2023-09-01' = {
  name: 'spoke-to-hub'
  parent: spokeVnet
  properties: {
    remoteVirtualNetwork: {
      id: hubVnet.id
    }
    allowVirtualNetworkAccess: true
    allowForwardedTraffic: true
    useRemoteGateways: false
  }
}

But at runtime:

• Routes are exchanged
• IP reachability exists
• Any listening service becomes a lateral movement candidate

The trust relationship is not configured.
It emerges.

Peering itself isn’t “transitive” — but reachability becomes effectively transitive once routing and shared paths exist.

That distinction matters operationally, not architecturally.

Visualising Trust vs Reachability

Most diagrams show connectivity.
Attackers care about paths.

Intended trust:

• Prod trusts Shared
• Non‑Prod trusts Shared
• Prod does not trust Non‑Prod

Runtime reality:

• Prod ↔ Shared ↔ Non‑Prod
• A routable path exists
• Therefore, trust exists

The network does not infer your intent.
It enforces physics.

Gotchas & Edge Cases

• Subscription boundaries have zero impact on packet flow
• Environment naming is invisible to the data plane
• “Temporary” peerings almost never get removed
• Shared services quietly accumulate the widest blast radius
• Once breached, containment follows routing — not diagrams

None of this requires negligence.
It emerges from reasonable defaults applied over time.

Best Practices

• Treat absence of reachability as the only real trust boundary
• Assume any routable east–west path will eventually be abused
• Design shared services as risk concentrators, not neutral hubs
• Regularly review effective reachability, not intended architecture
• If two environments must not trust each other, they must not be routable — full stop

This is Assume Breach applied to network design, not policy.

Learn More

• Azure virtual network peering overview
• Azure networking security overview
• Implement security breach prevention and recovery infrastructure