Welcome to our 3rd edition of the networking, security and eBPF predictions! I love starting the year by dusting off my crystal ball and predicting what will happen in the areas of technology that fascinate me: network, security, eBPF and Kubernetes and how they intersect with cloud computing and artificial intelligence. This blog - like the previous 2024 and 2025 editions - is not an official Isovalent stance: while the work of my Isovalent colleagues influence my eight predictions below, the blame is mine if none of them turn out to be correct. Open source usage goes under scrutiny Most organisations today rely heavily on open source. In many cases, they rely on open source software - nine trillion dollars worth of software if it was recreated from scratch - for the most critical parts of their infrastructure. What has been interesting to watch over the last few months is not a loss of trust in open source itself, but a growing discomfort with how casually it is consumed. The reaction to the discontinuation of Ingress NGINX (announced at KubeCon in November) is a good example. The maintainers had been open about the challenges they were facing: they had asked for help, and received very little in return. Regardless, it still seems to catch many platform engineers by surprise, with many upset by the decision. That reaction was understandable given how widely it is used. According to our State of Kubernetes Networking report, roughly half of respondents rely on it in production. This points to two broader issues: first, many organisations rely heavily on open source, but far fewer think seriously about contributing back. That is not a new problem, and it is not something I expect to be fixed any time soon. Second, and this is where I think 2026 will mark a shift, the cumulative impact of high profile projects like Ingress NGINX being retired, or open source utilities like XZ suffering serious vulnerabilities, will force organisations to rethink how they commit to open source projects. You should think of open source projects less as tools you casually pick up and more like neighbourhoods you move into. When you start using a project in production, you are making a long term commitment, and changing course later is rarely trivial. Just as deciding where to live is something people often think about for months, adopting open source technologies at scale deserves the same level of deliberation. Ingress NGINX did not struggle because it lacked users. On the contrary, it struggled because its importance outgrew the level of shared upkeep around it. Don’t think I am an open source skeptic: it’s quite the opposite. Only weeks ago, I was writing about how networking’s open source era is just getting started. What I do expect to change is how organisations select and engage with open source projects once they become production critical. This is where Open Source Program Offices have an opportunity to matter again. Even if some OSPOs have been scaled back, the need they address has not gone away. In 2026, I expect more organisations to treat open source selection as a strategic decision and to assess whether an open source project is sustainable, secure, and worth investing in. The rise of the Kubernetworker The finding from the State of Kubernetes Networking report that people keep coming back to is the fact that platform engineers remain firmly in charge of networking inside Kubernetes. On the surface, that is not necessarily a problem, nor should it be a surprise. Platform teams are closest to the developers, they maintain clusters, and they are usually the ones on call when things break. But it does come with an assumption everyone responsible for Kubernetes networking is comfortable with networking itself. Complex networking technologies like IPv6, BGP and network overlays are directly applicable to Kubernetes networking. Not every platform engineer has spent years working with them in production environments. At the same time, many traditional network engineers have stayed at arm’s length from Kubernetes. Sometimes intentionally, assuming it was someone else’s problem. Sometimes unintentionally. I was reminded of this during a conversation at KubeCon Atlanta with a platform engineer who told me they would rather not involve the network engineering team because, in their words, they were “old school”. That perception might seem rash or unfair, but it is not entirely invented. Some network engineers have been reluctant to change, and the industry has earned that reputation in places. But, amongst the networking community, the enthusiasm in Cilium and Kubernetes networking has never been higher. I see that enthusiasm reflected in the number of network engineers taking our Kubernetes networking labs. I also see it in the audiences lining up for Kubernetes networking sessions at events like Cisco Live, including my own sessions. The announcement of the upcoming Certified Kubernetes Networking Engineer certification will only encourage many, amongst the millions of Cisco-certified engineers, to take the plunge. This was also one of the motivations behind writing Cilium: Up & Running. James, Filip, and I wanted to create something that would help bridge the gap between traditional networking and Kubernetes networking. The goal was not to turn network engineers into platform engineers, or the other way around, but to give both groups a shared foundation. Something practical that helps people get started, or go deeper, without assuming they already know how Kubernetes networking works under the hood. To me, this is what the rise of the Kubernetworker is about. I do not expect it to become a new job title (it does not exactly roll off the tongue) but I do see it as a shift in mindset. Networking expertise is still needed. Kubernetes is where that expertise increasingly needs to be applied. VMs on Kubernetes lose their innocence One thing that is hard to ignore is the growing interest in running virtual machines on Kubernetes. Projects like KubeVirt have clearly gained traction. You could see it in the hundreds of people who showed up for VMs on Kubernetes Day at KubeCon in Atlanta. That interest is not happening by accident. It is largely being driven by licensing changes and cost pressure following the Broadcom acquisition of VMware. For many organisations, this has been the moment where running VMs on Kubernetes moved from a theoretical option to something they felt compelled to seriously evaluate. What people are starting to discover though is that this comes with caveats. Kubernetes is a highly extensible system, but it was not designed to run virtual machines. Making it do so requires workarounds. As adoption grows, those compromises become more visible, especially around networking, performance, and security. This is where comparisons with VMware often fall short. VMware has been around for more than twenty five years. Whatever your view on the acquisition itself, recreating the VMware experience inside Kubernetes is not something that happens overnight. It took years to build the operational maturity and network virtualisation capabilities that many teams now take for granted. It is also worth saying that these limitations are not being ignored. We recently introduced the Isovalent Network for Virtualization solution to address connectivity challenges between a traditional virtual machine platform and Kubernete clusters. Daniel Borkmann, co creator of eBPF and Cilium, has been working on how eBPF can help address VM on container networking performance problems. There's real potential here, but also it shows how deep and complex the problem space actually is. None of this means that running VMs on Kubernetes is a bad idea. It does mean that the early innocence is fading. In 2026, I expect adoption of VMs on Kubernetes to keep accelerating, but to be accompanied by a more honest set of frustrations around performance, networking, and operational maturity. Multicloud starts to look real For a long time, multicloud felt like something we talked about more than something we actually did. There have always been drivers behind multicloud. Availability, explicit exit plans, and regulation all play a role. Regulations like DORA make exit planning a requirement, forcing organisations to think seriously about how dependent they are on any single provider. For a long time though, it felt like the cloud providers themselves had not quite read the memo. I remember this clearly from my time at VMware. While I was working on the partnership between VMware and Amazon Web Services, AWS showed a real reluctance to use the term "multicloud" to describe the service (“hybrid cloud” was the preferred framing). The unspoken message often felt like, “why would you even consider using another cloud than us?”. Other providers had similar positions. That feels like it is changing. The fact that AWS now has a public “What is Multicloud” page would have been unthinkable not that long ago. The same goes for dedicated multicloud tracks appearing at re:Invent. Perhaps the frosty relationship between cloud providers is starting to thaw and they are now more willing to make multicloud easier. A good example is the new AWS Interconnect capability, which allows organisations to connect an AWS VPC and a Google Cloud VPC directly through an open source API. This is a meaningful shift. It removes a lot of the friction that previously required stitching things together through third party providers and, more importantly, it lowers the barrier to building genuinely resilient architectures across clouds. Multicloud is starting to look like real production architecture rather than just slideware. I had multiple conversations at KubeCon on this topic. Admittedly, it took place only a few weeks after the AWS outage, so there is probably some recency bias. Still, the same questions kept coming up: How do I connect clusters across clouds? How do I design for availability that can actually withstand availability zone or regional outages? Those conversations consistently turned toward how to do this with Cilium Cluster Mesh. That same week in Atlanta, I spoke to two architects from an internal Cisco SRE team who walked me through how they protected themselves against an availability zone failure by running Cluster Mesh across multiple sites. During the US EAST 1 outage, they were knocked off the management plane, but the data plane was fine and services still ran without a glitch. Multicloud will probably never be easy. But the conversation is moving toward concrete patterns driven by resilience, regulation, and a desire to reduce dependence on any single provider. And increasingly, cloud providers themselves are collaborating in ways that support that goal. Nano Segmentation Takes Off In my network segmentation spectrum post, I argued that security controls increasingly form a continuum rather than discrete layers. What we are seeing now is runtime security spreading further and further through the system, reaching places traditional controls never really touched. Nano-segmentation pushes security enforcement as far down as individual processes, system calls, and execution paths. Being able to block specific binaries and applications can dramatically reduce exposure when a vulnerability is discovered, especially when patching is slow or impractical. Cisco adopting Tetragon to remediate vulnerabilities on its own devices (what is known as Cisco Live Protect) is not a marketing exercise (well, not just a marketing exercise), and I will come back to that in the next section. It’s because eBPF lets you hook into the system in ways that were not possible before. But with that much power comes a lot of responsibilities. The Blue Friday outage we saw in 2024 was a sharp reminder of the risks involved. Blue screens across airports and critical infrastructure were not caused by an attack, but by a failure in how protection was delivered. It showed how security tooling can quickly become the problem it was meant to prevent. This is where eBPF based runtime security starts to make sense, a view echoed by engineers like Brendan Gregg when reflecting on how to avoid large scale, self inflicted outages. eBPF is not invulnerable, and bugs will be found, as I argued in my 2024 predictions, but security logic enforced at runtime, while constrained by the eBPF verifier, offers a different operational model. eBPF was built with guardrails from day one and the focus on safety continues as adoption of eBPF-based tooling continues to grow exponentially. The eBPF Foundation recently received a grant from the Alpha Omega Foundation to fund critical upstream security work. That work includes hardening the runtime, improving validation tooling, and auditing JIT compilers across multiple architectures. To me, that means that patching servers, fridges, traffic lights, smart meters - anything with a Linux kernel - could become something that can be realistically planned for, rather than something organizations approach with dread. Isovalent’s influence inside Cisco becomes visible The next prediction is more inward looking, but it is worth calling out as it signals where networking and security are headed. It’s clear that 2026 is the year where the influence of Isovalent - and eBPF based networking and security - goes way beyond Kubernetes. I mentioned Live Protect before: while it already runs on Cisco Nexus devices today, there is nothing particularly special about that environment. Many Cisco platforms already run on a Linux kernel. From a technical point of view, there is very little stopping eBPF programs from running on other devices as well, including platforms based on IOS XE and IOS XR. Cisco using Isovalent brings me to one of my favourite industry clichés: which is what people like to call dogfooding. The idea that a company should use your own product to prove it is safe and works as advertised (just like a dog owner might eat its own dogfood - yuk). What Cisco is doing here feels closer to drinking your own champagne: Cisco is running Tetragon to protect Cisco infrastructure at scale. Isovalent’s influence within Cisco isn’t limited to security. The Isovalent Load Balancer - Cisco’s first foray into load balancing since the discontinuation of the ACE module in 2012 - is a strong complement to Nexus. Isovalent’s work around EVPN (which you will hear more about during the upcoming Cisco Live) opens up new integration patterns, where Kubernetes clusters can be treated as first class participants in existing network designs, simplifying integration with EVPN-based Nexus fabrics. Even another recent acquisition - Splunk - is as excited to work with us as we are to work with them. It makes a lot of sense to integrate eBPF - and its ability to capture every event - with a platform built to ingest large volumes of data and extract meaning from it. Jeetu Patel, Cisco’s Chief Product Officer, recently called Isovalent “one of the best Cisco acquisitions”. While, of course, I share Jeetu’s optimism, I also recognise that it will take time for Cisco, its customers, and its partners to fully realise the impact of this shift. Still, the early signs are encouraging. MCP unlocks real use cases, and real risk One area where things are moving very quickly is around MCP and agentic AI. When I wrote my last set of predictions, MCP had only just been released publicly. Fast forward to today, and it already feels close to ubiquitous. It comes up in almost every conversation about AI driven systems. On the networking and security side, the use cases are genuinely compelling. The Azure engineering team built an MCP server with Cilium and Hubble support. I can hook it into a Kubernetes cluster, collect data from Cilium and Hubble, analyse traffic patterns, and generate network policies from what it sees. it’s not a far-fetched idea - I was doing it today and I also know of customers who are actively experimenting with similar approaches in their own environments. Used carefully, this can dramatically accelerate how teams understand their systems. Instead of manually interpreting logs and flows, you let the system surface patterns and propose controls. The two things that engineers hate the most is probably dealing with YAML manifests and writing firewall rules. By letting AI interpret logs and flows and suggest controls, it could make life so much easier for many of you. But this is also where things start to get uncomfortable. The more control you give to an MCP server, the easier it is for it to become autonomous. And it is surprisingly easy to give it a lot of control. Before I knew it, I had relaxed the server’s access from read-only to write. In minutes, the MCP server was taking actions I hadn’t anticipated. I don’t run Kubernetes in prod so there was no consequence to the MCP’s initiative. But it’s very easy to imagine how catastrophic it could have been if it’d started making unintelligent enforcement decisions. I still think 2026 will be the year where AI driven networking and security use cases accelerate significantly. It will go from useful but limited to genuinely transformative. At the same time, I would not be surprised if this acceleration leads to a correction. Organisations will keep pushing autonomy further and they will also discover new ways to fail along the way. In other words, 2026 may bring rapid progress, alongside significant bumps in the road. Identity becomes humanoid, and policy has to follow For a long time, identity was relatively well defined. Users had identities. Machines had identities. And identities were tightly coupled to relatively static policies. With MCP and agentic systems, that model starts to break down. If you let coding agents and MCP servers let loose, they may initiate changes, adapt over time, and operate with a degree of autonomy, often while operating with your credentials. In that sense, identity starts to feel humanoid. Yes, you can argue that we had that already with service accounts and cloud access keys but things are more fluid. How does an end-system know who’s interacting with it? Is it the person behind the keyboard, or is it an agent acting on their behalf? Look - identity has always been one of the hardest problems in distributed systems. That is not new. What is changing is that identity on its own is becoming less and less useful when it gets even harder to define the entity behind it. Take a simple example. A pod running a microservice needs to access a database that happens to run inside a virtual machine. At that point, identity is already crossing abstraction boundaries. It is no longer just a Kubernetes concern. We now need a policy to express that a specific workload identity can access a specific database identity, over a specific protocol, under specific conditions. Now add an MCP agent into the mix. Perhaps that agent is allowed to check configuration and suggest improvements, but not apply them. Or maybe it is allowed to apply changes, but only within a tightly constrained scope, and only during certain windows. In all of these cases, the hard part is not assigning an identity to the agent. The hard part is defining and enforcing policy that reflects intent, scope, and acceptable risk. This is why global identity matters. We need identities that span pods, virtual machines, services, and increasingly, agents. And then we need global policies that make identity actionable. I don’t think identity or policy gets neatly solved in 2026. If anything, both become harder. But the industry will begin to accept that treating them as separate problems no longer works. Identity only has meaning when it is paired with policy, and policy only works if the concept of identity adapts to the systems it is meant to protect. Join us to debate these predictions! If you want to dig into these ideas in more detail, I will be doing exactly that at the end of January on the eBPF and Cilium show. I will be joined by Dan Finneran, and we will review these predictions, challenge a few of them, and probably disagree on at least some points.