The traditional network perimeter didn’t fail overnight.
It faded, quietly, as organisations kept asking it to do jobs it was never designed for.
Not because security teams were wrong, but because the environment changed faster than the trust model.
Most enterprises still have a perimeter.
The problem is that many still treat it as authoritative.
The Mental Model
The common assumption
The long‑standing assumption goes something like this:
If a user is on the corporate network, we can trust them more.
That assumption underpins:
- VPN‑centric access models
- “Internal” vs “external” application classifications
- Firewall rules as primary user controls
- Security reviews anchored on ingress paths
It’s not reckless. It’s conservative.
And increasingly, it’s misleading.
Why it breaks
This model assumes:
- Network location is a stable signal
- Users reliably traverse centralised controls
- IP addresses approximate identity
In modern enterprises, none of these hold consistently, especially under change.
How It Really Works
The perimeter didn’t move to the cloud.
It lost its authority as the default trust boundary for users.
SaaS dissolved application ownership
Most critical applications are no longer behind your firewall:
- Microsoft 365
- Salesforce
- ServiceNow
- GitHub
You don’t own their networks. You don’t control their ingress paths.
Routing users “inside” first doesn’t increase trust, it just adds friction.
The applications that matter most are now outside the perimeter by design.
Remote work normalised untrusted networks
Users now work from:
- Home broadband
- Shared Wi‑Fi
- Mobile networks
- Client environments
Each introduces:
- IP churn
- Carrier‑grade NAT
- Shared address space
Network location stopped being a reliable indicator of who a user is or how they’re working.
Cloud platforms removed static boundaries
In Azure:
- IPs are ephemeral
- Services scale dynamically
- Platform traffic often bypasses traditional inspection
You can still draw boundaries, but they don’t stay still, and they don’t answer identity questions.
The real shift
The perimeter still exists.
What’s changed is that it no longer answers the most important question:
Should this user be allowed to do this right now?
Visualising the Shift
This is the practical change most architectures are grappling with.
The network hasn’t disappeared, it’s been demoted.
It’s now a signal, not the decision point.
Real‑World Impact
The most damaging failures of the perimeter model aren’t breaches.
They’re operational.
Change becomes the primary failure mode
IP‑based trust struggles with:
- New SaaS onboarding
- Remote worker growth
- Mergers and divestments
- Incident‑driven access changes
Under pressure, teams respond predictably:
- Broaden firewall rules
- Extend VPN scopes
- Add “temporary” exceptions
- Defer clean‑up indefinitely
Security erodes not through attack, but through accommodation.
Defence in depth becomes defence by inertia
Layers remain in place because:
- Removing them feels risky
- Ownership is unclear
- No single control is obviously broken
Over time, controls exist less to reduce risk and more to avoid uncomfortable conversations.
Users route around centralisation
When access paths are:
- Slow
- Fragile
- Incompatible with how people work
Users find alternatives.
Architectures that assume compliance instead of expecting bypass age badly.
Implementation Examples
Intentionally omitted.
This post focuses on why the perimeter has lost authority, not how to replace it.
Specific Azure controls, policies, and access patterns are covered later in this series once the trust model is clear.
Gotchas & Edge Cases
The perimeter still matters for workloads
East‑west traffic, data residency, and regulatory boundaries don’t disappear. This post is about user access, not service‑to‑service isolation.Choosing a perimeter‑centric model isn’t negligent
It can be a valid business decision, but it must be treated as a conscious risk, not a safe default.Legacy applications complicate everything
They don’t invalidate the shift; they increase the cost of ignoring it.
Best Practices (Design Consequences)
- Treat network location as context, not authority
- Assume users will access applications from outside your ideal path
- Expect exceptions to accumulate under change, and design accordingly
- If “being on the network” is still your primary trust signal, make the risk explicit