Routing Decisions That Quietly Create Security Gaps

Thu, 21 May 2026 00:00:00 +1000

Routing still feels like plumbing.

You change where packets go, traffic flows again, and the incident closes. Nothing looks less secure. No rules changed. No alerts fired. Yet something fundamental may have shifted not availability, but who is now allowed to talk to whom.

This post is about routing decisions that don’t break connectivity, they quietly break trust boundaries.

The Mental Model

Common assumption:
Routing is a connectivity concern. Security is enforced elsewhere.

Why it breaks:
In Azure, routing determines the effective security perimeter. If a route expands reachability beyond the documented trust boundary, that expansion is a security failure, regardless of intent.

Security controls only matter if traffic actually traverses them. Routing decides whether they ever get the chance.

How It Really Works

Azure evaluates routing before most security controls can apply policy.

User‑defined routes (UDRs) override platform defaults.
Peering enables reachability that security rules often assume is constrained.
Abstractions hide the effective path until it matters.

Azure will faithfully forward packets along any valid route. It does not validate whether that path aligns with your security intent or whether it expands trust beyond what was ever reviewed.

Routing doesn’t just connect networks.
It redefines the trust model the rest of your security stack assumes.

Routing as an Unreviewed Trust Expansion

Convenience Routes

A common change request:

“We just need workload A to reach service B.”

The route gets added. The problem is solved. But if that route enables A to reach everything B can reach, the trust boundary has already expanded.

No firewall rule changed.
But the security posture did.

If reachability grows beyond what was explicitly documented and approved, the routing change itself is the failure not the firewall configuration.

Asymmetric Paths, Invisible Impact

Azure does not enforce symmetric routing.

It’s easy to create designs where traffic passes through inspection on the way out, but returns via a different path governed by system routes or peering behaviour.

From a security perspective, this means:

Enforcement becomes partial
Logs represent only a subset of reality
Policy confidence decays over time

If you can’t explain the full bidirectional path, you can’t reliably define the trust boundary.

Accidental Transitivity

Routing plus peering enables implicit trust chains.

Network A can reach B.
B can reach C.
A can now often reach C even if nobody intended that relationship to exist.

No new security rule was added.
But effective reachability expanded anyway.

Real‑World Impact

This failure mode shows up operationally, not at design time:

Security reviews pass while posture degrades
Controls are correct, the path is not.
Visibility becomes misleading
Logs show inspected traffic, not all possible traffic.
Change risk compounds silently
Each routing change inherits and extends existing trust relationships.
Security ownership blurs
Routing changes feel “network‑only”, but their impact is architectural.

This changes how routing should be treated in production:
as a security‑significant change, not a connectivity tweak.

Implementation Example: A Route That Expands Trust

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


resource appRouteTable 'Microsoft.Network/routeTables@2023-09-01' = {
 name: 'rt-app-subnet'
 location: resourceGroup().location
 properties: {
 routes: [
 {
 name: 'to-shared-services'
 properties: {
 addressPrefix: '10.40.0.0/16'
 nextHopType: 'VirtualAppliance'
 nextHopIpAddress: '10.20.0.4'
 }
 }
 ]
 }
}

On paper, this sends app traffic through an inspection point.

In practice, this route should be treated as a security failure if:

10.40.0.0/16 contains more than the explicitly intended services
It enables reachability beyond the documented trust boundary
The return path does not traverse the same enforcement points

The route may be technically correct and still security‑incorrect.

Visualising the Trust Shift

flowchart LR A[App Subnet] -->|UDR| F[Inspection Point] F --> B[Shared Services] B --> C[Additional Networks] C -. Implicit Reachability .-> A

The security gap is not the firewall.
It’s the unreviewed expansion of reachability beyond intent.

Gotchas & Edge Cases

Platform‑managed routes may expand reachability without obvious configuration changes.
Multiple route tables create inconsistent trust enforcement across subnets.
Security tooling reports where traffic was seen, not everywhere it could go.

Best Practices

Treat routing changes as trust boundary changes
Document intended reachability, not just IP ranges
Review routes for what they enable, not what they fix
Assume transitivity unless explicitly disproven
If intent and reachability diverge, classify it as a security issue

🍺

Brewed Insight: If routing expands reachability beyond what you can explicitly justify, the design is already insecure even if every security control still looks correct.

Security Architecture on Brewed in the Cloud by Chris Hailes