Network Segmentation in AI Data Centers: 4 Lessons from the Purdue Model

By Jin Ho Kang · OT/ICS Security Consultant

Three decades ago, the engineers who designed factory-floor networks solved a problem that AI infrastructure teams are only now running into: how do you protect a system where downtime is catastrophically expensive, where one compromised node can cascade into a total failure, and where the fastest-performing architecture is also the hardest one to defend? Their answer was the Purdue Enterprise Reference Architecture, and the network segmentation discipline built on top of it is quietly becoming required reading for anyone securing GPU training clusters. Having spent years applying ISA/IEC 62443 and NIST CSF network segmentation frameworks to manufacturing plants, I find the parallel to today’s AI compute infrastructure hard to ignore — and it is starting to show up explicitly in how frontier AI labs describe the security engineers they want to hire, with recent postings for data center security roles naming “OT and IT networking” and “network segmentation” as core requirements rather than nice-to-haves.

Why AI Compute Infrastructure Needs OT-Style Network Segmentation

For most of its history, IT security has operated on an assumption that OT security never could: if something breaks, you patch it, reboot it, and move on. A GPU training cluster breaks that assumption in the same way a chemical reactor or a turbine control system does. A multi-week training run synchronizing tens of thousands of accelerators cannot tolerate an unplanned reboot any more than a continuous manufacturing line can tolerate an unplanned stop — the cost is not measured in support tickets but in lost compute-hours and corrupted checkpoints. That single constraint changes everything about how network segmentation has to be designed, because the conventional IT playbook of aggressive patching and frequent network changes is precisely what an availability-first environment cannot absorb.

The security research community has already been tracking a related pattern in industrial environments: as IT and OT networks converge, the resulting interdependencies create new lateral pathways that legacy perimeter models were never designed to stop, particularly through vendor remote-access tools and misconfigured boundary devices (IBM X-Force, 2025). AI data centers are converging in the same way — enterprise IT, MLOps tooling, third-party model APIs, and a physically isolated GPU fabric all now sit inside the same organizational network — and the lateral-movement risk that convergence creates is structurally identical to what OT security teams have spent two decades trying to contain through disciplined network segmentation. Without deliberate network segmentation, an AI data center inherits the same weakness the OT world learned about the hard way: a flat network is a fast network, right up until the moment it is also a fast way for an attacker to reach everything.

The Purdue Model in 60 Seconds: Levels 0–5 and the iDMZ

The Purdue Enterprise Reference Architecture organizes an industrial environment into a hierarchy of functional levels: field devices and sensors at the bottom, control systems and human-machine interfaces above that, manufacturing operations and historian systems in the middle, and business logistics and enterprise IT systems at the top (Purdue Enterprise Reference Architecture, Wikipedia; NIST SP 800-82 Rev. 3). Between the operations layer and the business layer sits a demilitarized zone — commonly called the industrial DMZ or iDMZ — whose only job is to prevent enterprise IT traffic from touching control-system traffic directly.

This hierarchy was never designed as a security model — it was originally an information-flow model for manufacturing enterprises — but the ISA-99 committee that later produced the IEC 62443 standard adopted the Purdue level structure directly as the conceptual foundation for its zone-and-conduit security architecture (Software Toolbox, 2026). NIST SP 800-82 Rev. 3 goes further and makes the network segmentation requirement explicit: it requires firewall rules that prevent Level 4 (business logistics) devices from communicating directly with Level 2, 1, or 0 devices, and recommends that outbound rules be made just as restrictive as inbound ones (SentinelOne, 2026). That single design rule — no direct path from the enterprise network to the process-control network — is the entire security value of the model, condensed into one network segmentation policy enforced at a single firewall.

Mapping GPU Clusters to Purdue Levels: Where the Analogy Holds and Where It Breaks

Overlay a modern AI data center’s network segmentation onto this hierarchy and the structure lines up more cleanly than most people expect. The GPU-to-GPU backend fabric — the InfiniBand or RoCE network carrying gradient synchronization traffic between accelerators — behaves like Level 0/1 field-device traffic: it is latency-sensitive, purpose-built, and has no business ever touching general-purpose IT traffic. The cluster orchestration layer (job schedulers, fabric managers) sits at roughly Level 2/3, supervising the physical layer without being part of it. Model registries, data pipelines, and internal MLOps tooling occupy a Level 3/4 position, and public-facing APIs and corporate IT sit at Level 5, exactly where enterprise systems have always sat.

