If you’re in an airport or café, you don’t join every open Wi‑Fi network just because your laptop can see it.

You make a trust decision often subconsciously about which networks you’re willing to attach yourself to.

In Azure networking, we routinely forget that same rule.

VNets get peered. Shared services get connected. Temporary exceptions become permanent.
Connectivity is established and trust quietly follows, whether anyone intended it or not.

This post is about what happens when organisational trust and network trust stop lining up and why that gap becomes a long‑term security failure mode.

The Mental Model

Common assumption:

Subscriptions, VNets, and peering boundaries reflect how much we trust different teams and workloads.

Why it breaks:
Azure networking has no concept of intentional trust. It only understands reachability.

If two networks can communicate:

• Trust exists
• Authority exists
• Blast radius exists

Whether that aligns with how your organisation actually thinks about risk is irrelevant to the platform.

Just like Wi‑Fi, the network won’t stop you joining something unsafe it assumes you meant to.

How It Really Works

VNet peering itself is not technically transitive. Azure won’t magically forward traffic through multiple peerings.

But trust becomes transitive in practice through three mechanisms:

1. Routing
   Once networks can exchange routes, traffic paths emerge that were never explicitly designed.

2. Name resolution
   Shared or linked Private DNS zones turn reachability into discoverability a subtle but powerful trust signal.

3. Shared platform services
   Firewalls, Bastion, jump hosts, monitoring agents, outbound NAT these services often sit inside a network that everyone peers to.

Azure does not distinguish between:

• “I trust this network with production data”
• “I just needed DNS during a migration”

Connectivity is connectivity. Trust is implied.

Real‑World Impact

1. Shared Services VNets Become Trust Authorities

A shared services VNet is often described as “just plumbing”.

In reality, once it is broadly peered, it becomes part of your security boundary.

Anything that can:

• Resolve names
• Route traffic
• Enforce (or bypass) inspection
• Act as an administrative entry point

…is no longer neutral infrastructure. It is trusted.

This is not inherently wrong but it is frequently unacknowledged.

2. Trust Outlives the Reason It Was Granted

Most peerings are created for good reasons:

• Migrations
• Platform integrations
• Temporary access
• “We’ll clean this up later”

The problem is not the decision, it’s the lack of an expiry.

Years later:

• Teams have changed
• Workloads have been repurposed
• Environments have shifted criticality

The network still enforces yesterday’s trust model with today’s consequences.

3. Subscription Boundaries Provide False Comfort

Subscriptions feel like security boundaries because they align with:

• Cost centres
• Ownership
• RBAC (Role-Based Access Control)

But from a network perspective, once peered, they are irrelevant.

A compromised workload doesn’t care which subscription it lives in only which networks it can talk to.

Implementation Example: Accidental Trust by Connectivity

A familiar pattern:

This diagram looks tidy. Centralised. Sensible.

What it doesn’t show:

• That Non‑Prod and Legacy now share a trust anchor with Prod
• That Hub failures propagate everywhere
• That any misjudgement in Hub affects all environments equally

The network has no way to express “I trust this less”.

Concrete Artefact: Trust With No Intent or Expiry

A typical peering definition:

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

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

This resource encodes:

• Connectivity
• Routing behaviour
• Gateway inheritance

What it does not encode:

• Why the trust exists
• How long it should exist
• What level of risk was accepted

From the platform’s perspective, this is a permanent trust relationship.

Gotchas & Edge Cases

• Private DNS is a trust amplifier
  If a workload can resolve a private endpoint name, someone assumed it was allowed to exist in the same trust domain.

• Temporary peerings rarely get removed
  Especially those created during incidents or migrations.

• Inherited routing bypasses original threat models
  UDRs and forced tunnelling often survive long after the assumptions that justified them.

• Security reviews skew toward new designs
  Drift happens in the parts of the network nobody wants to touch.

Best Practices (Without Turning This Into Segmentation Advice)

• Treat network adjacency as a trust decision
  If you wouldn’t join an unknown Wi‑Fi network, don’t implicitly trust a VNet just because it’s convenient.

• Assume trust decays over time
  Every peering should eventually be questioned, even if nothing appears broken.

• Design shared services as least‑trusted, not most‑connected
  Broad reach does not mean broad trust.

• Review trust, not just topology
  Ask who is trusted to talk to whom and whether that still matches reality.

Learn More

• Azure Virtual Network peering
• Azure Firewall architecture considerations