DEV Community: FirstPassLab

Inside NVIDIA’s $2B Marvell Deal: What NVLink Fusion Means for AI Ethernet Fabrics

FirstPassLab — Thu, 16 Apr 2026 22:54:39 +0000

If you work on AI infrastructure, the interesting part of NVIDIA's $2B Marvell deal is not the check size. It's that NVIDIA is trying to keep custom XPUs, optics, DPUs, and Ethernet fabrics inside one system model. That changes how network teams should think about scale-up versus scale-out design, RoCE behavior, and optical planning.

Why this matters: The company that defines the interconnect and operating assumptions of the cluster can stay in control even when customers start mixing in custom silicon.

This is not just a chip deal. It is a fabric-control deal, and it tells data center architects that optical interconnects, lossless Ethernet, and rack-scale integration are now the real battleground in AI infrastructure.

What exactly did NVIDIA and Marvell announce?

NVIDIA and Marvell announced a strategic partnership on March 31, 2026 that combines a $2 billion NVIDIA investment with a broader technical agreement around NVLink Fusion, custom XPUs, scale-up networking, and silicon photonics. According to NVIDIA (2026), Marvell will contribute custom XPUs and NVLink Fusion-compatible scale-up networking, while NVIDIA will provide Vera CPUs, ConnectX NICs, BlueField DPUs, NVLink interconnect, Spectrum-X switches, and rack-scale AI compute. According to Data Center Dynamics (2026), the two companies also plan to work on advanced optical interconnects and silicon photonics, plus AI-RAN use cases for 5G and 6G. The important point for network engineers is that the announcement spans the full AI factory stack, from compute attachment to optics, rather than a narrow financial investment.

Layer	Marvell contributes	NVIDIA contributes	Why it matters
Custom compute	Custom XPUs	Rack-scale AI ecosystem	Lets customers build semi-custom systems without abandoning NVIDIA infrastructure
Network attachment	Scale-up networking compatible with NVLink Fusion	ConnectX NICs, BlueField DPUs	Keeps traffic engineering and service insertion inside one architecture
Fabric	High-speed connectivity expertise	Spectrum-X switches, NVLink interconnect	Aligns scale-out Ethernet and scale-up GPU domains
Optics	Optical DSP and silicon photonics	AI factory platform demand	Pushes optical design into the center of AI network planning

The strategic language matters too. Jensen Huang said, according to NVIDIA (2026), that “the inference inflection has arrived” and token demand is surging. Matt Murphy said, according to NVIDIA (2026), that high-speed connectivity, optical interconnect, and accelerated infrastructure are now central to scaling AI. Those are networking statements as much as semiconductor statements.

Why does NVLink Fusion matter more than the $2 billion headline?

NVLink Fusion matters more than the dollar figure because it gives NVIDIA a way to stay essential even when hyperscalers and large enterprises want custom silicon instead of buying every accelerator directly from NVIDIA. According to Reuters (2026), the deal helps NVIDIA remain central while some customers increasingly choose custom processors. According to NVIDIA (2026), NVLink Fusion is a rack-scale platform for semi-custom AI infrastructure, so Marvell can bring its own XPUs and networking into a design that still depends on NVIDIA CPUs, NICs, DPUs, switches, interconnects, and supply chain scale. That is the real control point. The company that owns the fabric, interconnect, and integration standards can keep monetizing the cluster even when the accelerator mix changes.

This is why the deal is so important for AI networking. A hyperscaler can change the compute element more easily than it can rewrite a whole rack-scale fabric model. If NVIDIA can make custom chips coexist with ConnectX, BlueField, Spectrum-X, and NVLink Fusion, it keeps control over congestion behavior, telemetry, service insertion, and cluster design assumptions. That is much harder for rivals to displace than a single GPU SKU.

How will this change AI data center fabric design?

AI data center fabric design will shift further toward tightly coupled scale-up and scale-out domains, where compute, optics, DPUs, and Ethernet behavior are engineered as one system rather than separate procurement lines. According to Data Center Dynamics (2026), Marvell’s role includes NVLink Fusion-compatible scale-up networking, while NVIDIA contributes ConnectX NICs, BlueField DPUs, and Spectrum-X switches. That means architects should expect more fabrics where custom XPUs still depend on familiar Ethernet-adjacent building blocks, especially for east-west AI traffic, rack-scale cluster composition, and storage access. For data center network engineers, the lesson is straightforward: future AI fabrics will be judged by how well they handle congestion, latency spread, and optical scaling, not only by how many 800G or 1.6T ports they advertise.

A practical way to think about it is to split the fabric into two jobs:

Design domain	What it does	What architects must watch
Scale-up	Connects accelerators and high-speed local domains inside the rack or pod	Latency determinism, oversubscription, optical reach, memory and accelerator locality
Scale-out	Connects racks, pods, storage, and service planes over Ethernet	RoCEv2 behavior, ECN marking, PFC blast radius, telemetry, DPU policy insertion

This is where protocol behavior starts to matter more than marketing. RoCEv2 traffic still rewards low loss and controlled congestion. BlueField DPUs still matter for offload and infrastructure services. ConnectX remains important at the host edge. Engineers who already follow our NVIDIA Spectrum-X Ethernet AI fabric deep dive and our NVIDIA networking division analysis will recognize the pattern: Ethernet is becoming the operating fabric of AI, but it only works when the fabric is tuned like a system, not purchased like a switch refresh.

Why are optical interconnects and silicon photonics now strategic, not optional?

Optical interconnects and silicon photonics are strategic because AI clusters are now colliding with physical limits in power, distance, heat, and signal integrity, and the easiest way to unlock the next scaling step is often in the optical layer. According to NVIDIA (2026), the Marvell partnership explicitly includes collaboration on silicon photonics. According to Data Center Dynamics (2026), the companies will work on advanced optical interconnect solutions for AI infrastructure and AI-RAN use cases. Marvell is not just a chip vendor in this story, it is a specialist in high-performance analog, optical DSP, and photonics that can reduce the friction between dense compute blocks and the links that join them. In other words, this deal is about moving more cleanly from fast chips to usable systems.

That matters for data center teams because the networking bottleneck in AI is increasingly optical, thermal, and topological. If you followed our coverage of STMicro’s PIC100 silicon photonics push and Microsoft’s MOSAIC optical work, you have already seen the pattern. The industry is spending enormous effort on reducing interconnect power per bit and improving reach without wrecking latency. According to Reuters (2026), bandwidth and power efficiency are key bottlenecks in scaling AI data center systems, which is exactly why a photonics-heavy partner like Marvell is valuable to NVIDIA.

What does this mean for data center architects?

For data center architects, this deal is a warning that AI infrastructure competency now starts at the fabric and optical layers, not just at server onboarding or EVPN control-plane design. According to Reuters (2026), Big Tech firms including Alphabet and Meta are expected to spend at least $630 billion on AI infrastructure this year. When that much capital hits the market, customers stop asking only for “data center networking” and start asking for deterministic AI fabric behavior, DPU-ready designs, optical roadmaps, and clean migration paths between classical IP fabrics and GPU-heavy east-west clusters. According to Marvell (2026), the company delivered $8.195 billion in fiscal 2026 revenue, up 42% year over year, which tells you demand for these components is already translating into production spending, not lab curiosity.

For network teams, the practical implications are concrete:

Study lossless Ethernet behavior. AI fabrics depend on RoCEv2, ECN, buffer behavior, and carefully bounded PFC domains.
Treat optics as a design input, not a transceiver afterthought. Reach, insertion loss, thermals, and power are now first-order constraints.
Expect more heterogeneous racks. Custom XPUs, DPUs, smart NICs, and accelerator-specific traffic patterns will coexist.
Use telemetry aggressively. Hotspot detection, queue visibility, and microburst analysis matter more in AI fabrics than in traditional enterprise server pods.

If you want adjacent context, the related pieces on Equinix Distributed AI Hubs and NVIDIA GTC networking are worth reading alongside this one.

Does this deal change the competitive balance with Broadcom, custom ASICs, and hyperscalers?

Yes, because the deal gives NVIDIA a better answer to the two biggest threats to its dominance, custom silicon and independent fabric strategies. According to Reuters (2026), customers are increasingly considering custom processors instead of buying only NVIDIA’s high-priced parts. According to Tom’s Hardware (2026), Marvell is one of the leading custom ASIC design houses, with deep relationships across hyperscalers that want alternatives to standard GPU buying patterns. By investing in Marvell rather than treating custom silicon as a pure threat, NVIDIA gains a way to keep those designs attached to its networking and interconnect ecosystem. That changes the balance of power from “who builds the chip” to “who defines the system boundary.”

Broadcom is still formidable in custom silicon and switching, and hyperscalers will keep pursuing in-house accelerators. But NVIDIA’s move is clever because it turns coexistence into a product strategy. If the custom XPU still plugs into NVIDIA-friendly rack-scale assumptions, NVIDIA keeps influence over architecture, tooling, and supply chain decisions. That is why this story fits alongside our earlier reporting on Meta’s Spectrum-X buildout and the broader question of whether AI infrastructure will standardize around Ethernet-heavy, multi-vendor fabrics or fragment into isolated proprietary islands.

What should network engineers watch next?

Network engineers should watch three follow-on signals: whether more custom silicon vendors join NVLink Fusion, whether optical roadmaps accelerate from 800G to denser rack-scale topologies, and whether AI-RAN work pulls telecom and data center design closer together. According to NVIDIA (2026), the Marvell partnership also covers AI-RAN for 5G and 6G, which means this is not only a cloud data center story. According to Reuters (2026), Marvell expects revenue to approach $15 billion by fiscal 2028, nearly 40% growth, which suggests the market believes this infrastructure shift still has room to run. The engineers who benefit most will be the ones who can connect Ethernet behavior, optics, DPU services, and accelerator locality into one operational model.

In practical terms, that means reading semiconductor announcements like network architecture documents. When a partnership names ConnectX, BlueField, Spectrum-X, silicon photonics, and custom XPUs in the same paragraph, it is telling you where the next infrastructure bottlenecks and engineering priorities are forming. VXLAN EVPN design, queue engineering, optical planning, and deep telemetry are becoming more valuable, not less. AI did not make networks simpler. It made them central again.

Frequently Asked Questions

Why did NVIDIA invest $2 billion in Marvell?

Because NVIDIA wants customers building custom AI systems to keep using NVIDIA’s surrounding infrastructure stack. According to NVIDIA (2026), the deal ties Marvell’s custom XPUs and networking to NVLink Fusion, ConnectX, BlueField, Spectrum-X, and Vera, which preserves NVIDIA’s influence even in heterogeneous systems.

What is NVLink Fusion in practical terms?

NVLink Fusion is NVIDIA’s rack-scale framework for semi-custom AI infrastructure. It allows customers to combine non-NVIDIA compute elements with NVIDIA interconnect, NIC, DPU, switch, and system integration components instead of choosing an entirely separate architecture.

Why does this matter for data center networking teams?

Because AI clusters increasingly hit network and optical limits before they hit compute limits. According to Reuters (2026), bandwidth and power efficiency are key bottlenecks, so fabric design, congestion control, and interconnect choice directly affect AI system economics.

Does this help data center network engineers?

Yes. It increases demand for engineers who understand EVPN fabrics, AI Ethernet behavior, telemetry, optics, and DPU-aware operations. The more heterogeneous AI racks become, the more valuable strong data center networking architecture skills become.

AI disclosure: This Dev.to version was adapted from the original FirstPassLab article with AI assistance for editing, formatting, and Dev.to-specific presentation. The technical claims and canonical source remain the original article on FirstPassLab.

Stop Extending the Perimeter: Why Managed SASE and Universal ZTNA Are Replacing VPNs

FirstPassLab — Thu, 16 Apr 2026 16:54:04 +0000

Most VPN refresh projects make the same mistake: they keep network-level trust and just put a nicer portal in front of it.

In 2026, the real architectural shift is from network access to resource access. Managed SASE and universal ZTNA move the decision point closer to identity, device posture, and the specific app being requested. For network security teams, that changes how you design policy, how you troubleshoot access, and how you phase migration off legacy VPN.

Here is the practical model: what broke the perimeter approach, what a modern managed SASE architecture actually looks like, and how to migrate without rebuilding flat trust in a new dashboard.

TL;DR

Managed SASE and universal ZTNA are winning because perimeter VPN risk keeps getting worse. ThreatLabz reported VPN CVEs grew 82.5% from 2020 to 2025.
The modern target state is one policy plane across users, devices, apps, and branches, not separate VPN, NAC, SWG, and firewall silos.
Cisco's current universal ZTNA workflow already reflects that shift with Secure Access, trusted networks, private resources, policy rules, and Secure Client enrollment.
The best migration path is phased: start with remote private-app access, validate identity and device posture continuously, then collapse branch, contractor, and unmanaged-device access into the same control plane.

What changed in 2026 that finally broke the perimeter model?

The perimeter model broke because enterprise traffic, user identity, and application placement stopped lining up with a single trusted network edge years ago, and 2026 is when operations teams finally stopped pretending otherwise. According to NIST SP 800-207 (2020), zero trust exists because remote users, BYOD, and cloud-based assets are no longer inside an enterprise-owned boundary. According to CISA (2026), zero trust improves visibility and enables more precise, least-privilege access decisions. According to Zscaler ThreatLabz (2025), VPN CVEs grew 82.5% from 2020 to 2025, and roughly 60% of the vulnerabilities reported in the past year were high or critical. That is the real forcing function. The question is no longer whether VPN still works technically. The question is whether broad tunnel-based trust is still defensible when users, apps, and attackers all operate everywhere.

