When a Textbook Design Fails the Real World

A regional Australian water utility in Victoria was partway through a broader IT/OT network separation program with its Tier 1 consulting partner when a specific design did not survive contact with its own network. The consultancy's segmentation architecture for the utility's OT Historian followed every standard in the book: a middleware proxy sitting in an OT DMZ, bridging the OT and corporate networks in line with textbook best practice. The utility never built it. The design assumed capabilities the installed historian platform, AVEVA Historian (formerly Wonderware), simply did not have. Rather than force a design that did not fit its real environment, the utility asked Parasyn to work out what actually would.

The utility's production Historian sat inside the corporate network, historising operational data from SCADA and making it available to corporate users over the corporate LAN and VPN, a direct path between corporate IT and operational data that needed closing to align with IEC 62443 zone and conduit principles and to support obligations under the Security of Critical Infrastructure Act 2018 (SOCI Act). A standards-correct answer already existed on paper. What was missing was an architecture grounded in how the utility's specific historian platform actually worked: its data flow, its proprietary protocols, its licensing model, and what its vendor would and would not support in a segmented deployment. Without that grounding, a technically sound-looking design could be, and had been, impossible to actually build.

Parasyn started from the platform itself rather than from segmentation theory:

1. Vendor-grounded investigation
   Direct discussions with the historian vendor to confirm exactly which deployment patterns the platform could support, rather than relying on generic segmentation patterns.
2. Two detailed workshops
   Structured sessions walking the utility's OT, IT and cyber security stakeholders through three candidate architectures and the reasoning behind each.
3. Deep platform expertise applied
   Understanding of historian data flow, proprietary OEM protocols, interface details and licensing strategy, knowledge a generic architecture pattern cannot substitute for.
4. Structured evaluation
   Candidate architectures scored against cyber security and IEC 62443 alignment, SOCI Act obligations, IT/OT dependency, and technical feasibility.

Three representative options were assessed in detail:

The recommended dual-historian architecture is not only standards-aligned on paper, it is grounded in what the utility's actual historian platform can support, giving the utility confidence this design would not repeat the earlier attempt's fate:

With the architecture decided and the rationale grounded in the utility's real environment, Parasyn handed the recommendation back to the utility with a clear, buildable basis to progress into detailed design and implementation planning.

This engagement is a reminder that a segmentation design is only as good as the vendor-specific knowledge behind it. A textbook-correct architecture had already been designed for this utility and never built, because it assumed capabilities the installed historian platform did not have. Parasyn's redesign started from the platform itself: its data flow, its protocols, its licensing model, and what its vendor would actually support, then built the security boundary around that reality rather than around a generic pattern. You cannot design a security boundary without first understanding the engine inside it.