For two decades, the unspoken truth in enterprise security has been that Networking and Security are structurally at odds. NetOps builds for speed, uptime, and access. SecOps builds for control, verification, and containment. Zero Trust, in theory, bridges that divide. In practice, it has been used to widen it. This article is about why that has to change, and what it looks like when it does.
PART I: THE HISTORY
Two Teams. One Network. Fifteen Years of Friction.
If you have ever sat in a change advisory board meeting where a security team’s request to add microsegmentation to the production network was quietly voted down by operations, you already understand the problem. The friction is not personal. It is structural, and it has been baked into how we organize, fund, and incentivize these two functions.
Network engineers are measured on availability. Their job is to move packets reliably, fast, and without interruption. Their professional identity is built around uptime, and their nightmare is a routing change that takes down an application at 2 a.m. Security engineers are measured on risk reduction. Their job is to shrink the attack surface, enforce least-privilege, and stop lateral movement. Their nightmare is an undetected threat that has been living inside a flat network for six months.
These are not compatible nightmares. And for a long time, the architecture of enterprise networks reflected exactly that incompatibility. The perimeter model, firewall at the edge, implicit trust inside, was essentially a negotiated settlement. Security got to control what came in from outside. Networking got to keep the inside fast and flat. Both sides could declare victory in their own terms.
The NetOps side of this argument sounds like this: “Every time Security wants to add a rule, it needs a change window. Every change window is a risk to availability. We’ve had segmentation changes break application dependencies that nobody knew existed. We’re not obstructing the program. We’re protecting the business.”
The SecOps side sounds like this: “Networking treats every security control as an operational inconvenience. We present a microsegmentation plan that’s been in development for three months, and they find seventeen reasons to defer it. Meanwhile, the threat surface keeps growing, and we own the risk if something goes wrong.”
Both sides are right. That is what makes this so difficult. And it is exactly why Zero Trust, as it has been sold and deployed over the past decade, has so consistently failed to close the gap.
See also: Implementing Zero Trust for Kubernetes
PART II: THE COMPLICATION
How Zero Trust Became a Weapon in the Wrong War
The vendor marketing around Zero Trust arrived like a gift to the SecOps side of this argument. Here, finally, was an industry-validated framework that said everything networking had built on implicit trust was wrong. Security teams carried analyst reports into steering committees and quoted research predictions. Boards approved Zero Trust roadmaps. And networking teams, who had not been consulted in the design of those roadmaps, received them as a mandate handed down from above.
Forrester Research, the same firm that created the Zero Trust concept, documented the failure mode clearly: “Security teams often don’t know how to start their Zero Trust journey. Faced with a mountain of technical debt and a complex environment, they become paralyzed because they erroneously assume they must transform their entire environment.” But organizations were not reading the framework; they were reading the vendor brochures. And vendors, who had every incentive to position their platforms as the solution rather than an enabler, were more than happy to let security teams believe they could deliver Zero Trust by procurement alone.
The result was predictable: security teams arrived at CAB meetings with Zero Trust implementation plans that required fundamental changes to network architecture, had not been developed in partnership with the networking team, and could not answer basic operational questions about application dependencies, traffic flows, or failover behavior. Networking teams pushed back, correctly, and were characterized as obstructionist. The stalemate deepened.
Gartner research predicts that 30% of organizations will abandon their Zero Trust initiatives entirely by 2028, citing complexity, cultural resistance, and lack of integration. When analysts identify complexity and cultural resistance as the leading causes of Zero Trust program failure, the word ‘cultural’ is doing a lot of work. What it describes, in most organizations, is the accumulated damage of deploying a framework that required two teams to work in deep partnership, without ever actually building that partnership first.
John Kindervag, who created Zero Trust at Forrester in 2010, was explicit about this from the beginning. His original research called for a ‘protect surface’ approach: identify what you are protecting, map the transaction flows around it, and build policy from the network up. That process inherently requires networking and security to be in the room together. The vendor era of Zero Trust removed them both and replaced them with a platform evaluation. At RSAC 2025, Kindervag put it plainly: “Zero Trust is first and foremost a strategy. It’s something that you do, not something you buy. The biggest mistake I saw was to go too big, too fast; everybody is now trying to do it all at once for their entire organization.”
See also: Researchers Find 380,000 Open Kubernetes Servers
PART III: THE SHIFT
The Architecture Is Not at Odds. The Teams Have Been.
Here is what I have come to believe, after watching this play out across organizations at different scales and different levels of maturity: the architecture was never the real problem. Networking and security principles are not inherently in conflict. Availability and verification are not mutually exclusive. The problem has been organizational, two teams with different incentive structures, different vocabularies, and different views of what ‘done’ looks like, trying to solve a problem that can only be solved together.
The engineering reality of modern Zero Trust confirms this. The most technically advanced implementations being developed in 2025 and 2026 are being designed explicitly to reduce operational burden on network engineers, not to impose new burdens on them. Agentless microsegmentation, automated policy discovery, and unified traffic visibility are emerging precisely because the industry has finally acknowledged what practitioners have known for years: you cannot bolt security controls onto a network without the people who run that network being central to the design.
What the joint team is actually delivering, in current terms, is a six-part control surface: identity-centric least-privilege access, continuous trust evaluation rather than one-time authentication, inline inspection of the traffic the policy permits, data-centric controls (DLP and CASB) that travel with the data, behavior analytics that turn telemetry into detection, and runtime enforcement that can revoke or constrain access mid-session. The first five are mature capabilities. The frontier is runtime enforcement: real-time decision and action control across both planes. That is also the place where the partnership between networking and security has to be tightest, because enforcement at runtime requires real-time signal exchange that neither team can deliver alone.
Forrester’s own evaluation of the Zero Trust platform market makes the point that every CTO should read carefully and relay to both their teams: no single platform delivers Zero Trust. Not one. The industry spent ten years implying otherwise, conferences, keynotes, and successive product generations all built on the premise that the right tool would solve this. It won’t. It never could. Zero Trust is delivered by the people who build and own your network, working together with the people who secure it. The vendor era didn’t just obscure that truth. It profited from burying it.
The organizations beginning to achieve measurable Zero Trust maturity share a common characteristic: their networking and security functions share a program charter, a joint set of objectives, and, critically, shared accountability when things go wrong. The program is not a security project that networking has to accommodate. It is an infrastructure project that both teams own.
See also: AI That Plays by Your Rules: Why Enterprise MCP Integration Changes Everything
PART IV: THE PRACTICE
What It Looks Like When the Teams Are Actually United
Describing the need for collaboration is easy. The harder question is what it looks like structurally, what the working model is, how decisions get made, and what changes when these two functions operate as a single team rather than adjacent functions with competing priorities. Based on what I have seen work, there are five characteristics that distinguish organizations where this is real from organizations where it is aspirational.
The first is that the protect surface is defined together. Kindervag’s original framework was not a security document. It was an architecture document. The ‘protect surface’ the specific data, application, asset, or service being secured can only be correctly identified through a conversation between the people who understand what the network carries and the people who understand what the threat actors want. In the organizations doing this well, the protect surface definition is a joint workshop output, not a CISO memo.
The second is that traffic mapping is a shared discipline. Before a single policy is written, both teams need to understand the transaction flows around each protect surface. This is not a security task. It is a network architecture task that has security implications. Networking engineers know where the dependencies are. Security engineers know which of those dependencies represent implicit trust that should be made explicit. Neither can do this work without the other. The word ‘together’ is the operative one, and it is absent from most Zero Trust programs that fail.
The third is that change management is redesigned, not worked around. One of the most common failure modes I see is security teams trying to find ways to route around the change management process rather than redesigning it. Change management exists for good reasons: it protects availability, it enforces testing, and it creates accountability. What needs to change is not the existence of change control but its design: specifically, the classification criteria that determine which changes need a full CAB review versus which can be pre-approved within defined parameters. Building a Zero Trust change classification framework that network and security engineers design together is not a concession by security. It is a prerequisite for velocity.
The fourth is that observability is jointly owned. Industry research consistently identifies IT environment complexity and limited visibility as the top information security challenges organizations face. The visibility problem is not a security problem. It is a network architecture problem with security consequences. East-west traffic, the lateral flows between systems inside the network, is routinely invisible to security tooling because it was never instrumented by the network team. Closing that gap requires the network team to extend the telemetry infrastructure that they own and operate, motivated by a security outcome they now share accountability for.
The fifth is that incentives are realigned at the leadership level. None of the above happens if the CISO is accountable for Zero Trust maturity and the CTO is accountable for uptime, and those two metrics are never reconciled. The joint leadership must design the governance structure so that a networking team contributing to Zero Trust implementation is visibly rewarded for that contribution, not penalized by the operational overhead it creates. That means shared program metrics, joint reporting to the executive leadership, and a clear articulation to both teams that their professional success is now partially contingent on each other’s.
As Forrester’s 2025 research put it: “The solution isn’t more controls; it’s systematic understanding of what you actually have, where the trust relationships live, and who owns the responsibility for changing them.”
See also: Shadow MCP: Find the Ghosts Hiding in Your Codebase
PART V: THE EXECUTIVE RESPONSIBILITY
What the CTO Has to Own That Nobody Else Will
I want to be direct about something. The structural tension between networking and security is not a problem that either team created. It is a problem that leadership created by designing organizations with separate reporting lines, separate budgets, separate risk frameworks, and separate definitions of success, and then handing them a security framework that requires them to act as one. The failure to resolve that tension is not an engineering failure. It is a governance failure, and it sits squarely at the executive level.
The specific things that CTOs and CISOs need to own in this context are not glamorous. They are not about platform selection or vendor strategy. They are about organizational design: ensuring that the people who build the network and the people who secure it share a program charter before any technology decision is made; ensuring that technical debt is visible across both functions before any architecture change is proposed; and ensuring that the change management process is a collaborative design between the two teams rather than a battleground.
Gartner’s finding that fewer than 1% of large enterprises currently have a mature, measurable Zero Trust program is not evidence that Zero Trust is an impossible standard. Some of that gap is the technical bar moving. Continuous trust evaluation and runtime enforcement were not being measured five years ago. Most of it is evidence that the dominant implementation model (security-led, vendor-driven, delivered without genuine network partnership) does not work. The organizations beginning to change are not the ones with the biggest budgets or the most sophisticated platforms. They are the organizations where the CISO and the network leadership are in the same room, with shared accountability, before anyone opens a vendor presentation.
The mandate is straightforward: stop approving Zero Trust roadmaps that were built by security teams and handed to networking teams. Start requiring joint program ownership as a precondition of budget approval. The architecture will follow. The culture has to come first.
CONCLUSION
From Architecture at Odds to a Team United
The original insight behind Zero Trust was architectural: stop trusting the network, because the network will be compromised. That insight is as correct today as it was in 2010. What the past decade has demonstrated is that you cannot implement it by handing a security framework to one team and a set of operational constraints to another and expecting them to converge.
Zero Trust, done properly, is a forcing function for something the industry has needed for a long time: a genuine operating model where network engineering and security engineering are not adjacent disciplines with competing priorities, but a single function with a shared objective. The technology has caught up on most of what Zero Trust requires. Identity-centric access, continuous trust evaluation, inline inspection, data protection, and behavior analytics are mature, deployable capabilities. The frontier is runtime enforcement: real-time decision and action control during active sessions. That is where the next two years of Zero Trust maturity will be measured. But the technology is not the constraint.
The constraint is the governance model, the incentive structure, and the willingness of executive-level leadership to be honest about the organizational change that Zero Trust actually requires. It is not an architecture at odds. It never was. It is a team — not yet united, but capable of being so, with the right conditions in place.
Building those conditions is the work. And it starts not with a vendor evaluation, but with putting the right two teams in a room together and asking them to solve the same problem.
Sources and Research
- Forrester Wave: Zero Trust Platforms, Q3 2025 — https://www.forrester.com/blogs/announcing-the-forrester-wave-zero-trust-platforms-q3-2025-choosing-a-platform-solution-for-your-zero-trust-journey/
- Forrester Security Survey, 2025 — https://www.forrester.com/blogs/your-zero-trust-strategy-needs-an-adversarial-perspective/
- Gartner 2024 State of Zero Trust Adoption Survey — https://www.gartner.com/en/newsroom/press-releases/2024-04-22-gartner-survey-reveals-63-percent-of-organizations-worldwide-have-implemented-a-zero-trust-strategy
- Gartner Predicts 2025: Scaling Zero-Trust Technology and Resilience — https://www.gartner.com/en/documents/6283983
- Gartner: 10% of Large Enterprises Will Have a Mature and Measurable Zero-Trust Program by 2026 — https://www.gartner.com/en/newsroom/press-releases/2023-01-23-gartner-predicts-10-percent-of-large-enterprises-will-have-a-mature-and-measurable-zero-trust-program-in-place-by-2026
- John Kindervag, RSAC 2025 — https://www.illumio.com/blog/zero-trust-in-practice-with-creator-john-kindervag-and-ciso-jared-nussbaum
- ISC²: 15 Years of Zero Trust, October 2025 — https://www.isc2.org/Insights/2025/10/15-Years-of-Zero-Trust
- Zentera: Zero Trust Architecture — Cutting Through Complexity, December 2025 — https://www.zentera.net/blog/zero-trust-architecture-cutting-through-complexity
- CISA Zero Trust Maturity Model Guidance, 2025 — https://www.cisa.gov/zero-trust-maturity-model