Vendor messaging has also shifted in a way senior engineers should notice. Cisco now describes a model with a single policy engine across users, devices, and applications, not a bolt-on remote-access product. HPE Aruba's 2026 SASE trend analysis says universal ZTNA is becoming a first-class SASE pillar rather than a niche feature. That convergence matters because it tells you the market is settling on the same architectural answer: app-level, identity-aware access is replacing network-level trust as the design center.

What does a managed SASE and universal ZTNA architecture look like in 2026?

A 2026 managed SASE architecture uses a cloud-managed control plane to evaluate identity, device posture, context, and policy before exposing a specific application, network, or subnet, instead of dropping a user into a broad trusted overlay. According to NIST (2020), the core logic is still policy engine, policy administrator, and policy enforcement point. According to Cisco's current Universal ZTNA workflow (2026), the operational sequence is practical: onboard Secure Access and Firewall Management, define trusted networks, publish private resources, attach policy rules, associate them with enforcement devices, and enroll users with Secure Client 5.1.10 or later. That is exactly what a mature CCIE Security team should expect, a control plane that decides, an enforcement plane that brokers access, and a data plane that carries only the approved session.

The easiest way to visualize the stack is to separate control, enforcement, and transport.

Layer	What it does	What the engineer actually cares about
Identity and posture	Validates user, device, certificate, and context	IdP integration, MFA, posture signals, trusted networks
Policy engine	Decides allow, deny, or restrict	Least privilege, user groups, contractor policy, SaaS versus private-app rules
Enforcement points	Publishes or brokers access to specific resources	Secure Access connectors, FTD placement, branch edges, SWG/FWaaS path
Data plane	Carries approved app traffic	Latency, packet loss, QUIC/MASQUE behavior, path selection
Visibility and telemetry	Feeds continuous evaluation	Logs, risk scoring, incident response, troubleshooting

In Cisco's published workflow, the details are already concrete enough to be useful in design reviews. You define one or more trusted networks, supply the CA certificate for the ZTNA user, configure the FTD device with its FQDN, inside and outside interfaces, and PKCS12 certificate, then create private resources and map access policy rules to them. Cisco also notes that deployment reboots the device to reallocate resources for universal ZTNA components, which is the kind of operational gotcha that matters more than a marketing diagram. If you are planning a brownfield migration, that reboot window belongs on your change plan.

Why are perimeter VPN and flat remote-access models losing?

Perimeter VPN designs are losing because they solve reachability first and trust later, while zero-trust designs solve trust first and reachability only for the exact resource that passed policy. According to Zscaler ThreatLabz (2025), VPN vulnerabilities rose sharply over the last five years and the majority of newly reported issues in the last year were high or critical severity. According to IBM and Ponemon (2025), the global average cost of a data breach is $4.4 million. When the blast radius of a bad access decision is still measured in subnets instead of applications, the economics are no longer acceptable. The traditional VPN mental model, authenticate once, land on the network, and trust downstream controls to clean things up, is now the expensive model.

The comparison looks like this:

Design question	Legacy VPN answer	Managed SASE + universal ZTNA answer
What gets exposed?	A network segment or broad tunnel	A named app, subnet, or resource object
What is the trust anchor?	Network location after login	Identity, posture, and context on every request
How is contractor access handled?	Separate VPN profile or jump host	Same policy engine with narrower resource scope
How is IoT handled?	Usually outside the design or behind ACLs	Profiled, segmented, and controlled through policy and enforcement
How is lateral movement limited?	Mostly by firewalling after connection	By never granting broad network adjacency in the first place
How is troubleshooting done?	VPN concentrator, ACLs, and route tracing	Policy logs, resource maps, path telemetry, and user-to-app traces

This is also why older remote-access debates such as FlexVPN versus DMVPN are still useful but no longer sufficient. Those designs matter for overlays and transport, but the security control point has moved. The hard part in 2026 is not building another tunnel. The hard part is deciding which user on which device should be allowed to reach exactly which resource, under which conditions, and for how long.

How do you migrate from firewall-centric remote access to managed SASE in six steps?

The best migration path is phased, resource-driven, and brutally honest about legacy exceptions. According to NIST (2020), most enterprises will operate in a hybrid zero-trust and perimeter-based mode for an extended period. Cisco's current guide (2026) shows the same reality operationally, with trusted networks, enforcement devices, private resources, and client enrollment all arriving in stages. The mistake is trying to replace every remote-access workflow at once. Start with the users and applications that gain the most from app-level access and the least from broad network adjacency. That usually means contractors, private web apps, admin portals, and high-risk third-party access before branch-wide transport consolidation.

Inventory private applications, legacy services, user groups, and unmanaged devices that still depend on broad VPN access.
Integrate your identity provider, MFA, certificates, and device-posture signals so the policy engine has real inputs instead of static ACL assumptions.
Define trusted networks and private resources as applications, networks, or subnets, not generic tunnel destinations.
Deploy the enforcement points, which in Cisco's model means Secure Access plus Firewall Management and universal ZTNA-enabled FTD devices with correct inside/outside interface roles.
Write least-privilege policy per resource, including separate treatment for employees, contractors, privileged admins, and unmanaged or IoT-like devices.
Retire legacy VPN access incrementally, keeping only the narrow use cases that still require full tunnel semantics or legacy protocol support.

A practical migration checklist for CCIE Security teams should include policy objects, certificate lifecycle, DNS dependencies, private-resource naming standards, logging destinations, and change windows for enforcement-node reboot behavior. It should also include rollback logic. If policy-driven remote access becomes your new primary control plane, your rollback plan matters just as much as your allow rules.

What is the industry impact of managed SASE and universal ZTNA?

The industry impact is that remote access, branch security, contractor access, and unmanaged edge controls are being folded into one operating model, which changes both buying behavior and team structure. According to HPE Aruba's 2026 SASE trends analysis, universal ZTNA is becoming foundational rather than optional, and IoT coverage is one of the main reasons. According to Cisco's Zero Trust Access positioning (2026), the target is one policy engine across users, devices, and applications, with least-privilege enforcement for both AI and IoT use cases. According to IBM and Ponemon (2025), breach costs still average $4.4 million globally, which is why boards now care about access architecture in a way they did not when VPN was treated as a simple network service.

For operations teams, the biggest effect is organizational. Network, security, endpoint, and identity teams can no longer design in separate lanes. Your SASE rollout will fail if the network team thinks only about path quality, the security team thinks only about blocking, and the identity team treats posture as somebody else's problem. That is also why related developments such as enterprise zero-trust remote-edge hardening after the FCC router ban, identity segmentation in mixed-vendor estates, and SASE market spending growth through 2030 are part of the same story. The perimeter is not disappearing because one product category won. It is disappearing because identity, connectivity, and enforcement are becoming inseparable.

What should CCIE Security engineers focus on next?

CCIE Security engineers should focus less on memorizing product boundaries and more on mastering policy boundaries, because policy is now the architecture. NIST's model still matters because PE, PA, and PEP remain the cleanest mental framework for zero-trust design. Cisco's current workflow matters because it shows how those abstractions are turning into day-two operations with trusted networks, client enrollment, and private-resource publishing. ThreatLabz data matters because it explains why the old design center, broad VPN trust, has become harder to defend over time. The engineers who become indispensable in 2026 will be the ones who can map identity signals, segmentation strategy, branch connectivity, firewall insertion, and user experience into one coherent design.

That means three skill upgrades. First, get sharper at identity-driven policy, including certificates, posture, group mapping, and exception handling. Second, get better at publishing and troubleshooting private resources rather than just routing to them. Third, get comfortable with hybrid designs where some legacy VPN functions remain while zero-trust access expands. If you can explain when to keep a tunnel, when to broker an app, when to segment an IoT class, and when to move enforcement closer to the resource, you are already thinking like the engineers who will lead the next generation of production zero-trust deployments.

Frequently Asked Questions

Is managed SASE replacing VPN in 2026?

Yes, for most user-to-app access it is. According to Zscaler ThreatLabz (2025), VPN vulnerability pressure is still increasing, so new projects increasingly prefer identity-based access to specific resources over broad network tunnels.

What is the difference between ZTNA and universal ZTNA?

Universal ZTNA extends the same zero-trust logic beyond a narrow remote-user use case. In practice, it means applying one policy model to employees, contractors, branch users, unmanaged devices, private apps, SaaS, and in many cases IoT-connected resources.

Can universal ZTNA work with existing firewalls and on-prem apps?

Yes. Cisco's current Universal ZTNA workflow (2026) explicitly includes Firewall Threat Defense devices, inside and outside interfaces, private-resource objects, and policy synchronization between Secure Access and the enforcement point.

What is the biggest migration risk?

The biggest risk is carrying old perimeter assumptions into the new platform. If you publish large subnets, keep broad user groups, and skip posture or resource-level policy, you can recreate flat trust with nicer dashboards.

Does this matter for CCIE Security careers?

Absolutely. Managed SASE and universal ZTNA combine identity, segmentation, remote access, SaaS security, and policy automation, which makes them one of the clearest growth areas for senior CCIE Security engineers in 2026.

AI disclosure: this article was adapted from the original FirstPassLab post with AI assistance for Dev.to formatting and syndication. The original source remains the canonical version: https://firstpasslab.com/blog/2026-04-16-managed-sase-universal-ztna-2026/

Qualcomm's Wi-Fi 8 Push Means It's Time to Audit 6 GHz, mGig, and Roaming

FirstPassLab — Wed, 15 Apr 2026 22:53:01 +0000

Qualcomm just turned Wi-Fi 8 into a 2026 design discussion instead of a standards-watch item for later. The headline specs are flashy, but the part enterprise engineers should actually care about is this: 802.11bn is being built around ugly real-world problems like roaming failures, tail latency, overlapping cells, and uplink pressure at the wireless edge.

If you run campus wireless, this is the moment to audit 6 GHz coverage, mGig and 10G uplinks, PoE headroom, and the places where your current WLAN already falls apart under mobility or density. The real Wi-Fi 8 story is reliability engineering, not just a bigger PHY number.

Qualcomm's Dragonwing launch matters because it pulls Wi-Fi 8 into the 2026 enterprise design conversation instead of leaving it as a 2028 standards footnote. According to Qualcomm (2026), FastConnect 8800 reaches 11.6 Gbps peak PHY with a 4x4 client radio, while Dragonwing NPro A8 Elite targets up to 33 Gbps capacity and 1,500 clients in infrastructure gear. For enterprise wireless teams, the real story is not raw peak rate, but earlier visibility into how 802.11bn will change roaming, interference handling, edge coverage, and uplink design.

Key Takeaway: Treat Qualcomm's Wi-Fi 8 portfolio as an architecture signal, not a mandatory refresh trigger. Enterprise engineers should keep deploying Wi-Fi 7 where it solves current capacity problems, but start planning for multi-AP coordination, better roaming behavior, and heavier mGig and 10G access-layer demands now.

This announcement also fits a broader pattern. As enterprise network spending shifts toward wireless, AI, and edge infrastructure, vendors are no longer selling WLAN as a standalone AP problem. Qualcomm is packaging client silicon, AP silicon, fiber gateway silicon, and FWA silicon into one story. That is a useful clue for engineers and architects building the next three-year campus roadmap.

What Exactly Did Qualcomm Launch at MWC 2026?

Qualcomm launched one mobile Wi-Fi 8 client platform and five Dragonwing infrastructure platforms, which is why this announcement matters more than a single chipset release. According to Qualcomm's March 2026 press release, FastConnect 8800 is the first mobile connectivity system with 4x4 Wi-Fi, 10+ Gbps peak speeds, up to three times the gigabit range of the prior generation, and support for Wi-Fi 8, Bluetooth HDT, UWB, and Thread on one chip. On the infrastructure side, Dragonwing stretches from premium enterprise APs to mainstream mesh, 10G fiber gateways, and fixed wireless access.

Platform	Target role	Key claim	Why enterprise engineers care
FastConnect 8800	Mobile clients	11.6 Gbps peak PHY, 4x4 Wi-Fi, 3x range	Client behavior will change before campus infrastructure fully refreshes
Dragonwing NPro A8 Elite	Enterprise APs, premium routers	Up to 33 Gbps, 1,500 clients, 40% higher throughput	Signals what premium WLAN silicon will expect from uplinks and controllers
Dragonwing FiberPro A8 Elite	10G PON gateways	Wi-Fi 8 plus 10G fiber	Important for multi-dwelling and branch edge designs
Dragonwing FWA Gen 5 Elite	5G FWA edge	X85 modem plus Wi-Fi 8	Relevant for remote sites and backup WAN designs
Dragonwing N8 and F8	Mainstream routers and mesh	Wi-Fi 8 at volume tiers	Shows the standard is being positioned for broad rollout, not just premium pilots

According to Wi-Fi NOW Global (2026), the NPro A8 Elite is positioned for high-performance enterprise APs and premium routers, with a 5x5 radio architecture, up to 33 Gbps peak capacity, and support for 1,500 clients. That is not a normal early-standard message. It says Qualcomm believes operators and enterprise OEMs want Wi-Fi 8 hardware design wins now, even while 802.11bn is still being finalized.

Why Is Wi-Fi 8 a Bigger Enterprise Story Than Another Speed Headline?

Wi-Fi 8 matters because 802.11bn is designed to improve ugly, real-world wireless conditions instead of just winning a lab benchmark. According to Qualcomm's Wi-Fi 8 standards overview (2025) and the IEEE 802.11bn scope document, the standard targets at least 25% higher throughput in challenging signal conditions, 25% lower latency at the 95th percentile, and 25% fewer dropped packets, especially while roaming between access points. That makes Wi-Fi 8 more relevant to hospitals, warehouses, dense office floors, and stadiums than to marketing decks about one client hitting a perfect PHY rate next to an AP.

