OT Segmentation: Why the Framework Matters Less Than the Discipline

Part 2 of 2: Why the quality of your OT segmentation in real industrial environments matters more than the label on the framework you used to get there.

In Part 1, we walked through the Purdue Model and IEC 62443 as two frameworks that do different jobs. Purdue is the architectural reference. IEC 62443 is the building code. Both are useful. Both are necessary in most environments. Neither is sufficient on its own.

This piece takes the next step. It argues that the frameworks themselves are servants of something more fundamental: the discipline of OT segmentation. OT segmentation is the practice of separating industrial systems into controlled zones and tightly managing the communications between them. The label on the framework you cite matters less than whether your environment is actually well-segmented. And the path that gets you there is allowed to be a hybrid.

Frameworks Are Tools, Not Goals

A failure mode worth naming directly. Some teams adopt IEC 62443, or pursue 62443 certification, as the goal itself. The plan becomes “achieve 62443 alignment” instead of “be well-segmented.” The two are related but they are not the same thing, and when the framework becomes the destination, the actual security work can quietly drift sideways.

The same trap exists in the other direction. Purdue purists sometimes insist every architecture must follow the hierarchy strictly, even in environments where the hierarchy never quite fit. A modern manufacturing facility with cloud-connected historians, a maritime operation with intermittent satellite links, a pharma plant with vendor remote access for instrument calibration. These environments can be modeled in Purdue terms, and often should be for the shared vocabulary. They cannot always be forced into a clean five-level hierarchy without distorting how the systems actually work.

Frameworks are tools. When the framework becomes the goal, the goal stops being security.

What Good OT Segmentation Actually Does

Strip away the framework names and the certifications and the diagrams. Good OT segmentation, regardless of how you got there, accomplishes a small set of things:

• Clear separation between zones with different risk profiles. Systems that don’t need to talk to each other don’t talk to each other. Systems that handle different criticalities sit on different sides of a boundary.
• Tightly controlled communication between zones. This is the one that carries the most weight. Limiting what can flow into and out of zones where critical processes take place is one of the highest-leverage moves in OT security. A small number of well-understood communication paths, each justified, monitored, and protected, will reduce risk more than almost any other architectural decision.
• Containment when something goes wrong. A compromise in one zone should not become a compromise in every zone. OT segmentation is what makes that containment possible.
• Visibility into what’s actually crossing boundaries. Drawing a zone on a diagram is the easy part. Knowing what traffic is actually moving across the conduit, and whether that traffic matches what was expected, is where segmentation becomes operational.
• Documentation that survives staff turnover. The architecture has to be written down, maintained, and accessible to the people who come after the original architects leave. Tribal knowledge is not a segmentation strategy.

These are the outcomes that matter. They are the things an auditor, an incident responder, an insurance underwriter, or a thoughtful operator will actually care about. The framework you used to get there is a means, not an end.

The Hybrid Reality

Here is the part vendor content tends to flatten. Most mature OT programs are not pure 62443 implementations. They are not pure Purdue mappings. They are hybrids.

The cross-sector reality varies more than the framework-level conversation suggests. A pharma operation may layer 62443 zone-and-conduit thinking on top of FDA validation requirements and internal GxP controls. An energy generator under NERC CIP works through CIP requirements first and uses 62443 concepts where they help fill gaps the standard does not cover. A manufacturer might draw heavily on NIST SP 800-82 for the broader security program while using Purdue for shared vocabulary and 62443 for zone-level methodology in the most critical lines. A maritime operator faces IMO guidance, classification society requirements, and the realities of intermittent connectivity that no land-based framework was written for.

None of these teams are doing it wrong. They are doing what mature security work actually looks like: drawing on whatever combination of references, methodologies, regulatory requirements, and network security best practices fits their environment, their sector, and their risk tolerance.

The one thing all of them have in common, when they are doing it well, is documentation. A hybrid approach is not an excuse for ambiguity. If anything, it raises the bar. When you are pulling from multiple sources, the rationale for each choice has to be written down internally. Why this zone boundary here. Why this conduit allows that protocol. Why this control is at SL 2 instead of SL 3. Why this Purdue-level mapping deviates from the textbook in this specific case.

Heavy internal documentation is what turns a hybrid approach into a deliberate architecture. It is the difference between a team that knows what it built and a team that hopes someone wrote it down.

Where to Spend the Energy

If frameworks are tools and segmentation is the discipline, the question for any OT security leader becomes a different one. Less “which framework should we adopt.” More “are we actually well-segmented, and can we prove it.”

That question is harder. It is also more honest. It does not have a single right answer that lives in a standards document. It is answered, day by day, by the architectural choices being made, the conduit traffic being monitored, the zone boundaries being maintained, the documentation being kept current, and the discipline being applied even when nobody is auditing.

The frameworks help. Use them. Cite them. Pull from more than one if your environment calls for it. Let them inform your thinking and structure your conversations. Just don’t confuse following them with being secure.

Where This Leaves Us

Two posts ago we started with what looked like a comparison of two frameworks. We end somewhere more interesting. The comparison itself is less important than what sits underneath it: the choice to take segmentation seriously as a discipline, to apply it deliberately, to document it honestly, and to hold the framework loosely enough that it serves the work instead of running it.

Every environment is different. Every sector has its own pressures. Every team is working with the budget, the staff, and the legacy infrastructure they actually have, not the ones a textbook assumes. The good news is that the work is real and the principles travel. Manufacturing, pharma, energy, maritime, water, oil and gas. The frameworks vary. The discipline does not.

If you take one thing from this series, take this: the question to keep asking, in every architecture review, every vendor conversation, every audit prep, is whether your segmentation is actually doing what segmentation is supposed to do. The frameworks are there to help you answer that question. They are not the question itself. In the end, strong OT segmentation is what turns framework guidance into real operational security.

Stay deliberate. Stay documented. Keep the discipline.