Zero Trust Foundations: Running AAVI Through the Network Pillar
Why "where the request came from" stopped being a trust decision, and how SDN, microsegmentation, and VPN retirement fit into the answer.
Summary: This week we bring the Network pillar into our transaction flows and Zero Trust policy statements. For a long time, network location did most of the heavy lifting in security decisions: inside the network meant trusted, outside meant suspicious. Zero Trust asks us to retire that assumption entirely. We will run Network through AAVI, look at east-west and north-south traffic, bring SaaS and partner connections into the picture, and talk about why software defined networking is a core discipline rather than a nice-to-have. We will also talk about the retirement of VPN, for internal users, external users, and partners alike, since this is usually where organizations start making real Network pillar progress.
Grab a fresh cup of coffee, because this is the pillar where a lot of long-standing habits get questioned out loud. Last time, we ran AAVI through the Device pillar and asked whether a request should be trusted based on the health of the device or workload making it. This time we ask a related but different question: once identity and device have said yes, how far should that request actually be allowed to travel, and does it matter where it started from?
Spoiler for anyone who has been in security for more than a few years: the honest answer is no, not anymore, and that is a bigger shift than it sounds like. It is also exactly the gap behind some of the more painful headlines of the last couple of years, including actively exploited vulnerabilities in VPN concentrators and edge network appliances that were trusted simply because they sat at the perimeter. When the front door itself becomes the vulnerability, "inside the network" stops meaning anything useful.
Network Location Plays No Part in the Trust Decision
Here is the idea that Zero Trust asks us to accept fully, not partially: network location tells you almost nothing about whether a request should be trusted. Being on the corporate network, being on the VPN, being inside the data center walls, none of that is evidence of good intent. It never really was, but for a long time we treated it as if it were, because it was easier to build a wall than to evaluate every request individually.
Traditional network security assumed that if traffic made it past the perimeter, it was probably fine. That assumption is precisely what attackers have learned to exploit. Compromise one VPN credential, one edge device, one flat internal network, and you inherit the trust that the network location was supposed to represent. In a Zero Trust architecture, location is just one more piece of context, and a fairly weak one at that. The real questions are: who is asking, from what device or workload, requesting what action, against what data, and does the path that request is taking match what we expect for that specific transaction?
That reframing is not academic. It changes how we design the network itself, and it is why this pillar tends to generate the most architectural pushback of the five. Nobody wants to hear that the wall they spent a decade building is not actually doing the job everyone assumed it was doing.
Our Model Protect Surface, Continued
Back to our messy hybrid business application: on premises core, legacy database, corporate identity platform, SaaS analytics export, cloud file storage, internal admin tools, and vendor support access. Now we ask the Network question about the same transactions. When the finance user views customer records, what path does that traffic take, and would we notice if it suddenly took a different one? When the service account moves data to SaaS analytics, is that connection scoped to exactly the destination it needs, or can it technically reach half the data center? When the vendor connects for support, are they landing on a broad internal network segment, or a narrow, purpose built path that only reaches the systems they are actually supposed to touch?
Notice how this builds on Identity and Device rather than replacing them. A known identity, on a healthy device, still should not be able to reach systems and data it has no business reaching just because the network allows it. Network is where we decide how far trust is allowed to extend once it has been granted, and whether that reach is proven or just assumed.
East-West and North-South Traffic Both Matter
A quick vocabulary note before we go further, since this trips people up. North-south traffic is the traffic entering or leaving the environment: a user connecting from home, a partner calling an API, data being exported to a SaaS platform. East-west traffic is everything moving internally once it is already inside: one server talking to another, one microservice calling another, an administrator jumping from one internal system to the next.
Most traditional security investment went into north-south traffic. Firewalls at the edge, VPN concentrators, perimeter monitoring. That makes sense on the surface, since that is where the "outside" meets the "inside." The problem is that once an attacker, a compromised account, or a misbehaving workload gets past that edge, east-west traffic in a lot of environments is wide open. Flat internal networks let one compromised system reach dozens of others with no additional friction at all.
For our protect surface, north-south traffic includes the user sign-ins, the report exports to SaaS analytics, and the vendor's inbound connection. East-west traffic includes the application server talking to the legacy database, the service account moving data internally before it ever leaves for SaaS, and any administrator jumping between internal management tools. Both directions need the same discipline: define the expected path, verify that traffic matches it, and treat anything else as worth a second look. An east-west connection that has never happened before between two internal systems deserves just as much scrutiny as an unfamiliar external sign-in, arguably more, since that is exactly how a single compromised credential turns into a full environment compromise.
SaaS and Partner Connections Are Part of the Same Picture
It is tempting to think of "network" as only the stuff physically inside your data center or cloud tenant. That thinking leaves out a growing share of the actual protect surface. Our reporting workflow exports to a SaaS analytics platform. Files move to cloud storage. A vendor connects for support. Each of those is a network path with its own trust decision, and each one deserves the same rigor as internal traffic.
For SaaS connections, the questions are: is data leaving through an approved, monitored path, using an authenticated and scoped connection, to a destination that matches policy, with visibility into what left and when? For partner and vendor connections, the questions are similar but usually stricter: is the partner using a named, time bound connection method rather than a shared or standing one, is their reach limited to exactly the systems their relationship requires, and can we prove that limitation held during the actual session, not just that it was configured that way on paper?
This is also where a lot of "we already do Zero Trust" claims quietly fall apart. Organizations will lock down internal network segmentation carefully and then leave a SaaS integration or partner connection with far broader access than anyone intended, because it was set up years ago under a different set of assumptions and nobody has revisited it since. Network trust has to extend to every path data or access can travel, not just the ones inside the building.
SDN as a Core Discipline, Not a Side Project
Software defined networking deserves its own conversation here, because it is not just a nice modernization project sitting next to Zero Trust. It is one of the core disciplines that makes functional Zero Trust achievable at scale. Traditional network architecture, built around static VLANs, hardware appliances, and manually configured firewall rules, simply cannot keep up with the pace of change that Zero Trust requires. Policies need to follow the workload, the identity, and the transaction, not a fixed IP range that was accurate three reorganizations ago.
SDN lets network policy become programmable, consistent, and tied to the same identity and device signals we have already been building through this series. Microsegmentation, a direct product of SDN thinking, lets us shrink the blast radius of any single compromised system down to exactly what it needs, rather than an entire flat subnet. Instead of a vendor landing on "the internal network" broadly, SDN lets that vendor's connection be scoped to precisely the systems their support relationship covers, enforced consistently, and adjusted the moment that relationship changes.
The practical shift is this: network segmentation stops being a quarterly firewall rule review and starts being a continuously enforced, policy driven capability that adapts as fast as the rest of the architecture does. If Identity and Device can make a decision in real time, but Network still depends on someone manually updating a firewall rule next Tuesday, Network becomes the bottleneck that quietly reintroduces implicit trust everywhere else.
Where Most Organizations Start: Retiring VPN
Here is where a lot of Network pillar work actually begins in practice, and it is worth naming directly. VPN, for internal users, external users, and partners alike, is one of the clearest and most common places organizations choose to make their first real Network pillar progress. There is a good reason for that. VPN was built entirely around the old assumption we just spent this whole post questioning: get inside the tunnel, and you are treated as trusted on the internal network. That is precisely the assumption Zero Trust asks us to remove.
For internal human users, the reality on the ground usually falls into one of two patterns, and neither one holds up well. The first pattern is broad VPN access: users connect, land on a wide internal network segment, and from there reach far more than their role actually requires, all because the tunnel itself was treated as the control. The second pattern is arguably worse, and more common than most organizations want to admit. There is no VPN gate at all for internal traffic. Simple network presence, being connected to the internal network, however that connection happened, is treated as the trust signal by itself. Log in to the network, and broad access follows by default, with no additional limiting control beyond that initial network login. No application specific evaluation, no continuous check, nothing that asks whether this specific user, on this specific device, should reach this specific resource right now. That is not weak segmentation. That is functionally no segmentation, dressed up as a network.
Replacing either pattern means the same thing in practice: identity aware, application specific access that evaluates the request on its own merits, continuously, rather than granting broad reach because a user cleared a single gate, whether that gate was a VPN concentrator or simply the office network jack. A user should reach the exact application or resource their role requires, based on identity, device posture, and policy, regardless of whether they are on a VPN, on the corporate network, or working from a coffee shop with questionable WiFi. For external human users working remotely, the same principle applies without modification. Remote should not mean "on the network," and being physically present inside the building should not mean anything more either. For partners and vendors, VPN retirement usually matters even more, since partner VPN access has historically been some of the broadest, least reviewed, and longest lived access in the entire environment. A named, scoped, time bound connection replaces a standing tunnel that quietly grants far more reach than the relationship actually requires.
This retirement rarely happens all at once, and it should not. A sensible first pass might replace partner VPN access with scoped, application specific connections, since that population usually carries the most risk for the least oversight. The next pass might move a subset of remote workforce access to an identity aware proxy or equivalent capability for the highest risk applications. The next might tackle the harder internal case, replacing "you're on the network, so you're trusted" with actual per application evaluation for on-site users, which is often the most politically difficult segment because it has never been questioned before. Each pass reduces the number of connections that grant broad network reach simply because "that's how access has always worked."
AAVI Through the Network Pillar
Assess: Map What Is Actually Talking to What
Assess for Network means understanding the current traffic patterns, both north-south and east-west, along with every SaaS and partner connection touching the protect surface. What talks to what today? Which of those paths are documented, and which ones exist because someone configured them once and nobody has questioned it since? Where is VPN still the access method, for which populations, and how broad is that access once granted? And just as important, where is there no VPN or gate at all, with network presence alone doing the work of a trust decision?
For our protect surface, assessment likely reveals a familiar mix: a reasonably well segmented perimeter, a flatter internal network than anyone would like to admit, a VPN population that includes remote employees, a vendor, and maybe a forgotten legacy integration, on-site users who reach far more than their role requires simply by being connected, and a SaaS export path that nobody has reviewed since it was first built.
Adapt: Narrow the Paths to Match the Transaction
Adapt is where we use SDN, microsegmentation, and identity aware access methods to make each path as narrow as the transaction actually requires. Internal traffic between the application and the database gets constrained to exactly that path. The vendor's access gets scoped to the specific systems their support role covers, and time bound to the actual support window. SaaS export traffic gets tied to an approved, monitored destination rather than open outbound access from the application environment. Wherever VPN is still in use, or wherever network presence alone is currently granting access, Adapt is where we start replacing that with narrower, policy driven alternatives, population by population.
Verify: Prove the Path Matched the Policy
Verify asks whether the traffic that actually happened matched what we said should happen. Did the vendor's session stay within its scoped path for the entire connection? Did the SaaS export traffic go only to the approved destination? Did east-west traffic between internal systems match the expected pattern, or did something reach somewhere it had never reached before? Did an on-site user's access actually get evaluated per application, or did being on the network quietly grant everything again?
If we cannot prove the traffic stayed on the expected path, we CANNOT count network segmentation as part of the architecture yet.
That statement matters as much here as it did for Identity and Device. A microsegmentation policy that exists on paper but cannot be shown to have actually constrained a real session is not evidence of anything.
Iterate: Keep Narrowing the Blast Radius
Iteration for Network usually looks like a steady narrowing process. The first pass might scope the vendor connection. The next might retire VPN for one population and replace it with identity aware access. The next might tackle the internal, network-presence-as-trust pattern directly. The next might segment a previously flat internal network zone or tighten SaaS export paths to a single approved destination with full logging. Each pass shrinks how far a single compromised identity, device, or workload could actually reach, which is the entire point of the pillar.
Cross Functions Keep Network Honest
Visibility and Analytics need to show the actual path traffic took, not just that a connection was allowed. That includes east-west movement between internal systems, north-south connections to SaaS and partners, and any deviation from the expected pattern for a given transaction.
Automation and Orchestration make network policy enforceable at the speed the rest of the architecture requires. SDN and microsegmentation policies should update automatically as workloads, identities, and business relationships change, rather than waiting on a manual firewall change request.
Governance keeps network exceptions from becoming permanent. A temporarily broadened path for a migration project needs an expiration date. A partner connection needs a review cadence tied to the actual business relationship, not to whenever someone happens to remember it exists.
Before the Next Cup
Here is your homework before the next cup of coffee: pick one transaction from your protect surface and trace its full path, including every hop, every SaaS or partner connection, and any VPN access involved. Ask whether that path is documented, scoped, and monitored, or whether it is simply "however it has always worked," and ask honestly whether any part of it is being granted purely because someone is connected to the network.
Call to action: This week, do four small things. First, identify one east-west connection between two internal systems that has never been reviewed, and ask whether it needs the access it currently has. Second, look at one SaaS or partner connection and confirm whether its reach matches the actual business relationship. Third, if VPN is still in use for any population, internal, external, or partner, pick the highest risk group and start scoping a plan to replace that access with something narrower. If there is no VPN gate at all and network presence is doing the trusting instead, treat that as an even higher priority. Fourth, ask whether your visibility can actually reconstruct the path a given transaction took, not just whether it was allowed.
Remember, this series is the lighter, consolidated version of the process I walk through in full in ZT Foundations: Building Zero Trust with the Tools You Already Have. The book is available now through cletustaylor.com while I work through relaunching it across additional distribution channels, so if you would rather order it directly, that is the place to do it right now. There is also a companion volume, ZT Foundations: Protect Surface Walkthroughs, which walks through example protect surface evaluations and realistic outcomes for readers who learn best by seeing the process applied to real scenarios. Both books are meant to go deeper than this blog series can, and if your team is trying to make Zero Trust practical instead of theoretical, I would be grateful if you picked up a copy, shared it with your team, or pointed someone toward the series.
On a personal note, I am still looking for ARC reviewers for my Finding Truths book, A Student of Truth. If you would like to sign up to be a reviewer, you can do that at cletustaylor.com.
Next time, we bring the Application pillar into these same transaction flows and ask the next question: even when identity, device, and network all check out, does the application itself behave the way we expect it to for this specific action? As always, I would love to hear your thoughts, questions, pushback, and real world examples. Where has network location been doing more of the trusting in your environment than it probably should? Have you already started retiring VPN, and if so, where did you start? Send your comments and ideas to hello@cletustaylor.com, or leave a comment wherever you are reading this. I'll have the coffee ready, and I promise not to make you draw the entire network diagram from memory before the first sip.
Comments