Where the analogy strains is performance. A 1,000-GPU training cluster built from standard eight-GPU servers needs a non-blocking fabric that can sustain well over 400 terabits per second of all-to-all traffic with near-zero packet loss (The Network DNA, 2026), and InfiniBand fabrics are known to saturate once a cluster grows past roughly 512 to 1,024 nodes without moving to a hierarchical, multi-fabric topology (The Neural Base, 2026). Purdue-style field networks were built for slow, deterministic control loops measured in milliseconds; AI fabrics are built for microsecond-scale, all-to-all synchronization traffic that network segmentation was never originally designed to sit on top of. The lesson still transfers, though: the same tension OT engineers have negotiated for years between deterministic performance and defensible network segmentation is now the central design question for anyone architecting a GPU backend fabric, and it will only get sharper as fabric speeds move from today’s 400 Gb/s generation toward 800 Gb/s and beyond.

Zones and Conduits: What IEC 62443 Adds to AI Fabric Design

IEC 62443 formalizes Purdue’s hierarchy into two precise concepts for network segmentation: a zone is a group of assets that share a common set of security requirements, and a conduit is the communication channel between zones, which must be secured to the standard of the most sensitive zone it touches, not the least sensitive one (SentinelOne, 2026). That last clause is the part most IT-trained security teams get backwards when they first attempt network segmentation — a conduit connecting a low-trust zone to a high-trust zone inherits the high-trust zone’s requirements, never the reverse.

Applied to an AI data center, this suggests a deliberate network segmentation structure rather than the flat, trust-everything network many GPU clusters still run on today: a Training Fabric Zone for the isolated backend RDMA network, a Cluster Orchestration Zone for schedulers and fabric managers, a Data Ingestion Zone for training data pipelines, and an Enterprise IT Zone for corporate systems and public APIs. Every path between them becomes a named, monitored conduit rather than an open route — functionally the same compute-side iDMZ that has protected the boundary between Level 3 and Level 4 in manufacturing plants for over a decade, just relocated to protect the boundary between a training fabric and the corporate network that increasingly surrounds it. This is network segmentation with intent, not network segmentation as an afterthought bolted on after the fabric is already in production.

The Business Case: What Network Segmentation Actually Buys You

None of this is a theoretical exercise. IBM’s X-Force team recorded 670 vulnerabilities disclosed in the first half of 2025 alone that could affect OT-adjacent environments, with 11% rated critical on the CVSS scale (IBM X-Force, 2025) — a reminder that the attack surface convergence creates keeps expanding regardless of industry. On the defensive side, organizations that combine zero-trust principles with mature network segmentation (commonly implemented through microsegmentation tooling) report blocking as much as 95.8% of lateral-movement attempts between network segments, compared with far weaker outcomes on flat, unsegmented networks (Elisity, 2025). Detection speed compounds the effect: IBM’s 2025 Cost of a Data Breach report put the global average breach lifecycle at 241 days, with breaches contained before the 200-day mark costing meaningfully less than those that dragged on longer (IBM Cost of a Data Breach Report, 2025). Network segmentation done well does not just reduce the odds of a successful lateral move — it shrinks the blast radius and the detection window at the same time, which is exactly the combination that determines whether an incident stays contained to one zone or reaches the training data and model weights that represent an AI company’s core asset.

Bringing It Together

The Purdue Model will not survive a literal copy-paste into an AI data center — the traffic patterns, the hardware refresh cycles, and the sheer bandwidth requirements are too different for that. But the network segmentation discipline underneath it transfers almost without modification: define zones by criticality rather than by convenience, treat every conduit between zones as a security boundary rather than a shortcut, and never let the highest-trust zone inherit the assumptions of the lowest-trust one. For a security professional moving from OT into AI infrastructure, network segmentation is the real bridge between the two fields — not an entirely new discipline to learn, but a familiar one, applied to a network that happens to be moving gradients instead of setpoints.