Samsung Research's 802.11bn technical review adds the detail enterprise architects actually need. Enhanced Long Range improves edge performance with repetition and a dedicated preamble design, while Distributed Resource Units can deliver up to 11 dB uplink power gain under some conditions by spreading tones across wider bandwidth. On the MAC side, P-EDCA, Low-Latency Indication, Non-Primary Channel Access, and Dynamic Sub-band Operation all attack the tail-latency problem that existing Wi-Fi 6E and Wi-Fi 7 networks still struggle with when cells overlap or real-time traffic competes with bulk transfers.

That is the key change in mindset. Wi-Fi 7 pushed features like MLO and wider channels, which were already important in today's high-density enterprise WLAN market. Wi-Fi 8 is trying to make the network more deterministic under contention. Qualcomm's own standards language around seamless roaming, multi-AP coordination, and edge performance lines up with the problems enterprise teams file tickets about today: sticky clients, voice jitter during handoff, bad behavior at cell edges, and ugly contention on crowded floors.

How Do Dragonwing and FastConnect Change Enterprise WLAN Design?

Dragonwing changes enterprise WLAN design by pushing more complexity to the edge at the same time that client devices become more capable. According to Qualcomm (2026), NPro A8 Elite combines Wi-Fi 8 radios, high-performance compute, an integrated Hexagon NPU, and system-level coordination features. In practice, that means tomorrow's access points are being designed less like simple radio heads and more like edge compute nodes. For campus architects, that raises immediate questions about switch uplinks, PoE budgets, telemetry pipelines, and how much control logic will move closer to the AP.

The first implication is uplink pressure. If premium Wi-Fi 8 infrastructure is being marketed around 33 Gbps aggregate capacity, your access-layer design cannot stop at a mental model built around 1G AP uplinks. Even before Wi-Fi 8 arrives, many teams are already discovering that modern high-density wireless designs and AI-heavy collaboration spaces create ugly oversubscription at the edge. Wi-Fi 8 will make those weak spots more obvious, not less.

The second implication is roaming architecture. Qualcomm and Samsung both emphasize collaborative AP behavior, especially multi-AP coordination and seamless mobility domains. That should catch the attention of anyone running voice over Wi-Fi, industrial handhelds, or medical carts. If vendors execute well, Wi-Fi 8 could finally reduce the gap between the clean controller diagrams in design docs and the messy handoff behavior users experience on live floors.

The third implication is client asymmetry. FastConnect 8800 gives clients new capabilities first, which means campus engineers may see more advanced behavior at the edge of the network before the whole infrastructure is refreshed. That happened with Wi-Fi 6E and Wi-Fi 7 as well. Engineers who learned to read that transition correctly did better than teams who waited for a full rip-and-replace.

What Should Enterprise Wireless Engineers Lab Right Now?

Enterprise teams should lab the constraints Wi-Fi 8 is trying to solve, not just the features it promises to add. The smartest move in 2026 is to baseline where your current Wi-Fi 7 and 6E environments already fail: roaming, latency tails, cell-edge performance, and uplink saturation. If you cannot measure those problems now, you will not know whether any Wi-Fi 8 platform is actually helping you later.

Start with infrastructure readiness checks on your controller and access layer. In Cisco environments, useful first commands include:

show ap dot11 6ghz summary
show wireless client summary
show interface status | include 2.5G|5G|10G
show power inline

Those commands will not make a Catalyst 9800 suddenly support Wi-Fi 8, but they do expose the current realities that matter. Do you already have 6 GHz coverage where it counts? Which AP-facing switchports are still capped below mGig? Where are you running hot on PoE? Which client populations are consuming the most airtime in dense zones? That baseline is far more valuable than waiting for a vendor webinar.

Next, isolate your worst mobility zone and test it hard. Warehouses, hospitals, and large campus collaboration floors are ideal because Wi-Fi 8's promise is strongest where roaming and latency consistency already hurt. According to Qualcomm (2025), seamless mobility and multi-AP coordination are core 802.11bn themes. If your current network already handles those cases well, you have time. If not, Wi-Fi 8 belongs on your short list for pilot evaluation.

Finally, connect this work to business priorities. Qualcomm's Wi-Fi 8 story is tied closely to AI endpoints and always-on edge workloads, which matches the broader AI infrastructure shift now hitting enterprise networking budgets. If your business is adding real-time video analytics, robotics, AR workflows, or dense collaboration spaces, Wi-Fi 8 is more than a wireless roadmap item. It becomes part of application reliability.

When Should Enterprises Plan Wi-Fi 8, and When Should They Wait?

Most enterprises should plan for Wi-Fi 8 now, pilot it in 2027, and deploy it selectively before considering broad refreshes. The right early targets are not normal office floors with healthy Wi-Fi 7, but the places where reliability matters more than peak throughput: high-density venues, mobility-heavy operations, latency-sensitive workflows, and remote sites where FWA plus WLAN convergence matters. Qualcomm's own release says commercial products are expected in late 2026, while Samsung Research points to March 2028 publication for the standard, so there is enough runway for serious evaluation but not enough reason for a blind platform jump.

Environment	Best move in 2026	Why
Healthy office Wi-Fi 7 campus	Wait	Little reason to replace stable 6E or 7 deployments
Stadium, airport, hospital, warehouse	Pilot	Roaming, density, and interference are exactly where 802.11bn aims to help
New branch with 10G fiber or FWA edge	Evaluate early	Dragonwing FiberPro and FWA platforms align well with greenfield edge builds
Budget-constrained refresh	Keep Wi-Fi 7	Standards maturity and client mix still favor Wi-Fi 7 today
CCIE lab and architecture teams	Study now	Skills around 6 GHz, mGig, roaming, and deterministic WLAN behavior are compounding

This is also where competitor content still has a gap. A lot of launch coverage stopped at "11.6 Gbps" or "AI-native". The more useful interpretation is that Qualcomm is betting enterprise buyers want reliability features commercialized before the standard process fully ends. That is the same signal serious architects should pay attention to.

Frequently Asked Questions

What did Qualcomm announce for Wi-Fi 8 in 2026?

Qualcomm announced the FastConnect 8800 mobile connectivity platform and five Dragonwing infrastructure platforms at MWC 2026. According to Qualcomm (2026), the lineup spans client devices, enterprise access points, premium routers, 10G fiber gateways, fixed wireless access, and mainstream mesh tiers. That breadth is why the launch matters more than a single premium chipset.

Is Wi-Fi 8 mainly about higher speed than Wi-Fi 7?

No. According to Qualcomm (2025) and Samsung Research (2025), Wi-Fi 8 is fundamentally about ultra-high reliability. The standard targets at least 25% better throughput in difficult signal conditions, 25% lower latency at the 95th percentile, and 25% fewer dropped packets while roaming. Speed still matters, but reliability is the design center.

What is the most important Wi-Fi 8 feature for campus networks?

Multi-AP coordination is the most important long-term feature for enterprise campuses because it addresses overlapping cells, interference, and inconsistent performance under load. Qualcomm explicitly frames this as a fix for dense campuses and public venues where independent AP behavior creates latency spikes and bad user experience.

Should enterprises skip Wi-Fi 7 and wait for Wi-Fi 8?

Usually no. If Wi-Fi 7 solves a real problem today, deploy it. According to Qualcomm, Wi-Fi 8 commercial products are expected in late 2026, but the standard itself continues maturing toward 2028. That means most enterprises should use Wi-Fi 7 for near-term capacity upgrades and reserve Wi-Fi 8 for pilots and targeted high-value zones first.

What should CCIE Enterprise candidates study first for Wi-Fi 8?

Study 6 GHz design, mGig and 10G uplinks, PoE headroom, mobility behavior, and high-density RF trade-offs first. Those are the areas where Wi-Fi 8 extends existing enterprise wireless design, not replaces it. If you already understand Wi-Fi 7 adoption patterns and modern high-density venue design, you are building the right foundation.

AI disclosure: This Dev.to version was adapted with AI assistance from the original FirstPassLab article for community syndication. The technical analysis, claims, and source links were preserved from the canonical post.

Agentic AI in NetOps: What to Automate First, What to Keep Human-Approved

FirstPassLab — Wed, 15 Apr 2026 16:55:18 +0000

Network teams are about to hear the same pitch from every vendor: let AI run NetOps. The useful version of that idea is real, but it is much narrower and much more engineering-heavy than the marketing suggests.

The practical question is not whether an LLM can push configs. It is which operational tasks have enough telemetry, deterministic tooling, and rollback safety to let an AI agent help without creating a bigger outage.

In this post, I break down where agentic AI is already credible in network operations, where it still needs human approval, and what infrastructure teams should build before they trust autonomous workflows in production.

Quick take: Start with evidence gathering, correlation, validation, and approval-gated remediation. Do not start by giving an AI agent raw SSH access to production.

What does agentic AI in network operations actually mean?

Agentic AI in network operations means the system is working toward an operational goal, not just reacting to a prompt or correlating alarms. According to Selector (2026), classic event intelligence and AIOps help reduce noise and speed root cause analysis, but agentic NetOps adds goals, context, reasoning, and action. According to Cisco (2026), its AgenticOps model combines live telemetry, domain-specific reasoning such as the Deep Network Model, and deterministic execution through governed workflows. In plain English, that means the platform can watch the network, test multiple hypotheses, collect evidence from tools, recommend a fix, and sometimes execute that fix inside policy boundaries. That is very different from an LLM that only summarizes syslog messages.

The cleanest way to understand the shift is this:

Capability	Traditional AIOps	Agentic NetOps
Primary job	Correlate events and reduce alert noise	Pursue operational outcomes such as faster recovery or safer change validation
Context	Mostly events, logs, and anomalies	Telemetry, topology, policy, dependencies, history, and tool access
Reasoning	Pattern detection and recommendations	Multi-step planning, hypothesis testing, and tool orchestration
Action	Human executes runbook	AI can execute approved workflows under guardrails
Risk model	Low automation risk, lower operational leverage	Higher leverage, so governance and auditability are mandatory

That last line matters most. Engineers on Reddit are saying the quiet part out loud. In r/networking, one practitioner wrote that many vendor AIOps products still feel like "turning on NetFlow and going 'that's an anomaly' every day a 1000 times a day," while another argued that networking remains too "snowflakey to automate at scale" without better context. Those complaints are not anti-AI. They are anti-hype. Agentic NetOps only works when it has enough environment-specific knowledge to act safely.

Why is 2026 the inflection point for autonomous NetOps?

2026 looks like the inflection point because three things are finally arriving at the same time: better reasoning models, richer cross-domain telemetry, and controller-level execution layers that can be audited. According to Gartner via PagerDuty (2025), enterprise deployment of agentic AI for infrastructure operations is expected to rise from less than 5% in 2025 to 70% by 2029. According to Cisco (2026), agentic troubleshooting now spans campus, branch, industrial, data center, and service provider workflows, while its AI Assistant and Agentic Workflows are already running at production scale. According to Microsoft Community Hub (2025), Azure Networking used NOA agents to cut time-to-detect for fiber incidents by 60% and improve repair times by 25%.

That combination changes the industry conversation. For years, the promise was "self-healing networks," but the reality was dashboards, ticket routing, and endless false positives. Now the vendors with the strongest execution story are not leading with magic. They are leading with specific use cases:

Cisco says autonomous troubleshooting can cut MTTR to minutes in campus, branch, and industrial networks.
Cisco says continuous optimization can tune RF, QoS, path selection, and control planes from live conditions.
Cisco says trusted validation can evaluate blast radius and policy impact before a change is executed.
Microsoft's NOA architecture focuses on specialist agents, a planner agent, and approvals for any risky action.

That is a much more believable roadmap than generic "AI for networking" messaging. It also explains why related markets are moving fast, from real-time data streaming for operations to AI-native networking startups.

What technical architecture makes agentic NetOps safe enough for production?

A safe agentic network needs five layers working together: telemetry, context, reasoning, deterministic tools, and policy enforcement. According to Cisco (2026), AgenticOps starts with cross-domain telemetry from networking, security, observability, and application experience. According to Selector (2026), autonomy fails when data quality and causal context are weak. According to Techzine (2026), Cisco is exposing operations tools through controller-level MCP servers rather than letting agents improvise directly on every device. That design choice is the real story, because it creates a constrained execution plane that engineers can observe, test, and roll back.

A practical reference architecture looks like this:

Layer	What it should include	Why it matters
Telemetry	Syslog, streaming telemetry, flow data, controller metrics, client experience data	Agents cannot reason well from isolated alerts
Context graph	Topology, dependencies, change history, intent, maintenance windows	Prevents locally correct but globally bad actions
Reasoning layer	Domain-tuned model plus general reasoning model	Separates network expertise from generic language ability
Tool layer	Approved APIs, playbooks, MCP servers, test harnesses	Makes actions repeatable and auditable
Governance layer	RBAC, approval gates, blast-radius limits, rollback, logging	Turns autonomy into controlled operations instead of risk

This is also where protocol behavior still matters. A trustworthy agent should understand that an OSPF neighbor flap and a BGP session drop are not just two red alerts. They imply adjacency loss, route churn, possible upstream transport failure, and potential application impact. Before any remediation, the system should be able to gather deterministic evidence with commands such as:

show bgp ipv4 unicast summary
show ip ospf neighbor
show interfaces counters errors
show logging | include %BGP|%OSPF|%LINEPROTO

That kind of evidence collection is exactly where agentic AI shines. The agent does the repetitive data pull at machine speed, and the engineer reviews the reasoning, the proposed fix, and the expected blast radius.

For official reference material, Cisco's AgenticOps announcement, Microsoft's Network Operations Agent framework, and the Model Context Protocol are worth bookmarking.

Which network tasks should AI handle first, and which should stay human-approved?

The best first tasks for agentic AI are the ones with high repetition, clear evidence, and low irreversible blast radius. According to Cisco (2026), autonomous troubleshooting, RF optimization, QoS tuning, and validation against live topology are already emerging as early production use cases. According to Cisco's networking blog (2026), its AI Packet Analyzer was trained on more than one million packet captures, which is exactly the sort of bounded expert task where machine speed beats manual toil. In contrast, major route-policy changes, security segmentation updates, and anything that can blackhole traffic across multiple domains should remain human-approved until rollback and intent validation are proven.

Use this decision table when you scope your first rollout:

Task	Autonomy level to start with	Why
Alert correlation and incident summarization	Full autonomy	Low risk, high operator time savings
Evidence gathering from controllers, logs, and CLI	Full autonomy	Deterministic and easy to audit
Wireless RF tuning and path optimization	Partial autonomy	Strong telemetry feedback loop, bounded effect
Compliance checks and pre-change validation	Partial autonomy	Great value, but findings should be reviewed initially
Ticket enrichment and cross-team handoffs	Full autonomy	High toil, low blast radius
Firewall policy changes	Human approval required	Security regressions are expensive
BGP route-policy or segmentation changes	Human approval required	Blast radius can exceed the local domain
Multi-domain remediation during an outage	Human approval required	Requires business context and rollback judgment

That is also where the Reddit skepticism is useful. One engineer wrote that current systems are "not very trustworthy at even triaging the most basic of issues," while another said AI is strongest as "extra eyes and ears to process predictive data 24x7." Both can be true. The right design pattern is not zero autonomy or full autonomy. It is layered autonomy, where low-risk tasks are delegated first and high-risk changes stay behind approval gates.

How should network and platform teams prepare for agentic NetOps right now?

Network and platform teams should prepare for agentic NetOps by getting better at operational data, controller-driven workflows, and policy engineering, not by trying to become prompt engineers. According to Cisco (2026), governed execution depends on cross-domain telemetry and explainable workflows. According to Selector (2026), AI must understand before it can act. That means the winning teams in 2026 are the ones that can normalize telemetry, model intent, expose safe tools, and measure outcomes. If you already care about AI-driven reliability, automation career positioning, and market signals around automation roles, this is where those threads converge.

Here is the most practical rollout sequence I would recommend:

Unify telemetry before you add agents. Pull in controller data, client health, flow records, security events, and change history.
Define business-facing experience metrics. Time to connect, roaming quality, app latency, and incident restore time are better targets than raw device counters.
Wrap execution tools at the controller layer. Give agents approved APIs and MCP-exposed tools, not unconstrained CLI access.
Start with observation and validation. Let the system investigate, summarize, and simulate before it remediates.
Gate risky changes with approvals and rollback. No exceptions for routing policy, segmentation, or Internet edge changes.
Measure trust with hard numbers. Track MTTR, false-positive rate, rollback frequency, and operator hours saved.

This is also the career angle. The engineer who can build safe closed-loop workflows will be more valuable than the engineer who only pastes configs or only writes Python. Agentic NetOps rewards people who understand protocols, intent, operational risk, APIs, and governance as one system.

Frequently Asked Questions

What is agentic AI in network operations?

Agentic AI in NetOps means AI systems can observe telemetry, reason across context, and execute approved actions instead of only surfacing alerts or recommendations. The difference from a chatbot is operational intent: the agent is trying to restore service, validate a change, or prevent degradation inside policy boundaries.

How is AgenticOps different from AIOps?

AIOps usually focuses on event correlation, anomaly detection, and recommendations. AgenticOps extends that model with planning, tool use, and governed execution, so the system can investigate, validate, and sometimes remediate instead of stopping at a dashboard insight.

Can agentic AI replace network engineers?

No. According to Cisco (2026) and Microsoft Community Hub (2025), the model is human-supervised autonomy, not human removal. Engineers still define intent, approve risky changes, validate architecture, manage exceptions, and own the business consequences of operational decisions.

What should teams automate first with agentic NetOps?

Start with evidence gathering, alert summarization, cross-domain correlation, compliance checks, and bounded optimization tasks such as RF or path tuning. Leave route-policy changes, segmentation, and multi-domain outage remediation behind approval gates until rollback and validation are proven.

AI disclosure: This Dev.to version was adapted with AI assistance from the canonical FirstPassLab article, then reviewed and edited before publication. Canonical source: https://firstpasslab.com/blog/2026-04-15-rise-of-agentic-ai-when-networks-manage-themselves/

DevNet Expert Is Now CCIE Automation. What Actually Changes for Network Automation Engineers

FirstPassLab — Tue, 14 Apr 2026 22:54:24 +0000

Cisco changed the name, not the blueprint. Python, NETCONF/RESTCONF, YANG, CI/CD, and infrastructure-as-code are still the core skills. But the rename from DevNet Expert to CCIE Automation changes something very real for working engineers: recruiter filters, compensation bands, and how automation work gets classified inside enterprise hiring.

If you build automation for network changes, policy deployment, or compliance workflows, this is less about branding hype and more about market visibility.

TL;DR

The exam content did not fundamentally change.
The market signal did.
"CCIE" shows up in ATS filters, recruiter searches, and compensation frameworks in ways "DevNet Expert" often did not.
The rebrand helps automation engineers get seen, but hiring-manager understanding will still lag for a while.

What actually changed?

According to Cisco's 2026 certification update, the DevNet track was renamed across the board:

Old name	New name
DevNet Associate	CCNA Automation
DevNet Professional	CCNP Automation
DevNet Expert	CCIE Automation

The important part is what didn't change.

The core automation skill set is still the same.
The blueprint still centers on APIs, programmability, model-driven operations, and automation pipelines.
The difficulty did not suddenly get easier because the badge changed.

So this was not a new technical track. It was a repositioning of automation as a first-class networking specialty under the CCIE brand.

Why the rename matters more than it looks

For a lot of engineers, the old problem was not skill mismatch. It was discoverability.

In many enterprises, job requirements, recruiter searches, and internal leveling frameworks still use blunt keyword matching. If the requirement says CCIE, then profiles containing CCIE float to the top. If your certification says DevNet Expert, you may never make it into the same shortlist, even when your actual skills map well to the job.

That matters because automation engineers often sit in an awkward middle zone:

too network-heavy for generic software roles
too code-heavy for traditional networking hiring funnels
too specialized for HR systems that classify people by old labels

The rebrand does not solve all of that, but it removes one structural blocker.

The practical impact for network automation engineers

1. Better recruiter and ATS visibility

This is the biggest near-term gain.

When the credential includes CCIE, it starts matching the language that enterprise recruiters already use. That increases the odds of showing up in:

recruiter keyword searches
ATS filters for senior network roles
compensation review discussions tied to certification tiers

That may sound superficial, but it affects whether you get contacted at all.

2. Stronger salary positioning

Historically, CCIE-branded tracks have been easier to anchor in senior compensation bands. The problem for DevNet Expert holders was not necessarily lower capability, but weaker market recognition.

If an employer already understands CCIE as a premium signal, then CCIE Automation gives automation engineers a cleaner reference point during salary discussions.

That does not guarantee better offers. It does make the conversation simpler.

3. Better alignment with how modern network teams actually work

Network operations is no longer just CLI depth plus protocol knowledge. Mature teams increasingly need people who can:

automate repetitive change windows
validate intended state before deployment
integrate network systems with CI/CD workflows
use APIs instead of fragile screen scraping
bridge operations, platform engineering, and security controls

The rename is Cisco acknowledging that this is networking expertise, not a side discipline.

What still has not been fixed

The market signal improved. The education problem did not disappear.

Hiring managers still need context

A lot of managers understand CCIE Enterprise, Security, or Data Center immediately. Fewer can explain what CCIE Automation covers in practical terms.

So even with a better title, engineers will still need to translate the credential into business and technical outcomes:

automated provisioning
faster validation
reduced change risk
repeatable policy rollout
lower operational toil

The "is it a real CCIE?" debate is not over

Some engineers still define CCIE primarily around deep protocol and platform implementation under lab pressure.

That is a fair instinct, but it misses how much modern network engineering now depends on automation literacy. Building and troubleshooting production-grade automation against live APIs, source-of-truth systems, and deployment pipelines is not trivial. It is just a different kind of expert pressure.

Multi-vendor portability still depends on how you learned it

The most transferable parts of the track are things like Python, REST APIs, NETCONF, YANG models, testing habits, and automation design patterns.

The least transferable parts are tool-specific workflows tied closely to a single vendor platform.

So the credential helps, but your real portability still depends on whether you learned principles or only one vendor's tooling surface.

How I would use the rebrand if I were in the market

If you hold the former DevNet Expert, the obvious move is to update every place where discovery happens:

LinkedIn headline
resume certification section
email signature
portfolio site
speaker bios and conference profiles

Then back the title up with concrete proof of work.

For example, instead of stopping at the certification name, show evidence like:

built API-driven configuration pipelines for Cisco platforms
used NETCONF/RESTCONF to validate and deploy change sets
automated compliance checks across production devices
integrated network workflows with Git-based approvals and testing
reduced manual provisioning time from hours to minutes

That is what turns the credential from a label into a hiring advantage.

The bigger industry takeaway

The interesting part here is not just certification branding.

It is that automation is being folded into the core identity of advanced networking work. That tracks with where the industry is already headed:

more intent and policy driven operations
more API-centric tooling
more pre-change validation
more overlap between networking, security, and platform engineering

The engineers who benefit most from this shift will not be pure coders with no network depth, or pure CLI specialists with no automation skills.

It will be the people who can do both.

Final take

The move from DevNet Expert to CCIE Automation does not magically upgrade anyone's technical ability.

What it does is remove a naming problem that was getting in the way of qualified automation engineers being found, understood, and priced correctly.

That is a meaningful change.

And if the industry keeps moving toward API-first operations, validation pipelines, and software-shaped infrastructure, this track will look less like an outlier and more like the direction the rest of networking was always heading.

AI disclosure: This Dev.to article was adapted from a FirstPassLab original using AI-assisted editing and formatting. The source analysis and final review were done by FirstPassLab.

Identity Beats IP Policy: What Forescout's New Segmentation Model Means for Multi-Vendor Networks

FirstPassLab — Tue, 14 Apr 2026 16:53:47 +0000

Zero trust segmentation keeps failing for the same reason: policy is still glued to IP addresses, VLANs, and static assumptions about what a device is. That works until you add unmanaged IoT, OT controllers, medical gear, M&A-driven vendor sprawl, or plain old DHCP churn.

Forescout's latest identity-driven segmentation release is interesting because it treats segmentation as a classification problem first and an enforcement problem second. If you run multi-vendor networks, that shift matters more than the press release headline.

Why it matters: Cisco TrustSec still gives you stronger native enforcement on Cisco-heavy networks. But Forescout is pushing a model that fits the environments many teams actually inherit: mixed vendors, unagentable assets, and east-west flows that are hard to describe with static ACLs alone.

What Did Forescout Actually Launch on March 23, 2026?

Forescout launched a cloud-native, agentless segmentation capability inside the 4D Platform that models policy by device identity, attributes, behavior, and risk instead of by subnet alone. According to Forescout (2026), the platform now lets teams visualize zones from a single console across IT, OT, IoT, and IoMT, while reducing onboarding from weeks to hours and avoiding vendor lock-in or a network redesign. That matters because traditional segmentation tools usually force one of three compromises: they cover only managed endpoints, they work only in OT, or they depend on agents that industrial and medical devices cannot run. According to Network World (2026), Forescout's new zone modeling can use up to 1,200 device attributes, overlay risk levels onto communication matrices, and validate policy against actual communication patterns before enforcement.

Most reporting stopped at "new segmentation feature," but the design detail is more interesting. The 4D Platform's segmentation sits on top of existing asset intelligence, risk scoring, and control workflows. According to Forescout (2026), it combines more than 30 agentless discovery methods and turns that data into heatmaps and matrix views for east-west communication risk. According to Industrial Cyber (2026), the product is meant to bridge IT and OT without agents, redesign, or single-vendor dependency. In practice, that means the release is less about one more NAC dashboard and more about moving segmentation planning upstream, before enforcement breaks production.

Capability	Legacy port-based NAC	Forescout 4D segmentation	Why it matters
Primary policy anchor	VLAN, IP, port	Identity, attributes, behavior, risk	Survives DHCP churn and device mobility
Asset coverage	Mostly managed endpoints	Managed, unmanaged, and unagentable devices	Better fit for OT, IoT, and healthcare
Deployment style	Appliance-centric	Cloud-native overlay	Faster rollout in hybrid estates
Validation model	Enforce first, troubleshoot later	Model communication before enforcement	Lower outage risk
Vendor dependency	Often strong	Multi-vendor by design	Better for acquisition-heavy enterprises

Why Is Identity-Driven Segmentation Replacing IP-Based NAC?

Identity-driven segmentation is replacing IP-based NAC because zero trust breaks when policy depends on addresses that move faster than the business. According to NIST SP 800-207, zero trust protects resources rather than trusting network location, and that principle lines up almost perfectly with Forescout's argument that segmentation should follow device identity, not subnet placement. According to Network World (2026), Justin Foster described the shift clearly: a laptop can change IPs, but the device's role, owner, function, and risk profile remain far more stable anchors for policy. That is why identity-centric models are gaining traction in hospitals, factories, and campuses where DHCP churn, roaming clients, mergers, and temporary VLAN workarounds make ACL sprawl hard to govern.

This is also where the release intersects directly with real-world Cisco practice. Cisco TrustSec solved much of this years ago by replacing IP-bound policy with SGT-based policy. According to Cisco (2026), SGACLs are topology-independent and continue to apply even when devices move or change IP addresses. A typical Catalyst enforcement pattern still looks like this:

interface GigabitEthernet1/0/2
 authentication port-control auto
 mab
 dot1x pae authenticator
 cts role-based enforcement

That is the key technical point for network security engineers. Forescout is not inventing identity-based policy, Cisco already proved that model with SGTs and SGACLs. What Forescout is doing is extending the argument to environments where 802.1X coverage is incomplete, where endpoints cannot run agents, or where five to seven vendors share the same production network. That gap is exactly where older NAC programs usually stall.

How Does Forescout Enforce Policy Across Multi-Vendor, OT, and IoT Networks?

Forescout enforces policy as an overlay that talks to existing switching and routing infrastructure, rather than requiring a rip-and-replace fabric. According to Network World (2026), the platform can communicate directly with switches and routers or use SDN control layers where a vendor requires it, with Arista enforcement routed through CloudVision rather than the switch itself. It can also move newly identified devices into a more appropriate VLAN automatically, collect visibility from SPAN ports and packet brokers such as Gigamon and Keysight, and classify non-agentable OT devices through header scraping, active probes, remote execution scripts, and secure proxy methods. That blend of control and discovery is the practical reason this launch matters.

For network engineers, the architecture is easiest to understand as three layers:

Asset intelligence layer: identify device type, owner, function, and risk across IT, OT, IoT, and IoMT.
Policy modeling layer: build zones and allowed flows with matrix-based heatmaps before turning controls on.
Enforcement layer: push actions through the infrastructure you already own, including VLAN changes and controller-driven policy.

The hardest problem here is not policy syntax, it is classification accuracy. Network World's example is a good one: if a system looks like a generic Windows endpoint but is actually an MRI system, placing it in the wrong segment can create patient safety and compliance risk. That is why identity-driven segmentation depends on visibility quality more than on pretty dashboards. It also explains why many organizations on Reddit and in forums talk about NAC migrations as operationally messy. One Reddit networking post surfaced by Tavily describes an organization "moving from using Forescout for NAC to Cisco ISE with 802.1x/MAB," which is a useful reminder that segmentation changes are never just licensing decisions, they are identity, policy, and workflow redesign projects.

What Should CCIE Security Engineers Learn From This Release?

Network security engineers should read this release as a signal that production zero-trust work is becoming broader than Cisco-only policy enforcement. According to IoT Analytics (2025), connected IoT devices reached 18.5 billion in 2024 and are projected to hit 39 billion by 2030. According to Forescout (2026), 75% of the riskiest connected devices in its 2026 Vedere Labs report were new to the rankings in the last two years. That combination, exploding device count plus rapidly shifting device risk, explains why enterprises want segmentation tied to asset intelligence and east-west visibility rather than static access lists. If you design or operate production security controls, this is the operational reality behind modern zero-trust programs.

In practical terms, this release reinforces five skills worth building now:

Understand how Cisco ISE and TrustSec segmentation maps identity to enforcement.
Practice ISE 3.x lab deployment so you can compare native Cisco workflows with overlay models.
Track how vendors such as Nile are packaging native NAC and microsegmentation into broader platform plays.
Understand why SASE growth is pushing segmentation decisions closer to identity and application policy.
Read where the broader zero-trust blueprint is heading so you are not studying only for the lab and missing the market.

The opportunity is straightforward. Engineers who can translate between Cisco-native controls, vendor-agnostic overlays, and OT-aware asset discovery will be more useful than engineers who know only how to paste RADIUS templates. I am glad this release makes that visible.

Does Forescout Replace Cisco ISE and TrustSec, or Complement Them?

In most enterprises, Forescout complements Cisco ISE and TrustSec rather than replacing them outright. According to Cisco (2026), TrustSec still delivers deep native enforcement with SGTs, SGACL matrices, and topology-independent policy on supported Cisco infrastructure. According to Network World (2026), Forescout's strength is that it can classify and segment assets across networks that are already heterogeneous and often include unagentable OT and IoMT systems. The architectural question is therefore not "which one is better?" but "where do you need native enforcement, and where do you need broader visibility and policy abstraction?" Cisco-heavy campuses often still favor ISE plus TrustSec. Hybrid hospitals, factories, and acquisition-heavy enterprises may favor Forescout for visibility and policy design, then use vendor-native enforcement where available.

A simple buying lens looks like this:

Question	Cisco ISE + TrustSec	Forescout 4D segmentation
Best fit	Cisco-dominant campus and branch	Mixed-vendor IT, OT, IoT, IoMT
Identity model	802.1X, MAB, SGT, ISE policy sets	Asset identity, labels, behavior, risk
Enforcement strength	Deep native Catalyst and Nexus policy	Flexible overlay across existing infrastructure
OT and agentless coverage	Possible, but not the core strength	Core design goal
Main tradeoff	Stronger native control, narrower ecosystem	Broader coverage, less single-vendor depth

That is the competitor gap most quick news coverage missed. The headline is not simply that Forescout added segmentation. The deeper takeaway is that zero-trust design is turning into a data-quality and control-plane orchestration problem. The engineers who win will understand both the native Cisco path and the overlay path.

Frequently Asked Questions

What did Forescout launch in March 2026?

Forescout launched cloud-native, agentless identity-driven segmentation in the 4D Platform on March 23, 2026. According to Forescout (2026), the release adds zone modeling across IT, OT, IoT, and IoMT assets without requiring a network redesign or vendor lock-in.

Is Forescout replacing Cisco ISE and TrustSec?

Not in most Cisco-heavy enterprises. Cisco ISE and TrustSec remain stronger for native SGT and SGACL enforcement on Catalyst and Nexus, while Forescout is more attractive when coverage must extend to unmanaged, unagentable, and multi-vendor environments.

Why is identity-driven segmentation better than IP-based segmentation?

Identity-driven segmentation is more durable because policy follows what a device is and how risky it is, not the IP address it happens to hold today. According to NIST SP 800-207, zero trust should protect resources rather than trust network location, which is exactly why identity-based policy scales better in hybrid networks.

What should network security engineers learn from this release?

They should keep mastering Cisco-native controls, especially ISE, TrustSec, 802.1X, MAB, and SGACL verification. They should also add asset classification, OT and IoT discovery, zone modeling, and multi-vendor policy design, because that is where real customer networks are going.

AI disclosure: This post was adapted from an original FirstPassLab article with AI assistance and reviewed before publication. The original source is here: https://firstpasslab.com/blog/2026-04-14-forescout-identity-segmentation/

AI Can Generate the Network Config. The Real Job Is Validating It Before Production

FirstPassLab — Mon, 13 Apr 2026 22:55:35 +0000

AI Can Generate the Network Config. The Real Job Is Validating It Before Production

Large language models are already pretty good at producing VLAN stanzas, ACLs, and even decent-looking BGP policy snippets.

That does not mean the network engineer disappears.

It means the low-value part of the job, repetitive config generation, gets compressed. The high-value part, understanding intent, validating impact, enforcing policy, and debugging failures across the automation stack, becomes more important.

That is the real shift happening in network automation right now.

Where AI is already useful in network operations

According to Gartner's 2026 network automation outlook, network automation deployments are expected to triple by the end of 2026. In practice, the first wave is landing in a few obvious places:

Config generation from natural-language requests
Policy translation from intent into ACL, segmentation, or QoS changes
Change validation against known baselines
Troubleshooting assistance by correlating telemetry, logs, and historical incidents
Compliance checking against CIS, NIST, and internal standards

That is enough to remove a lot of repetitive work from daily operations.

Why CLI-only work is the first thing that gets compressed

The easiest network tasks to automate are the ones that already follow a template.

Think about the work that fills a normal week:

Task	AI / automation readiness
VLAN creation and assignment	High
ACL updates	High
Standard BGP or OSPF neighbor config	High
Software upgrade orchestration	High
Tier-1 troubleshooting	Medium
Architecture decisions	Low
Incident judgment under ambiguity	Low

If your value is mostly typing device-by-device CLI faster than the next person, AI is coming for that margin.

If your value is understanding blast radius, rollback paths, control-plane behavior, policy intent, and failure domains, AI makes you more leveraged, not less.

That is why the real question is not, "Can AI write a config?"

It is, "Who understands whether that config is safe to deploy into this network?"

The interfaces AI actually uses are the automation stack

This is the part that matters most.

AI does not magically operate networks by vibes. It plugs into the same interfaces automation engineers have already been building around:

NETCONF / RESTCONF for structured device changes
YANG models for schema and validation
gNMI and streaming telemetry for observability and feedback loops
Python for workflow glue, guardrails, and custom logic
CI/CD pipelines for change testing and promotion
Infrastructure as Code tools like Ansible and Terraform
Controller APIs such as Catalyst Center, NSO, Meraki, or vendor-specific platforms

That is why the engineers who understand the automation stack are in the best position for the next wave.

They are the people who can:

review what the model is trying to change
constrain it with guardrails
test it before production
debug it when the generated change is technically valid but operationally wrong

A generated payload that matches a YANG model is not the same thing as a safe network change.

"AgenticOps" is just networking automation with more autonomy attached

Vendors are starting to describe the next phase as AgenticOps: AI systems that do more than suggest. They detect anomalies, correlate causes, propose fixes, and sometimes initiate actions.

That direction showed up clearly in 2026 messaging from Cisco, Huawei, and NVIDIA:

Huawei talked about autonomous AI agents for network operations
NVIDIA released a telecom-focused large model tuned for network data
Cisco framed the shift as NetOps -> AIOps -> AgenticOps

The common thread is simple: once systems can propose and execute changes, your production risk moves from manual keystrokes to automation design.

So the bottleneck becomes:

model quality
policy quality
test quality
rollback quality
telemetry quality
human review at the right control points

That is engineering work, not prompt theater.

What the AI-era network engineer actually does

The strongest network engineers in the next few years will not be the people who refuse automation.

They will be the people who can operate one level higher.

A realistic day looks something like this:

Morning

review AI-generated change recommendations
compare them to maintenance windows, dependency graphs, and policy constraints
approve, reject, or modify the rollout plan

Midday

define intent for segmentation, routing, or capacity policy
encode guardrails in CI checks and controller workflows
validate proposed changes in lab or pre-prod

Afternoon

investigate the ugly cases the model could not fully resolve
reproduce failures with Python, pyATS, or simulation tools
fix the workflow, not just the one broken command

That is the leverage point.

The job shifts from being the person who types every command to being the person who designs, validates, and governs the system that does.

A practical skills stack for the next 2 years

If I were advising a network engineer who wants to stay relevant as AI becomes normal in ops, I would focus on this stack:

YANG + NETCONF/RESTCONF
Learn how modern structured configuration actually works.
Python for network workflows
Not full-time software engineering, just enough to query APIs, parse responses, and build sane glue code.
Git and CI/CD for network changes
Because generated configs without test gates are just faster mistakes.
Infrastructure as Code
Especially Ansible and Terraform, depending on whether you live more in device automation or cloud networking.
Streaming telemetry and observability
Autonomous systems are only as good as their feedback loops.
Lab validation
Build a place where you can test workflows, not just device configs.

If you want a hands-on starting point, I like building around a small lab plus structured APIs first, then layering CI and telemetry on top.

The certification angle, briefly

The original FirstPassLab piece behind this post focused on CCIE Automation as a signal that these skills are becoming core networking skills, not a side quest for "developer types."

I think that broader point is right even if you are not pursuing that specific certification.

The market is moving toward engineers who can bridge protocol knowledge with automation interfaces.

Knowing BGP matters.
Knowing how to validate a BGP change through an API-driven workflow matters more than it did two years ago.

The main takeaway

AI will absolutely write more network config.

But production networks are not judged on whether a config looks plausible. They are judged on whether the change is safe, reversible, observable, and aligned with business intent.

That means the durable skill is not raw CLI speed.

It is being the engineer who can turn AI output into controlled network change.

If you learn the automation interfaces now, AI is more likely to become your amplifier than your replacement.

This post is adapted from the original FirstPassLab article: AI Will Write Your Network Configs by 2028 — Why CCIE Automation Is Your Insurance Policy.

AI disclosure: This article was adapted from an original FirstPassLab post with AI assistance for editing and syndication. The canonical version lives at FirstPassLab.

Oracle Is Funding 131K-GPU Clusters. Here’s Why RoCEv2 Fabrics Just Became a Board-Level Problem

FirstPassLab — Mon, 13 Apr 2026 16:54:12 +0000

Oracle Is Funding 131K-GPU Clusters. Here’s Why RoCEv2 Fabrics Just Became a Board-Level Problem

Oracle’s latest AI infrastructure push is easy to read as a finance story: layoffs, capex, hyperscaler pressure, and another giant GPU announcement.

But the more interesting signal for engineers is lower in the stack.

Oracle says OCI Supercluster can scale to 131,072 GPUs, with 2.5 to 9.1 microseconds of cluster latency and up to 3,200 Gb/sec of cluster network bandwidth. Once numbers get that large, the network stops being “supporting infrastructure” and starts deciding whether the AI investment pays off at all.

That is why this story matters even if you never touch Oracle Cloud directly. It is a clean example of a broader shift across the industry: AI-era infrastructure is turning congestion control, queue behavior, optics, and east-west fabric design into executive-level concerns.

Why this is a networking story, not just a cloud spending story

Big AI clusters fail on data movement long before they fail on raw GPU count.

If you buy thousands of accelerators but cannot keep collective traffic predictable, you do not have an AI platform. You have an expensive queueing experiment.

According to Oracle’s AI infrastructure material, the company is building around a RoCEv2-based cluster fabric with NVIDIA ConnectX NICs, high-bandwidth east-west networking, and an architecture direction that emphasizes offload and multiplanar design. That tells us two things:

The back-end fabric is now part of the product.
The back-end fabric is now part of the business case.

In normal enterprise environments, network teams can get away with talking about throughput, redundancy, and high-level topology. In large AI environments, those abstractions are not enough. The important questions become much more specific:

What happens to collective traffic during microbursts?
How big is the pause-domain blast radius?
Are ECN thresholds tuned well enough to mark before the fabric gets ugly?
Are front-end and back-end flows isolated cleanly?
Can you prove latency behavior under sustained load, not just in synthetic idle tests?

That is why a headline about layoffs quickly becomes a lesson about packet paths.

What Oracle is actually betting on

Strip away the corporate drama and the technical bet looks straightforward.

Oracle is putting money behind a model where AI competitiveness depends on fabric quality as much as compute quantity. Its public infrastructure messaging points to a few design priorities:

Design priority	Why it matters
Very large GPU cluster scale	Failure domains, oversubscription, and congestion behavior become architecture decisions
RoCEv2 transport	You need intentional loss management, not generic “fast Ethernet” assumptions
High-bandwidth cluster network	East-west design starts dominating outcomes for training and distributed inference
NIC/offload emphasis	Host-edge behavior matters almost as much as switch behavior
Separation of front-end and back-end traffic	User/API traffic and GPU-cluster traffic should not compete for the same operational assumptions

This is one of the clearest signs that the network is moving from cost center to constraint solver.

If the fabric performs well, expensive accelerators stay busy.
If the fabric performs badly, the GPUs wait, jobs stretch, and the whole capex story gets harder to defend.

Why RoCEv2 changes the engineering problem

RoCEv2 is attractive because it brings RDMA semantics onto Ethernet and IP-based infrastructure. That gives operators a familiar ecosystem and better integration with existing data center practices than a fully separate transport stack.

But it also raises the bar for fabric discipline.

A RoCEv2 environment does not magically behave like a perfect lossless network. You have to design for it.

The real engineering work is in the ugly details:

1. ECN and PFC are design choices, not defaults

PFC can help suppress drops for sensitive traffic classes, but it can also widen blast radius if the pause domain is too broad or the topology is sloppy.

ECN can signal congestion before things fall apart, but only if queue thresholds and telemetry are configured intelligently.

In other words, the question is not “do we support RoCEv2?”

The question is “can we keep RoCEv2 predictable at scale?”

2. Average utilization is a weak metric

AI fabrics punish teams that only look at interface averages.

The useful signals are things like:

queue buildup
latency spread, not just median latency
retransmissions and retries
NIC-level counters
pressure around hot spots during synchronized workloads

A link can look healthy in a dashboard while the training job above it is already losing efficiency.

3. The host edge matters

Once you are dealing with ConnectX-class NICs, offload behavior, and AI-optimized hosts, the edge is no longer just a server team problem.

The network outcome is shaped jointly by:

switch buffering and queue policy
NIC behavior
offload settings
optics and physical layer quality
workload placement

The cleanest leaf-spine diagram in the world will not save a badly tuned host edge.

The practical architecture lesson

A lot of teams still draw AI infrastructure as “some GPUs attached to a fast spine.” That mental model is already outdated.

A better model is to treat the environment as two different networks sharing one business outcome:

Front-end network

This is where API traffic, user access, storage access, service integration, and platform control traffic live.

Back-end cluster network

This is where the expensive part happens: node-to-node traffic, collective operations, checkpoint movement, and all the east-west behavior that determines whether the cluster performs like a product or a science project.

Once you separate those mentally, several design rules get clearer:

isolate traffic classes aggressively
design congestion containment on purpose
think about optics and thermals early
instrument the host edge, not just the switching layer
validate under realistic synchronized load

That is also why AI networking keeps pulling data center engineering closer to systems design and performance engineering.

What network teams should do this quarter

You do not need an Oracle-sized budget to take the lesson seriously.

If your team is anywhere near GPU infrastructure, these are good next moves:

1. Review one RoCEv2 design end to end

Do not stop at topology. Walk the queues, congestion policy, traffic classes, and failure domains.

2. Split front-end and back-end diagrams

If both traffic types still live in the same fuzzy architecture box, fix that first.

3. Add queue and latency telemetry to your standard view

Throughput graphs are not enough for AI fabrics.

4. Revisit optics assumptions

At dense 400G and 800G scale, physical-layer details turn into application performance issues quickly.

5. Learn to explain fabric behavior in business terms

GPU utilization, job completion time, and cluster efficiency are the language executives will care about. That translation layer is increasingly part of the engineer’s job.

The broader takeaway

Oracle is not the only company making this shift. It is just making the shift loudly.

Across hyperscalers, AI clouds, and modern data center platforms, the pattern is the same:

more money into east-west fabrics
more emphasis on NICs and offload
more sensitivity to congestion behavior
more pressure on network teams to think like performance engineers

For years, networking teams had to argue that the fabric mattered.

Now the market is doing that for them.

If a company is willing to reorganize billions of dollars around GPU infrastructure, then the fabric carrying those workloads is no longer plumbing. It is strategy.

Canonical version: https://firstpasslab.com/blog/2026-04-08-oracle-layoffs-ai-data-center-networking-impact/

AI disclosure: This Dev.to article was adapted with AI assistance from the original FirstPassLab article, with editorial restructuring for the Dev.to engineering audience.

Google Bought Wiz for $32B. Here's Why Cloud Network Engineers Should Care

FirstPassLab — Sun, 12 Apr 2026 22:54:05 +0000

Google didn't just buy a security vendor, it bought an API-level map of how multi-cloud environments are actually exposed.

For infrastructure teams, the important part of the Wiz deal is not just the $32B headline. It's that CNAPP has moved into the same design conversation as VPCs, route tables, IAM boundaries, Kubernetes networking, and cloud misconfiguration management. If you operate AWS, Azure, or GCP at scale, this is network engineering work with a security hat on.

Key takeaway: The Google-Wiz deal pushes cloud security posture management closer to the infrastructure layer. Engineers who can reason about cloud networking, identity, and exposure paths together will have a much stronger edge than teams that still treat them as separate domains.

What Did Google Actually Buy With Wiz?

Wiz is a Cloud-Native Application Protection Platform (CNAPP) that provides agentless security scanning across multi-cloud environments. Founded in 2020 by Assaf Rappaport and team (who previously sold Adallom to Microsoft), Wiz grew to over $500 million in annual recurring revenue in under four years — making it one of the fastest-growing enterprise software companies ever.

According to Forrester's analysis, the $32 billion price tag surpasses Cisco's $28 billion Splunk acquisition in 2024 as the largest cybersecurity deal on record.

Here's what Wiz actually does that matters to network engineers:

Wiz Capability	What It Does	Network Engineering Relevance
Cloud Security Posture Management (CSPM)	Continuously scans cloud configs for misconfigurations	Catches open security groups, overly permissive NACLs, public-facing resources you didn't intend
Cloud Workload Protection (CWPP)	Detects vulnerabilities in running workloads	Identifies exposed services across VPC/VNet boundaries
Network Exposure Analysis	Maps cloud network paths and identifies reachable resources	Shows which resources are internet-facing through actual network path analysis, not just security group rules
Cloud Infrastructure Entitlement Management (CIEM)	Maps IAM permissions and identifies excessive access	Reveals service accounts that can modify network configurations
Kubernetes Security Posture (KSPM)	Secures Kubernetes clusters and container networks	Flags CNI misconfigurations, exposed services, and network policy gaps

The critical differentiator: Wiz is agentless. It connects via cloud APIs and scans your entire environment without deploying software to every workload. For network engineers who've fought the battle of getting agents deployed and maintained on thousands of endpoints, this architecture is significant.

Why Is This the Largest Cybersecurity Deal in History?

The $32 billion price tag reflects the reality that cloud security has become the most critical — and most fragmented — part of enterprise security. According to Google's announcement, Google Cloud CEO Thomas Kurian framed the acquisition as making "security a catalyst for innovation, not a barrier."

Several factors drove the price:

Market timing. Cloud misconfigurations are the leading cause of cloud security incidents, responsible for approximately 80% of breaches according to Gartner. Every enterprise migrating to cloud needs CSPM, and most have inadequate tooling.

Multi-cloud reality. According to CRN's reporting, Wiz will continue supporting AWS, Azure, and Oracle Cloud after the acquisition. This is crucial — Google is buying a tool that monitors competitors' clouds. Rappaport stated: "We remain committed to our open approach, ensuring Wiz continues to support all major cloud and code environments."

AI security. The combined Google Cloud + Wiz platform will detect threats created using AI models, protect against threats to AI models, and use AI to help security professionals hunt threats. As AI workloads explode across cloud infrastructure, securing them becomes a hyperscaler-scale problem.

Competitive positioning. Google Cloud trails AWS and Azure in market share. Embedding best-in-class security directly into the platform is a differentiation play — GCP becomes the cloud with built-in Wiz.

How Does This Change Multi-Cloud Security for Network Engineers?

If you manage network infrastructure across AWS VPC, Azure vWAN, or GCP NCC, the Google-Wiz acquisition changes your security toolchain dynamics in three ways.

1. Cloud Security Posture Becomes a Network Team Responsibility

Traditionally, cloud security posture management lived with the security team or DevSecOps. But CNAPP platforms like Wiz analyze network exposure — which security groups allow traffic, which resources are internet-reachable, which VPC peering connections create unintended lateral movement paths.

This is network engineering work wearing a security hat. Here's what a CNAPP network exposure finding looks like in practice:

Finding: RDS instance db-prod-users is reachable from the internet
Path:  Internet → IGW → Public Subnet SG (port 3306 open) → RDS
Risk:  Critical — database directly exposed via misconfigured security group
Fix:   Remove 0.0.0.0/0 ingress rule on sg-0a1b2c3d, add private subnet route

Network engineers already understand routing, subnets, and access control. CNAPP just surfaces the misconfigurations you'd find during a manual audit — but continuously and at scale.

2. Google Cloud Gets a Competitive Security Advantage

The hyperscaler security landscape before and after the acquisition:

Hyperscaler	Native Security Platform	CNAPP Integration	Network Security
AWS	Security Hub + GuardDuty + Inspector	Third-party CNAPP (CrowdStrike, Palo Alto)	VPC Flow Logs, Network Firewall, WAF
Azure	Defender for Cloud + Sentinel	Partially integrated CSPM	NSG Flow Logs, Azure Firewall, Front Door
GCP (post-Wiz)	Security Command Center + Wiz CNAPP	First-party CNAPP	VPC Flow Logs, Cloud Armor, Cloud IDS
Oracle Cloud	Cloud Guard	Third-party	NSG, Web Application Firewall

GCP is now the only hyperscaler with a first-party, enterprise-grade CNAPP built into the platform. For network engineers evaluating cloud platforms, this changes the security assessment matrix. GCP's native security tooling jumps from "adequate" to "best-in-class" overnight.

3. Multi-Cloud Security Gets More Complex, Not Simpler

Here's the paradox: Wiz promises to remain multi-cloud, but it's now owned by a competitor. If you run a multi-cloud environment with AWS as primary and GCP secondary, you're now sending your AWS network topology data through a Google-owned security scanner.

According to SDxCentral's analysis, this acquisition "formalizes a trend that has been building across the cloud workload security market: hyperscalers increasingly want tighter control over the security stack around their platforms."

For network engineers managing multi-cloud connectivity, the practical implication is clear: evaluate whether your organization is comfortable with Google-owned tooling scanning non-Google infrastructure. If not, alternatives like CrowdStrike Falcon Cloud Security, Palo Alto Prisma Cloud, and Orca Security still offer independent multi-cloud CNAPP.

What Is CNAPP and How Does It Differ From Traditional Network Security?

CNAPP consolidates capabilities that network engineers previously handled with separate tools. According to Wiz's documentation, a CNAPP platform unifies:

CSPM (Cloud Security Posture Management) — continuous compliance and misconfiguration detection
CWPP (Cloud Workload Protection Platform) — vulnerability scanning for running workloads
CIEM (Cloud Infrastructure Entitlement Management) — identity and access control analysis
KSPM (Kubernetes Security Posture Management) — container and Kubernetes security
CDR (Cloud Detection and Response) — real-time threat detection

For comparison with traditional network security tools:

Traditional Network Security	Cloud-Native Equivalent (CNAPP)
Firewall rules audit	Security group / NACL posture check
Vulnerability scanner (Nessus)	Agentless workload scanning
Network access control (Cisco ISE)	Cloud IAM entitlement analysis
SIEM correlation	Cloud detection and response
Penetration test / network path analysis	Automated network exposure analysis

The key difference: CNAPP operates at API level, not packet level. It doesn't inspect traffic — it reads cloud configurations and maps exposure. This is a fundamentally different security model from the perimeter-based approach that most network engineers trained on.

For teams building zero-trust cloud architectures, understanding CNAPP is increasingly relevant. These platforms turn architecture principles into operational controls across cloud networking, identity, workload posture, and exposure analysis.

What Skills Should Network Engineers Develop?

The Google-Wiz deal accelerates the convergence of networking and cloud security. Network engineers who position themselves at this intersection will capture the highest-value roles. Here's what to focus on:

