Hybrid networking usually starts with good intentions.
A site‑to‑site VPN or ExpressRoute is approved to “unlock value”. Azure workloads need to talk to on‑prem systems, operations need visibility, shared services need reach. The diagram still shows two boxes, so it feels contained.
But the moment east–west traffic crosses that link, containment stops being an architectural fact and becomes an assumption.
And assumptions don’t survive attackers.
The Mental Model
Common assumption:
On‑prem and Azure are separate security domains that just happen to be connected.
Why it breaks:
East–west traffic doesn’t understand organisational boundaries. Once routing and DNS align, hybrid connectivity collapses those domains into a single lateral movement surface selectively, but decisively.
Hybrid doesn’t “extend” your network.
It redefines adjacency.
How It Really Works
Hybrid east–west behaves less like cross‑environment communication and more like internal traffic with extra hops.
Three forces make this unavoidable.
1. Routing Turns Distance into Trivia
From a packet’s perspective, an RFC1918 prefix reachable via ExpressRoute or VPN is just another route.
If Azure workloads can route to on‑prem subnets, then adjacency exists regardless of intent, documentation, or team boundaries.
This is where many designs fail quietly: segmentation may exist within environments, but hybrid routing stitches those segments together in ways no single team models end‑to‑end.
2. DNS Collapses Discovery
Shared DNS is the most underestimated hybrid risk.
Private DNS zone links, conditional forwarders, split‑horizon records, all introduced for operability unify discovery across environments. Once names resolve, targets are discoverable. Once discoverable, they are reachable by design.
Hybrid DNS rarely mirrors trust boundaries. It mirrors convenience.
3. Legacy Trust Survives the Move
This is the uncomfortable part.
Treating Azure VNets as an extension of the on‑prem “internal network” is no longer a risk it is an architectural failure.
That failure usually shows up as:
- Broad RFC1918 route advertisement
- Shared DNS namespaces without containment intent
- Implicit trust based on IP origin rather than workload purpose
These assumptions made sense in legacy estates. Carrying them into Azure turns hybrid connectivity into an amplifier for lateral movement.
Real‑World Impact
This materially changes how you design, deploy, and operate hybrid estates.
Containment Stops at the Wrong Places
If a compromised Azure workload can:
- Resolve on‑prem service names
- Route to broad on‑prem prefixes
- Reach shared or management services
Then containment is no longer environment‑scoped. It’s estate‑wide.
At that point, “hybrid” is not a boundary it’s a corridor.
Blast Radius Expands by Default
Most hybrid designs are asymmetric:
- Azure workloads gain broad on‑prem reach
- On‑prem systems only require narrow Azure access
That imbalance is perfect for lateral movement out of Azure and into legacy environments where controls are weakest and trust is highest.
Change Control Quietly Becomes a Security Decision
Adding a VNet peering, linking a DNS zone, or advertising a new route can silently expand the attack surface.
These changes are often treated as networking hygiene, not trust‑boundary modifications.
That mismatch is structural, not procedural.
Implementation Examples
Visualising the Hybrid East–West Surface
The tunnel isn’t the risk.
Everything that becomes reachable because of it is.
Once routing and DNS align, lateral movement doesn’t care which side of the cloud boundary it starts on.
Route Reality Check (Azure CLI)
This isn’t about configuring routes it’s about recognising adjacency.
| |
If an application NIC shows broad on‑prem prefixes with a Virtual network gateway next hop, the question is no longer “is this needed?”.
It’s “why is this workload adjacent to legacy infrastructure at all?”
That output isn’t just diagnostic data.
It’s evidence of a trust decision already made.
Gotchas & Edge Cases
“Doesn’t This Explode Cost and Complexity?”
Yes, it can.
Rejecting universal hybrid adjacency often means:
- More deliberate workload placement
- Fewer but more intentional hybrid crossing points
- Increased up‑front design effort
What it does not automatically mean:
- One tunnel per workload
- Dozens of ExpressRoutes
- Infinite network sprawl
Most estates don’t suffer because they have too many hybrid connections.
They suffer because everything is allowed to use the same one.
Flat hybrid designs trade visible complexity for invisible blast radius. The cost doesn’t disappear — it just shows up later, under incident response and compensating controls.
“But It’s ExpressRoute, It’s Private”
Private doesn’t mean constrained.
ExpressRoute often increases east–west risk because it:
- Encourages broader route propagation
- Reduces perceived scrutiny
- Becomes the default path for “just make it work” connectivity
The transport isn’t the issue. Reachability is.
Asymmetric Visibility Persists
Hybrid east–west paths routinely cross tooling boundaries:
- Azure flow logs on one side
- Legacy monitoring on the other
No single team sees the full lateral path. That blind spot is architectural, not operational.
Best Practices
- Treat hybrid routing and DNS changes as trust‑boundary decisions
- Minimise advertised prefixes, especially management and shared services
- Avoid universal hybrid adjacency by default; justify it explicitly
- Review effective routes from workload NICs, not diagrams
- Accept that reducing blast radius may increase design effort and choose it anyway
This isn’t about blocking traffic.
It’s about being intentional about who becomes adjacent to what.
If everything is hybrid‑adjacent, then cloud and on‑prem aren’t environments anymore they’re just terrain.