Most Azure environments don’t fail because someone opened the perimeter too wide.
They fail because inside the network, everything slowly learned it didn’t need to ask anymore.
Reachability became normal. Then expected. Then invisible.
By the time anyone questions it, the network has already answered yes on their behalf.
The Mental Model
Common assumption:
“If traffic is inside the VNet or coming from on‑prem it’s already trusted.”
This isn’t usually stated out loud. It just emerges.
VNets start small. On‑prem connectivity is enabled for migration speed. Shared services need to be reachable. Early workloads benefit from convenience, and nothing breaks.
Why it misleads:
VNets don’t stay small and neither does connectivity intent.
As environments grow, reachability expands faster than understanding. What began as a deliberate exception turns into a default, and “inside the network” quietly becomes shorthand for safe enough.
That’s not a security philosophy problem.
It’s a network failure caused by trust inheritance.
How It Really Works
Azure VNets are routing domains, not trust domains.
They provide:
- Layer‑3 connectivity
- Flat reachability by default
- No concept of workload sensitivity or intent
Azure is doing exactly what it’s designed to do.
The failure happens when connectivity is treated as authorisation especially across boundaries that were never meant to be peers.
Over time, this pattern emerges:
- On‑prem networks can reach most VNets
- New workloads inherit that reachability automatically
- No explicit decision is made because none is required
At that point, the network isn’t enforcing intent.
It’s amplifying convenience.
The Real Question You’re Facing
You’re not choosing between open and locked‑down networking.
You’re choosing between:
- Implicit trust via reachability, or
- Explicit trust via declared intent
If on‑prem can reach everything simply because it’s on‑prem, the network has already made a trust decision it just didn’t document it.
A Necessary Reframe: On‑Prem Is a Zone, Not a Peer
In a mature Azure environment, on‑prem should not be treated as “just another VNet”.
It is a distinct network zone with different ownership, lifecycle, and failure characteristics.
A defensible default looks like this:
On‑prem can reach shared services by default.
Workload networks must opt‑in.
This isn’t about assuming compromise.
It’s about preventing ambient trust from spreading via routing.
Real‑World Impact
This failure mode shows up operationally long before any incident.
Design impact
- New workloads become reachable from on‑prem without discussion
- Architects can’t clearly state why certain paths exist
- Shared services quietly become transit points
Operational impact
- Connectivity reviews focus on NSGs instead of intent
- Change risk increases because blast radius is unclear
- Removing access is harder than granting it ever was
Security impact
- Internal boundaries blur
- Lateral movement becomes a property of the network
- Containment relies on “nothing changing” rather than design
The network didn’t break suddenly.
It drifted and no one noticed.
Implementation Examples
What Over‑Trust Looks Like at Scale
After a few years of growth, many environments resemble this:
Nothing here violates Azure best practices.
The failure is behavioural:
- On‑prem reachability is assumed, not justified
- New VNets inherit access automatically
- No one can say which paths are intentional
How the Failure Creeps In
A typical peering or gateway configuration (simplified):
| |
This isn’t wrong.
But over time, it’s interpreted as:
“Anything internal can probably talk to this.”
That assumption scales faster than architecture diagrams.
Gotchas & Edge Cases
Private endpoints don’t fix this
They often reinforce the idea that “private” equals “safe”, even as reachability expands.Peering intent fades faster than peering configs
The network remembers decisions long after teams forget why they were made.Change velocity accelerates trust drift
Especially when new workloads are created by teams far from the original design.
Best Practices (Without Tooling)
Staying within network design, not enforcement:
- Define where on‑prem can reach by default and write it down
- Treat workload reachability as an opt‑in decision
- Periodically review which paths exist purely because they’re easy
- Design shared services as intentional choke points, not accidental hubs
These are design disciplines, not firewall strategies.