Most organisations think they’ve implemented Zero Trust because they’ve rolled out MFA, application whitelisting, hardened endpoints, and locked down identity in Microsoft 365. On paper, it looks solid. In reality, it’s incomplete.
The blind spot? The network.
In my experience working across enterprise environments, this is where Zero Trust efforts fall apart. Once traffic gets inside the network—especially east-west traffic between servers, workloads, and applications—it often moves with far less scrutiny than it should. Flat networks, legacy VLAN designs, and implicit trust between systems still dominate.
Attackers know this. That’s why modern breaches don’t stop at initial access—they pivot, move laterally, and escalate privileges using the network itself as the highway.
Extending Zero Trust to the network means applying the same principles we already use for users and endpoints—verify explicitly, assume breach, and enforce least privilege—to how data flows. Not just who is accessing, but what is talking to what, and why.
In this guide, I’ll walk through how to extend Zero Trust into the network layer, including practical steps, real-world configurations, and the mistakes I see most IT teams making.
Quick Fix Summary
If you’re short on time, here’s where to start:
- Implement micro-segmentation to restrict east-west traffic
- Replace flat VLANs with identity-aware network controls
- Enforce application-level access policies, not just network ACLs
- Monitor and log all lateral movement traffic
- Use tools like conditional access, firewalls, and NDR together—not in silos
Why the Network Is the Weakest Link in Zero Trust
Zero Trust is often treated as an identity problem. That’s only half the story.
The Reality in Most Environments
- Internal traffic is often implicitly trusted
- VLANs are used for segmentation, but rarely enforced strictly
- Firewalls focus on north-south traffic, ignoring east-west
- Service accounts and legacy protocols bypass modern controls
Real-World Scenario
I’ve seen environments where:
- MFA is enforced everywhere
- Devices are compliant via Intune
- Conditional Access is tightly configured
…but a compromised server was able to:
- RDP laterally across the environment
- Query Active Directory freely
- Access file shares without restriction
Why? Because the network allowed it.
Step-by-Step: Extending Zero Trust to the Network Layer
1. Identify and Map East-West Traffic
Before locking anything down, you need visibility.
Tools You Can Use
- NetFlow / sFlow collectors
- Firewall logs
- Network Detection & Response (NDR) tools
- Azure Network Watcher (for cloud environments)
Example: PowerShell Netstat Snapshot
Get-NetTCPConnection | Select-Object LocalAddress, RemoteAddress, State
This gives a quick snapshot of active connections—useful for identifying unexpected communication paths.
What to Look For
- Servers talking to systems they shouldn’t
- Unusual ports (e.g., SMB, RDP, WinRM across tiers)
- High-volume lateral traffic
2. Implement Micro-Segmentation (Not Just VLANs)
Traditional VLANs are not Zero Trust. They’re coarse and often poorly enforced.
What You Should Be Doing Instead
- Segment based on application roles, not just IP ranges
- Enforce policies at host or workload level
- Use software-defined networking (SDN) where possible
Example Approaches
| Approach | Tooling |
|---|---|
| Host-based firewall rules | Windows Defender Firewall |
| Identity-based segmentation | Azure AD + Conditional Access |
| SDN segmentation | VMware NSX, Azure Virtual Network |
Example: Windows Firewall Rule
New-NetFirewallRule -DisplayName "Allow App Server to DB" `
-Direction Outbound -Protocol TCP -RemotePort 1433 `
-RemoteAddress 10.10.2.10 -Action Allow
This enforces least privilege at the host level—not the network edge.
3. Enforce Identity-Aware Network Access
Zero Trust networking is not just about IPs—it’s about identity.
Key Concept
Who (or what) is making the connection matters more than where it comes from.
Implementation Options
- Conditional Access policies tied to applications
- Azure Private Access / Zero Trust Network Access (ZTNA)
- Replace VPNs with identity-aware proxies
Real-World Shift
Instead of:
“Allow subnet 10.10.1.0/24 to access server X”
Move to:
“Allow only authenticated, compliant devices running approved apps to access server X”
4. Lock Down Lateral Movement Paths
This is where most breaches expand.
High-Risk Protocols to Restrict
- RDP (3389)
- SMB (445)
- WinRM (5985/5986)
- LDAP / Kerberos
Example: Blocking Lateral RDP
New-NetFirewallRule -DisplayName "Block RDP Lateral" `
-Direction Inbound -Protocol TCP -LocalPort 3389 `
-RemoteAddress 10.0.0.0/8 -Action Block
Then explicitly allow only jump hosts or privileged access workstations.
5. Monitor, Log, and Validate Continuously
Zero Trust is not “set and forget.”
Minimum Logging You Need
- Firewall logs (allow + deny)
- Authentication logs
- DNS logs
- Network flow data
What Good Looks Like
- You can trace any connection from source to destination
- You can identify why it was allowed
- You can quickly detect anomalies
Real-World Implementation Example
Scenario: Securing a Hybrid Environment
An organisation running:
- On-prem AD + file servers
- Azure workloads
- Microsoft 365
Before
- Flat internal network
- VPN access to entire subnet
- Minimal east-west controls
After
- Azure AD Conditional Access enforced
- Servers segmented by role (web, app, DB)
- SMB restricted to specific systems only
- Admin access only via hardened jump hosts
- VPN replaced with ZTNA
Outcome
- Lateral movement reduced dramatically
- Audit visibility improved
- Incident response time cut in half
Additional Tips / Pro Tips
🔧 Pro Tip: Start with Audit Mode
Before enforcing rules, log and observe. You’ll break fewer things.
⚠️ Warning: Legacy Applications Will Push Back
Older systems often require:
- Broad network access
- Unencrypted protocols
- Static IP-based rules
Plan exceptions carefully—but don’t let them dictate your architecture.
🔍 Pro Tip: Use “Deny by Default” Gradually
Flip the model over time:
- Monitor traffic
- Define allowed flows
- Block everything else
🧠 Best Practice: Align Network and Identity Teams
Zero Trust fails when:
- Network teams manage firewalls
- Identity teams manage access
- No one owns the full picture
FAQ Section
1. What is Zero Trust networking?
Zero Trust networking applies Zero Trust principles to network traffic, ensuring that all communication is verified, authenticated, and authorised—regardless of location.
2. Is VLAN segmentation enough for Zero Trust?
No. VLANs provide basic separation but lack identity awareness and fine-grained control. Micro-segmentation and policy-based controls are required.
3. How do I stop lateral movement in my network?
Implement:
- Host-based firewalls
- Strict access rules for RDP/SMB
- Network segmentation
- Monitoring and alerting
4. Do I need to replace my VPN?
Not immediately, but modern Zero Trust Network Access (ZTNA) solutions provide more granular, identity-aware access and are a better long-term approach.
5. What’s the biggest mistake in Zero Trust networking?
Focusing only on identity and endpoints while leaving the internal network largely unrestricted.
Conclusion / Actionable Takeaways
Extending Zero Trust to the network is where theory meets reality. It’s also where most organisations fall short.
If you take one thing away, it should be this: Zero Trust doesn’t stop at login.
Your Next Steps
- Map your internal traffic flows
- Identify high-risk lateral movement paths
- Implement micro-segmentation incrementally
- Enforce identity-aware access controls
- Continuously monitor and refine
In my experience, the organisations that get this right don’t just improve security—they gain visibility, control, and confidence in their environment.
Last Updated
Last Updated: April 2026
Aligned with current best practices across Windows Server, Microsoft 365, and modern Zero Trust architecture models.
From my early days on the helpdesk through roles as a service desk manager, systems administrator, and network engineer, I’ve spent more than 25 years in the IT world. As I transition into cyber security, my goal is to make tech a little less confusing by sharing what I’ve learned and helping others wherever I can.