“We need a Purdue-aligned network” sounds like a requirement.
It gives an architecture conversation a useful shape. We can talk about enterprise systems, manufacturing operations, controllers, physical processes, and the boundary between IT and OT. The diagram helps people organize a complicated environment into something they can reason about together.
Then someone asks where the firewall should go.
That is usually where the conversation feels as though it has become concrete. We can draw zones, pick enforcement points, and start talking about rules. But there is a step hiding between the Purdue diagram and the firewall design: which systems actually need to communicate, in which direction, under what conditions, and with what consequence if that communication is denied, inspected, interrupted, or compromised.
The distinction I find useful is:
Classification → policy → enforcement
Purdue helps classify the environment. The segmentation policy describes the relationships that should and should not exist. The firewall, ACL, VRF, VPN, proxy, fabric policy, or another control makes those decisions true.
Skipping the middle does not eliminate the policy work. It moves that work into implementation, usually at the most expensive time to discover it.
A useful model cannot answer every question
The ISA-95 functional hierarchy organizes manufacturing activities and the interfaces between enterprise and control functions into logical levels. That is useful in roughly the same way the OSI model is useful: the abstraction gives us shared language without pretending to answer every design question.
Knowing that two systems belong at different Purdue levels does not tell me which side initiates a session. It does not tell me whether two systems at the same level should trust one another, whether management traffic follows the same path as application traffic, or how remote administration and SaaS-hosted control planes fit. It does not tell me what needs inspection or how long the facility can tolerate a missing dependency.
Those are not flaws in the model. They are questions outside what a functional hierarchy can decide by itself.
This is also why I would not replace Purdue with a different diagram and call the problem solved. ISA/IEC 62443 takes the architecture further through zones, conduits, risk assessment, target security levels, and documented security requirements. Its system-design requirements reinforce the idea that grouping assets and defining communication paths belong inside a larger risk and requirements process. A zone is not complete merely because it has a familiar label.
Start with what the facility is trying to do
Before deciding what belongs between two levels, I want to understand what the facility is intended to produce and which systems make that possible.
Consider a deliberately simplified robotics system. A controller may communicate with a robot. An upstream ERP or OT application may send a job or work instruction. The robotics application may return status or completion data. Supporting services handle name resolution, authentication, monitoring, time, administration, or software management.
Assigning those components to Purdue levels helps organize them. It still leaves the more consequential questions open. Which connections are required? Who initiates them? What happens to production if one is denied? Does inspection change latency or reliability? What can an attacker reach if either endpoint is compromised? Can the process continue safely if the upstream dependency disappears?
I am not proposing a segmentation design for that hypothetical system. The point is the sequence of reasoning. The production outcome leads to the supporting solutions. Their architecture reveals the required relationships. The consequences of those relationships inform the policy. Only then do we have enough context to make a good enforcement decision.
The boundary may still be a firewall. In many cases it probably should be. The difference is that the firewall is now enforcing a decision instead of becoming the place where the organization first tries to discover one.
Brownfield environments do not wait for perfect knowledge
There is a reasonable counterargument. A brownfield facility may never produce a perfect inventory of every dependency before segmentation begins. Strong boundaries, default-deny, and controlled discovery can be safer than waiting indefinitely for complete application knowledge.
I substantially agree with that.
NIST’s current OT security guidance recommends using mapped data flows to identify required communication and configuring isolation devices to permit explicitly authorized traffic. It also acknowledges the practical problem: when necessary traffic is unclear, an organization may temporarily allow and record communication so it can identify undocumented dependencies and build the isolation rules.
That can be a legitimate implementation strategy. The trade-off should be explicit. Discovery during rollout can mean slower delivery, temporary or broader exceptions, troubleshooting under production pressure, more coordination, and revisiting the original zones once application behavior becomes clearer.
The mistake is not beginning before everything is known. The mistake is treating the topology as a complete segmentation policy because its boxes resemble the reference architecture.
Exceptions are sometimes architecture feedback
This becomes visible when a clean diagram meets a working facility. DNS appears. Monitoring needs access. Authentication and administration follow different paths. Vendor support requires a controlled entry point. An old application depends on a shared service nobody included in the first design. DHCP, time, licensing, patching, and other infrastructure traffic refuse to stay inside the application-shaped boxes.
Some of those exceptions are technical debt. Some are poor discipline. Some should be rejected.
But if a zone continually needs exceptions that contradict the philosophy used to create it, the exceptions may also be telling us that the abstraction was incomplete. A rule base can absorb that mismatch for a while. Eventually the stated policy and the operational policy become different things.
Implementation should not be the first place the organization learns how the system works unless it intentionally accepted discovery as part of implementation. Otherwise, broad rules and permanent temporary exceptions become the way production reconciles an incomplete architecture.
Let the policy outlive the topology
A durable requirement should describe what must remain true without unnecessarily turning today’s implementation into permanent organizational doctrine.
“These communities must remain isolated except for explicitly permitted application flows” preserves security intent. “Install this category of appliance in this location and require every connection to traverse it” may be a sound design, but it is an implementation decision presented as a requirement.
That difference matters as management paths change. Infrastructure may be administered from inside the facility, elsewhere on the corporate network, remotely, or through an Internet-hosted control plane. A physical interpretation of IT → IDMZ → OT does not by itself describe which identities can manage which systems, where connectivity may meet, which controls apply, or how policy remains coherent across centralized and distributed enforcement points.
Current Cisco guidance illustrates both sides of the trade-off. Its CPwE IDMZ design strongly supports firewalls and an industrial DMZ, while beginning the design process by identifying which systems and users need to interact, what they need to do, and how long connectivity can be unavailable. Cisco’s hybrid cloud IDMZ guidance then explores how that architecture changes when access and management extend beyond a facility-local model.
None of that makes a physical IDMZ obsolete. It may represent a genuine security, administrative, or ownership boundary and be exactly the right answer. Something operationally simple at one facility can simply create a different kind of complexity when repeated across an enterprise. Centralized and distributed designs both move complexity somewhere.
The policy should be stable enough to evaluate either design.
Give the enforcement something durable to enforce
I am not arguing that Purdue is broken, that firewalls are overused, or that implementation must wait for perfect application documentation. Those versions of the argument are more provocative and less useful.
The narrower point is that three different decisions often get compressed into one diagram. We classify systems and functions. We define the communication relationships and consequences the organization will accept. We choose controls and topology that enforce those decisions.
Before asking where the firewall belongs, ask what the facility is trying to accomplish, which systems make that possible, which relationships must exist, and what happens when those relationships fail or become compromised.
Purdue can help organize the answer. A firewall can be an excellent way to enforce it.
The segmentation policy is still the part we have to define.
References: