Everyone’s talking about zero trust for users. For endpoints. For applications. And that’s great — that conversation needed to happen, and it’s finally happening at scale. But there’s a part of your infrastructure that most zero trust strategies quietly skip over. The part that, if compromised, doesn’t just give an attacker access to some of your environment. It gives them a remote control for all of it.
We’re talking about the management plane. And right now, for most organizations, it’s sitting outside the zero trust model entirely — trusted by default, verified by nobody, and worth more to an attacker than everything beneath it.
First, Some Architecture
Network infrastructure is typically described in three planes — and understanding how they relate to each other is what makes the security implications click.
The data plane is where your traffic lives. Packets moving between devices, users hitting applications, a laptop talking to a file server. This is what most security tools are focused on — firewalls, IDS/IPS, DLP, NAC. It’s the most visible layer and the one that gets the most attention.
The control plane is the intelligence layer. It doesn’t carry user traffic — it decides how that traffic should flow. Routing protocols, spanning tree, BGP, SDN controllers — these are control plane functions. The control plane programs the data plane. It’s the traffic cop that tells your infrastructure where packets should go and how the network should behave.
The management plane is the administrative access layer. SSH sessions to switches and routers, your hypervisor console, Intune, Active Directory, cloud management portals, TACACS+ — anything that lets humans configure and control the infrastructure itself. It’s the cockpit. It’s where you go to make things happen at scale.
Here’s why this matters from a security standpoint: these planes have a hierarchy. The management plane sits above the control plane, which sits above the data plane. Own the management plane, and you own the control plane by extension — you can rewrite routing logic, manipulate SDN controllers, and reconfigure BGP policies. Own the control plane, and the data plane does whatever you tell it. Your VLANs, your ACLs, your carefully designed segmentation — all of it becomes reconfigurable.
This is why the management plane is so catastrophic when compromised. It’s not just another attack surface. It’s the layer that controls all the other layers. When an admin logs into Intune, they can push policy to 200,000 devices simultaneously. When someone SSHs into your core switch with the right credentials, they can rewrite your ACLs. When an attacker reaches your hypervisor management console, your VLANs become a suggestion.
The management plane is where “I have a foothold” becomes “I own everything.”
Two Recent Breaches That Make This Painfully Concrete
The Mexico Government Hack: The AI-Assisted Climb
In late 2025, one person with two AI platforms breached nine Mexican government agencies over roughly six weeks. Not a nation-state team. Not an elite APT group. One operator. And what the forensic record reveals is a systematic climb toward the management layer.
Using Claude Code and OpenAI’s API as operational tools, the attacker moved from initial access on internet-facing servers, through credential harvesting, through lateral movement, until eventually gaining administrative control over Jalisco state’s entire virtualization infrastructure — a 13-node Nutanix cluster, both management consoles, and 37 of 38 database servers. Custom rootkits were deployed across 20 state agencies.
When you own the hypervisor management console, the VLANs underneath it stop mattering. You’re above the segmentation. You can reconfigure the virtual switching fabric directly.
There’s an instructive moment in the report where the attacker tried to lateralize through a municipal water utility and hit a wall. Patched systems. Proper configurations. The AI tried EternalBlue, credential sprays, PetitPotam, PrinterBug, LDAP anonymous bind — and failed at all of them. The report quotes Claude summarizing the failures as evidence of defensive quality. The attacker got almost nothing from that target and moved on.
Physics held. Good controls held. The climb stopped.
The Stryker Breach: Management Plane as the Target
In March 2026, Iran-linked hackers from a group called Handala did something that should be required reading for every IT and security leader: they didn’t exploit a zero-day. They didn’t deploy a single line of malicious code. They logged into Stryker’s Microsoft Intune environment with compromised admin credentials and issued remote wipe commands.
200,000 devices. 79 countries. Wiped.
No exotic attack chain. No malware. Just legitimate tools, doing exactly what they were designed to do — because the attackers had the keys.
This is “living off the land” at its most devastating. The management plane didn’t just become an attack vector. It became the weapon.
Here’s the part that should make you exhale slightly: Stryker’s connected medical devices — defibrillators, surgical systems, patient communication platforms — were untouched. Why? They operated on separate, segmented networks. The attackers had no path to them.
Segmentation held. The blast radius was enormous, but it had a boundary.
The Uncomfortable Question
After reading both of those, here’s what every security and IT leader should be sitting with:
What’s the single pane of glass in your environment where an authenticated admin can touch everything? What’s the platform where one compromised account isn’t a breach — it’s a detonation?
Almost every organization has one. Usually several. And the implicit assumption baked into most architectures is that the management plane is inherently trusted — that if you show up with valid admin credentials, you must be legitimate. There’s no layer asking whether this credential, from this device, at this time, behaving in this way, should actually be allowed to do this.
That assumption made sense in a world where sophisticated attacks required sophisticated attackers. It doesn’t hold anymore.
Why AI Changes the Calculus
The Mexico breach illustrates something important about the current threat environment: the skill gap between “person with malicious intent” and “person who can execute a sophisticated, targeted attack” is collapsing.
The attacker in that case was not an expert. He didn’t deeply understand the systems he was attacking. But with AI as an operational co-pilot, he could probe, adapt, escalate, and persist at a pace and scale that would have required a team of specialists just a few years ago. Over 400 custom attack scripts. Nearly 2,600 AI-generated intelligence reports on compromised servers. An AI that, when told “do everything,” ran through an entire escalation playbook autonomously.
An AI-assisted attacker is relentless. It doesn’t get bored. It doesn’t go home. It doesn’t make careless mistakes at 2am. It will keep working toward the management plane until it finds a path — or until it hits controls that genuinely block it.
The controls that blocked it in Jalisco’s water utility weren’t exotic. They were patched systems and proper configuration. The controls that could have saved Stryker weren’t exotic either. They were the same things we already know work — continuous verification, least-privilege access, anomaly detection on privileged accounts.
The difference is that those controls need to extend to the management plane specifically. Not just to users. Not just to endpoints. To the infrastructure control layer itself.
What Zero Trust for the Management Plane Actually Looks Like
This isn’t a new category of technology. It’s an extension of principles you’re probably already applying elsewhere:
Device administration authentication (TACACS+) — Every SSH session to a switch or router should require a verified identity, with command-level authorization enforced. Not just “you’re authenticated,” but “you’re authenticated, your device is compliant, and you’re authorized to run these specific commands and not those ones.” Centralized, logged, and tied to your identity infrastructure.
Continuous verification for privileged access — Admin credentials to your hypervisor console, your MDM platform, your cloud management interfaces should be subject to the same continuous verification posture as any other access. A valid credential from an anomalous device, location, or behavior pattern should trigger step-up authentication or be blocked entirely.
Network segmentation that includes the management plane itself — Your out-of-band management network should be genuinely isolated, not just logically separated from the same AD that an attacker might have already compromised. If domain admin gets you to your switch management interfaces, that’s not segmentation — that’s a shortcut.
Least-privilege on admin accounts — The admin who manages endpoint policies doesn’t need the same account that manages network infrastructure. Blast radius reduction applies to the management plane just as much as anywhere else.
None of this is theoretical. These are the same zero trust principles that are already well-understood for user access — applied one layer up in the stack, to the layer that controls everything beneath it.
The Stryker Medical Devices Are the Point
It’s worth returning to that detail about Stryker’s medical devices. In the middle of a catastrophic breach — 200,000 devices wiped across 79 countries — the defibrillators worked. The surgical systems worked. The patient communication platforms worked. Because someone, at some point, drew a hard line around those networks and said: there is no path from the corporate environment to these systems. And that decision held under attack conditions that took down almost everything else.
That’s not luck. That’s architecture. And it’s the same architecture that can protect your management plane — if you extend your zero trust thinking to include it. The VLAN still can’t be defied if the management interface itself is protected. Physics holds. But “protected” has to mean more than “it’s on an internal network.”
The next breach that makes headlines probably won’t involve a novel attack technique. It’ll involve someone who got admin credentials, reached a management plane that implicitly trusted them, and did exactly what that plane was designed to do. The question is whether your architecture has a hard line they can’t cross — or whether you’re hoping they won’t find the path.