Cloud Security Posture Management (CSPM)

Learn to read and interpret cloud security posture reports. Understand the relationship between VPC architecture, security groups, NACLs, and actual network exposure. This is the cloud equivalent of understanding firewall rule ordering and NAT traversal.

Infrastructure as Code (IaC) Security

Wiz and similar CNAPP platforms scan Terraform, CloudFormation, and Pulumi templates for security misconfigurations before deployment. Network engineers who can write secure IaC templates are worth more than those who fix misconfigurations after deployment.

Multi-Cloud Network Architecture

The ability to design network architectures that are secure across AWS, Azure, and GCP simultaneously is rare and high-value. Understanding each cloud's native network security controls — and how they interact with CNAPP scanning — is the sweet spot. Our multi-cloud networking comparison covers the networking fundamentals.

Cloud-Native Identity and Access Management

Network engineers traditionally think in terms of IP addresses and ports. Cloud security thinks in terms of identities and permissions. Learning IAM policy analysis — understanding which service accounts can modify route tables, create peering connections, or open security groups — bridges the gap.

What Does This Mean for the Cloud Security Market?

The $32 billion price tag validates cloud security as a foundational market, not a niche. Here's the competitive landscape post-acquisition:

Company	CNAPP Approach	Multi-Cloud	Acquisition Status
Wiz (Google)	Agentless, graph-based	AWS, Azure, GCP, OCI	Acquired ($32B)
CrowdStrike	Agent + agentless hybrid	AWS, Azure, GCP	Independent
Palo Alto (Prisma Cloud)	Agent-based, code-to-cloud	AWS, Azure, GCP, OCI	Independent
Orca Security	Agentless, SideScanning	AWS, Azure, GCP, Alibaba	Independent
Microsoft Defender for Cloud	Native Azure + multi-cloud	Azure-first, AWS/GCP supported	Hyperscaler-owned
Check Point CloudGuard	Agent-based, integrates with Wiz	AWS, Azure, GCP	Independent (Wiz integration)

The acquisition creates pressure on AWS and Azure to either build or buy comparable CNAPP capabilities. AWS has been incrementally enhancing Security Hub, and Microsoft has Defender for Cloud, but neither matches Wiz's depth in agentless multi-cloud scanning.

For network engineers, this consolidation means cloud security tooling will increasingly be bundled with cloud infrastructure — similar to how SD-WAN security features got absorbed into SASE platforms. Understanding the native security capabilities of each cloud becomes as important as understanding their networking primitives.

How Does the Regulatory Approval Process Affect You?

The deal took a full year to close, from announcement in March 2025 to completion on March 11, 2026. The EU specifically evaluated whether the acquisition would reduce competition in cloud security.

According to CRN's reporting, Google faced a $3.2 billion breakup fee if the deal fell through. The EU ultimately approved it, concluding that customers had "credible alternatives" in cloud security.

The practical takeaway: if your organization uses Wiz today, expect integration changes over the next 12-18 months. Wiz's roadmap will increasingly prioritize GCP-native integrations while maintaining multi-cloud support. If you're selecting a CNAPP vendor now, factor in the Google ownership when evaluating long-term vendor independence.

Frequently Asked Questions

How much did Google pay for Wiz?

Google paid $32 billion in cash for Wiz, making it the largest cybersecurity acquisition in history and Google's biggest acquisition ever. The deal surpasses Cisco's $28 billion Splunk acquisition in 2024. It was announced in March 2025 and closed on March 11, 2026 after EU regulatory approval.

Will Wiz still support AWS and Azure after the Google acquisition?

Yes. Wiz CEO Assaf Rappaport confirmed the platform will maintain its multi-cloud commitment, continuing to support AWS, Azure, GCP, and Oracle Cloud. Google Cloud CEO Thomas Kurian emphasized the company's "commitment to openness." However, expect deeper GCP integrations to develop over time.

What is CNAPP and why should network engineers care?

CNAPP (Cloud-Native Application Protection Platform) unifies cloud security posture management (CSPM), workload protection (CWPP), identity entitlement management (CIEM), and network exposure analysis in a single platform. For network engineers, CNAPP replaces fragmented security tools with unified visibility across cloud networks — and network exposure analysis is fundamentally a networking discipline.

How does the Google-Wiz deal affect network and platform teams?

Cloud security posture management is increasingly part of day-to-day work in hybrid and multi-cloud roles. Understanding CNAPP capabilities, cloud network exposure analysis, IaC security, and multi-cloud architecture helps network, platform, and security teams operate from the same map instead of separate tool silos.

AI disclosure: This Dev.to version was adapted with AI assistance from FirstPassLab source material and reviewed before publication. Original canonical article: https://firstpasslab.com/blog/2026-03-12-google-wiz-32b-acquisition-cloud-network-security-engineer-guide/

Cisco SD-WAN Is Under Active Attack: 3 Exploited Catalyst Manager CVEs and the Patch Plan

FirstPassLab — Sun, 12 Apr 2026 16:53:49 +0000

If you run Cisco Catalyst SD-WAN Manager, this is a patch-now situation.

Cisco has now confirmed that three SD-WAN vulnerabilities are being actively exploited in the wild, and the important detail is that attackers are chaining bugs together, not just using the headline CVSS 10.0 issue. That means a "medium" or "high" score on its own is not a comfort signal here.

In this post, I’ll break down the attack chain, the affected releases, the fixed versions, and the hardening steps worth doing before your next maintenance window.

TL;DR

3 Cisco SD-WAN CVEs are now confirmed exploited in the wild

Attackers are chaining auth bypass, credential exposure, and file overwrite bugs

There are no workarounds that fully fix this, patching is the answer

If your SD-WAN control plane was internet exposed, assume higher risk and investigate for compromise

What happened

The timeline moved fast:

February 25, 2026: Cisco shipped patches for five Catalyst SD-WAN Manager vulnerabilities and disclosed that CVE-2026-20127 was already being exploited as a zero day.
February 25, 2026: CISA issued Emergency Directive ED 26-03 telling federal agencies to patch immediately.
March 5, 2026: Cisco updated the advisory and confirmed that CVE-2026-20128 and CVE-2026-20122 were also being exploited in the wild.

So this stopped being a single-bug story very quickly. It is a campaign against SD-WAN management infrastructure.

The five SD-WAN vulnerabilities at a glance

CVE	Severity	CVSS	Description	Exploited?
CVE-2026-20129	Critical	9.8	API authentication bypass leading to netadmin access	Not yet confirmed
CVE-2026-20126	High	7.8	REST API privilege escalation to root	Not yet confirmed
CVE-2026-20133	High	7.5	Information disclosure via filesystem access	Not yet confirmed
CVE-2026-20122	High	7.1	Arbitrary file overwrite via API leading to vManage privileges	Yes
CVE-2026-20128	Medium	5.5	DCA credential exposure that enables lateral movement	Yes

One of the useful reminders here is that attackers do not care about CVSS in isolation. They care about whether one flaw unlocks the next one.

A medium-severity credential leak becomes a serious incident if it gives an attacker a clean path to move across the SD-WAN control plane.

How the attack chains work

Based on Cisco Talos reporting and Cisco’s advisory updates, there are two important chains to understand.

Chain 1: the original zero-day path

1. Find an internet-exposed SD-WAN Manager or Controller
2. Exploit CVE-2026-20127 (authentication bypass)
3. Chain with an older privilege-escalation bug
4. Escalate to root
5. Modify scripts or services for persistence
6. Maintain access to the control plane

Chain 2: the newer March 2026 path

1. Exploit CVE-2026-20128 (DCA credential exposure)
2. Reuse those credentials against other SD-WAN nodes
3. Exploit CVE-2026-20122 (arbitrary file overwrite)
4. Gain vManage-level access
5. Potentially chain again for higher privileges

That is why patching only the loudest bug is not enough. The real risk is the kill chain.

Who is behind it

Cisco Talos tracks the actor exploiting the original zero-day as UAT-8616.

What matters operationally:

They appear to have targeted SD-WAN infrastructure for an extended period
They focus on control-plane compromise, not just one-off access
They have used persistence techniques, including modifying system scripts
Reporting indicates they may also downgrade software to reintroduce known-vulnerable states

That last point is especially nasty because it means version drift and software integrity suddenly matter a lot more than teams often assume.

What to do right now

1. Check your version

On vManage:

vmanage# show version

If you are not on a fixed release, you have work to do.

2. Upgrade to a fixed release

Current train	Fixed release
20.9.x	20.9.8.2
20.12.5 / 20.12.6	20.12.5.3 or 20.12.6.1
20.13 / 20.14 / 20.15	20.15.4.2
20.16 / 20.18	20.18.2.1

If you are on something older than 20.9, plan a supported upgrade path first.

3. Harden while you patch

These are the practical steps I would treat as baseline:

Block direct internet access to SD-WAN Manager and Controller whenever possible
If exposure is unavoidable, restrict access to known source IPs only
Disable HTTP on the web UI and use HTTPS only
Put management components behind a firewall with tight filtering
Ship logs to an external SIEM because local logs may not be trustworthy after compromise
Rotate admin credentials and verify role-based access assignments
Monitor for unauthorized software downgrades

4. Check for compromise, not just exposure

If your control plane was internet exposed at any point, I would assume elevated risk and validate:

Unusual API authentication events
Unexpected local or admin accounts
Script or service modifications on vManage/vSmart nodes
Unplanned configuration changes in the fabric
DCA-related access patterns that do not match normal operations

Why SD-WAN control planes are such attractive targets

Compromising a branch router is bad.

Compromising the management and policy layer of an SD-WAN fabric is much worse.

An attacker with control-plane access can potentially influence:

routing policy
traffic engineering
segmentation behavior
controller trust relationships
security policy distribution

That is why these vulnerabilities matter beyond patch management. They are a reminder that the SD-WAN controller stack should be protected like a crown-jewel system, not managed like a regular internal app.

Engineering lessons worth carrying forward

A few things this incident reinforces:

Management planes need zero-trust thinking too.
If your controller is reachable from too many places, you are giving attackers a simpler first hop.
CVSS is not enough for prioritization.
A medium bug that exposes credentials can outrank a higher-severity bug if it fits a live chain.
External logging is mandatory for critical control planes.
If local telemetry can be tampered with, your incident response starts blind.
Version integrity matters.
Track unexpected downgrades, not just upgrades.
Patching windows for management infrastructure should be shorter.
The blast radius is too large to treat SD-WAN control components like low-priority admin systems.

References

Cisco security advisory: https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-sdwan-authbp-qwCX8D4v
Cisco SD-WAN upgrade matrix: https://www.cisco.com/c/dam/en/us/td/docs/Website/enterprise/catalyst-sdwan-upgrade-matrix/index.html
CISA advisory context: https://www.cisecurity.org/advisory/multiple-vulnerabilities-in-cisco-catalyst-sd-wan-products-could-allow-for-authentication-bypass_2026-016
SecurityWeek coverage: https://www.securityweek.com/cisco-warns-of-more-catalyst-sd-wan-flaws-exploited-in-the-wild/

If you want the original FirstPassLab version with canonical attribution, it’s here:
https://firstpasslab.com/blog/2026-03-05-cisco-sdwan-more-flaws-exploited-wild-patch-now/

AI disclosure: This article was adapted with AI assistance from an original FirstPassLab article and reviewed before publication.

Zero Trust Is Killing the Perimeter Playbook, Not Network Security Engineering

FirstPassLab — Sat, 11 Apr 2026 22:54:17 +0000

If you still treat the firewall as the center of your security architecture, you are already behind.

Zero trust is not killing network security engineering. It is killing the old perimeter-first playbook: static ACLs, VPN-only remote access, and segmentation models that depend on where a device happens to land. The teams getting ahead are shifting toward identity, posture, micro-segmentation, and automation.

In other words, the valuable skills are moving up the stack, not disappearing.

Why the perimeter model is breaking down

The old model assumed a clean boundary between inside and outside. That assumption is hard to defend in 2026 for three reasons.

1. Remote and hybrid work made “inside” fuzzy

Users now connect from home networks, unmanaged Wi-Fi, and temporary workspaces. Trusting traffic because it came through a VPN tunnel is much weaker than validating who the user is, what device they are on, and whether it still meets policy.

2. Cloud moved the critical assets

When apps, APIs, and data live across AWS, Azure, GCP, and SaaS platforms, the firewall is no longer sitting in front of the crown jewels. A lot of the real control points are now identity systems, policy engines, and service-to-service trust boundaries.

3. Attackers care about lateral movement

Perimeter controls might stop some initial access, but they do very little once an attacker lands somewhere legitimate. The practical zero trust question is not “did they get in?” It is “what can they reach next?”

That shift changes what network and security engineers need to be good at.

The skills that are losing value fastest

These are still useful in brownfield environments, and you still need them to operate legacy networks. But they are no longer enough.

Static ACL thinking

Permit and deny lists tied to subnets and VLANs do not express user identity, device trust, risk, or application context very well. They are still part of the toolbox, but not the architecture.

VPN as the primary remote access model

Traditional VPN remains important for some use cases, especially admin access and site-to-site connectivity. But for workforce access to internal apps, the center of gravity is moving toward ZTNA and application-aware access controls.

Segmentation based only on topology

If your policy depends mostly on a device being in the “right VLAN,” you have a brittle model. Modern environments need segmentation that follows users, workloads, and device state.

The skills that matter more now

This is where the opportunity is. Zero trust increases the value of engineers who can connect network controls, security controls, and automation.

Identity-driven access control

Identity is becoming the first policy primitive.

That includes:

802.1X and NAC design
posture assessment
device profiling
conditional authorization
integration with identity providers and MFA systems

For Cisco-heavy shops, this usually means understanding ISE deeply enough to design policy, troubleshoot edge cases, and explain where it fits and where it does not.

A useful mental model is this:

Zero trust principle	What engineers actually build
Verify explicitly	802.1X, posture, MFA, certificate-based access
Least privilege	role-based access, dACLs, SGTs, app-specific policy
Assume breach	containment, limited east-west access, rapid quarantine
Continuous evaluation	posture rechecks, adaptive policy, telemetry-driven response

Micro-segmentation

This is the part many network teams underestimate.

Micro-segmentation is how you make “assume breach” real. Once a user or endpoint is authenticated, the system still needs to limit where it can move. In Cisco environments that often means Security Group Tags and TrustSec-style policy. In cloud and hybrid environments it may mean workload identity, service policy, and host-based enforcement.

The important design shift is that segmentation follows identity and context, not just IP addressing.

Detection and response, not just prevention

Firewalls do not go away in zero trust, but their role changes. They become one enforcement point among several.

The engineers who stand out are the ones who can connect signals across systems, for example:

NAC or identity context
endpoint posture or EDR alerts
firewall telemetry
DNS or proxy activity
automated quarantine workflows

That is much closer to security engineering than to traditional “box-by-box firewall administration.”

Security automation

Manual policy changes do not scale when access decisions depend on users, device health, application sensitivity, and environment state.

This is why automation matters more, not less:

pushing NAC and policy changes through APIs
automating quarantine or exception workflows
validating segmentation changes before rollout
keeping policy consistent across campus, branch, data center, and cloud

If you can bridge identity, segmentation, and automation, you are much harder to replace than someone who only manages perimeter rules.

An important reality check: NAC is not full zero trust

A lot of teams overstate what NAC platforms can do.

Tools like Cisco ISE are valuable because they provide strong building blocks: authentication, profiling, posture, policy, and segmentation hooks. But they are not the entire zero trust architecture. You still need application-aware access, cloud-native controls, telemetry, response workflows, and sane operational design.

That nuance matters. The best engineers are not the ones claiming a single platform solved zero trust. They are the ones who know exactly where each control starts and stops.

A practical migration map for engineers

If you are deciding what to learn next, here is the rough shift.

Older emphasis	Higher-value replacement
static subnet ACLs	identity-aware policy and dynamic authorization
VLAN-only segmentation	micro-segmentation tied to user, device, or workload context
VPN-first user access	ZTNA-style app access plus stronger identity controls
manual firewall workflows	API-driven policy and response automation
perimeter trust assumptions	continuous verification and limited blast radius

That does not mean you throw away firewall, routing, or switching knowledge. It means those fundamentals now support a more identity-centric architecture.

What this means for network security engineers in 2026

The market is rewarding engineers who can answer questions like these:

How do we enforce least privilege after successful authentication?
How do we quarantine a compromised endpoint automatically?
How do we stop east-west movement without redesigning the whole network?
How do we keep access policy consistent across campus, branch, and cloud?
How do we prove that the policy is doing what we think it is doing?

Those are architecture and operations questions, not just certification questions.

If you already know routing, switching, VPNs, and firewall behavior, you are not starting over. You are adding the controls that make those foundations relevant in a zero trust world.

Bottom line

Zero trust is not making network security engineers obsolete. It is raising the bar.

The skills losing value are the ones built around static trust and perimeter assumptions. The skills gaining value are identity, posture, micro-segmentation, response, and automation.

That is a good trade if you like real engineering work.

More depth on the original write-up is available at FirstPassLab.

AI disclosure: This article was adapted from a canonical FirstPassLab post with AI assistance for Dev.to formatting and audience fit. The underlying ideas, structure, and source material came from the original article.

Your GPUs Aren’t the Bottleneck, Model Delivery Is: Fixing AI Distribution on Kubernetes

FirstPassLab — Sat, 11 Apr 2026 16:54:09 +0000

Most AI infra postmortems still blame GPU shortages. In practice, a lot of the pain shows up earlier: giant model pulls, cold-start storms, registry hotspots, bad placement, and east-west congestion during scale-out.

If your platform is serving 140 GB to 1 TB model artifacts, you are not just running Kubernetes with accelerators anymore. You are operating a distributed delivery system where artifact movement and locality are part of the network design.

Key takeaway: for many teams, the real AI bottleneck is not compute capacity. It is repeatable model delivery, topology-aware placement, and predictable transport behavior under bursty inference demand.

Why are AI models exposing a network infrastructure gap?

AI models expose a network infrastructure gap because model artifacts are now large enough to behave like distributed storage workloads, not normal application releases. According to the CNCF blog "The weight of AI models" (2026), a quantized LLaMA-3 70B model weighs about 140 GB, while frontier multimodal models can exceed 1 TB. That changes the failure mode. Instead of pulling a few container images during a controlled rollout, teams now stampede registries, object stores, and east-west links when inference pools scale out. The result is congestion, long-tail latency, cold-start delays, and inconsistent placement across GPU nodes. For network engineers, this looks less like classic web scaling and more like a storage, transport, and locality problem wrapped inside Kubernetes.

The March 27 CNCF post makes the core point clearly: most enterprises already run AI infrastructure on Kubernetes, but model artifact management still lags behind software artifact management. Containers already get versioning, rollback, security scanning, and immutable delivery through OCI registries. Model weights are still too often copied with scripts, pushed into generic buckets, or mounted from shared filesystems. That gap is exactly where infrastructure breaks first.

Characteristic	Traditional app rollout	AI model rollout
Artifact size	Usually MB to low-GB images	140 GB to 1 TB+ model artifacts
Burst pattern	Planned CI/CD release windows	Sudden scale-out under inference demand
Primary risk	Slow image pull	Cache miss storms, hotspotting, cold starts
Best mitigation	More replicas, smaller images	Preheating, P2P distribution, placement locality

What did CNCF’s 2026 data reveal about AI deployment maturity?

CNCF’s 2026 data revealed that enterprise AI demand is real, but the supporting infrastructure is still immature. According to the CNCF Annual Cloud Native Survey (2026), 66% of organizations use Kubernetes for generative AI workloads and 82% of container users run Kubernetes in production, so the orchestration layer is no longer the blocker. The bigger warning is operational maturity: 47% of organizations deploy AI models only occasionally, only 7% deploy daily, and 52% do not train models at all. In other words, most organizations are consumers of AI, not builders of frontier models, and even they still struggle to deliver inference reliably. That is why the network discussion has shifted from peak bandwidth to repeatable deployment mechanics.

The same survey says 37% of organizations use managed APIs, 25% self-host models, and 13% already push AI to the edge. That mix matters for network design. Managed APIs reduce local GPU pressure but increase dependency on WAN resilience and cost controls. Self-hosting increases demand for high-throughput storage, regional artifact replication, and predictable fabric performance. Edge inference introduces another layer of locality, caching, and policy complexity.

CNCF metric	What it means	Why network engineers should care
66% use Kubernetes for GenAI	Kubernetes is the default AI platform	Cluster networking is now part of AI delivery
47% deploy only occasionally	Most teams have immature pipelines	Cold starts and scale events stay painful
7% deploy daily	Very few have production-grade automation	Reliable rollout mechanics are now a competitive edge
52% do not train models	Most teams are inference consumers	Model serving and distribution matter more than training clusters
82% run Kubernetes in prod	Core platform is mature	The lag is above the orchestrator, in delivery and operations

This also explains why the CNCF survey says the gap between AI ambition and infrastructure reality is stark. The story is not “companies need more GPUs.” The story is that they need the boring infrastructure around GPUs, including registries, caches, CI/CD, observability, and disciplined rollout workflows.

Which parts of the stack are actually lagging: storage, scheduling, or delivery?

All three are lagging, but delivery is the hidden bottleneck because it connects storage, scheduling, and network behavior into one failure domain. According to the CNCF March 27 post (2026), model weights are still often managed with ad hoc downloads, unsecured shared filesystems, or generic object storage. According to the CNCF Cloud Native AI White Paper, AI serving also needs right-sized GPU allocation, evolving Dynamic Resource Allocation, and model-sharing formats that reduce unnecessary pulls. Then the March 26 CNCF post adds the control-plane view: DRA, the Inference Gateway, OpenTelemetry, Kueue, and GitOps patterns are finally giving teams tools to make AI workloads behave like first-class infrastructure. The problem is that many enterprises have not yet connected those pieces into one operational system.

The most practical architecture in the CNCF material is simple and powerful: package models as OCI artifacts, store them in Harbor or another registry, distribute them with Dragonfly, and mount them close to the inference engine instead of redownloading them for every scale event. According to the CNCF blog (2026), Dragonfly’s P2P distribution can use 70% to 80% of each node’s bandwidth and reduce long-tail hotspots during large-scale model rollout. That is a real network optimization, not marketing language.

modctl modelfile generate .
modctl build -t harbor.registry.com/models/qwen2.5-0.5b:v1 -f Modelfile .
modctl push harbor.registry.com/models/qwen2.5-0.5b:v1

That workflow matters because it turns models into managed artifacts instead of “big files somewhere.” It also aligns with newer Kubernetes mechanisms such as Dynamic Resource Allocation and the Gateway API Inference Extension, which help teams place workloads more intelligently and route inference traffic with higher utilization.

Lagging layer	Current bad habit	Better pattern
Artifact storage	Buckets and shell scripts	OCI registries with metadata and versioning
Scheduling	Generic pod placement	GPU-aware, topology-aware placement with DRA/Kueue
Delivery	Every node pulls from origin	P2P distribution, preheating, local cache reuse
Observability	CPU and memory only	Tokens/sec, queue depth, time to first token, cache hit rate
Rollback	Manual model swaps	GitOps and immutable artifact references

How does this gap change hiring, architecture, and CCIE-level operations?

This gap changes the job market because AI infrastructure now rewards engineers who can connect data center networking, automation, and platform operations into one coherent system. According to the CNCF blog "The platform under the model" (2026), AI Engineering is about building reliable systems around models, not just tuning models themselves. That means low-latency serving, safe rollouts, GPU scheduling, governance, and observability all become infrastructure work. The same post notes that only 41% of professional AI developers identify as cloud native, which leaves a real skills gap between AI teams and infrastructure teams. That is where experienced network engineers can win. The person who understands locality, congestion, failure domains, and automated recovery is no longer supporting the AI team from the sidelines. They are part of the AI product path.

For architects, the implication is that GPU clusters are not standalone islands anymore. They need registry replication, east-west traffic planning, multi-zone failure modeling, token-aware autoscaling signals, and security controls around model access. For operators, the implication is that old SRE dashboards are incomplete. Prometheus and OpenTelemetry now need to sit beside inference metrics, cache hit rates, and queue depth. For CCIE-level engineers, especially those on the data center and automation side, this is the next obvious adjacency. If you can already think clearly about EVPN locality, traffic engineering, or pipeline-driven change control, you are closer to AI infrastructure than most headlines suggest.

Open source matters here too. According to CNCF (2026), portability and composability are central because organizations are spreading AI workloads across hyperscalers, GPU-focused providers, and on-prem environments. Proprietary AI services can hide complexity for a while, but they do not remove the underlying network behaviors. They just move them to a different fault domain.

What should network engineers do in the next 90 days?

Network engineers should spend the next 90 days building operational discipline around model movement, placement, and observability instead of chasing abstract AI hype. According to the CNCF survey (2026), only 7% of organizations deploy AI models daily, which means the field is still open for teams that can make AI delivery boring and reliable. According to the CNCF white paper, right-sizing resource allocation, fractional GPU use, and model-serving efficiency are still evolving, so early wins come from basic engineering hygiene. If your team can stop cache-miss storms, reduce cold-start time, and prove artifact lineage, you will already be ahead of much of the market.

Map the artifact path. Document where model weights live, how big they are, how they move between regions, and which links saturate during scale-out.
Add locality before adding bandwidth. Prefer node-local or zone-local caches and preheating before assuming bigger links are the only answer.
Treat placement as network design. Align GPU placement, failure zones, storage locality, and service routing so that hot models do not bounce across the fabric unnecessarily.
Measure AI-specific signals. Track time to first token, tokens per second, queue depth, cache hit rate, and model pull duration alongside packet loss and interface utilization.
Standardize immutable delivery. Move from bucket copies and shell scripts to OCI artifacts, GitOps references, and controlled rollbacks.
Run failure drills. Test what happens when a registry slows down, a zone fails, or 100 nodes request the same model at once.

Frequently Asked Questions

Why is network infrastructure lagging behind AI models?

Network infrastructure is lagging because model artifacts have grown into the hundreds of gigabytes or more while many teams still rely on ad hoc downloads, weak versioning, and generic autoscaling. According to CNCF (2026), the bottleneck is operational delivery, not just raw bandwidth.

Is Kubernetes ready for AI workloads in 2026?

Yes, but only with the right supporting stack. CNCF data shows strong Kubernetes adoption for AI, yet organizations still need GPU scheduling, model artifact management, caching, and inference routing to run reliably.

What matters more for inference, GPUs or networking?

Both matter, but networking often becomes the hidden limiter. Cache misses, model pulls, queue depth, and east-west traffic can delay startup and inflate latency even when GPU capacity exists.

What should CCIE-level engineers learn from this trend?

They should learn OCI artifact delivery, Kubernetes scheduling concepts, GPU fabric traffic patterns, and observability for token-driven workloads. AI systems now reward engineers who can connect infrastructure, networking, and automation.

AI disclosure: This article was adapted from a canonical FirstPassLab post using AI assistance for editing and Dev.to formatting. Technical claims, sources, and the canonical URL point to the original article.