This is the third post in our MTSA cybersecurity series. In the first post, we introduced the crawl, walk, run approach we’re using to work through the regulation, and used segmentation as the preview example. In the second post, we covered asset inventory: knowing what’s on your network. This post picks up where that one left off.
A crew manifest tells you who’s aboard. It doesn’t tell you who has access to the bridge, the engine room, or the cargo hold; that’s a separate question, with separate consequences if you get it wrong. Asset inventory works the same way. Knowing what’s on your network is step one. Knowing what each of those assets can reach, and what can reach them, is what actually determines your exposure.
That’s network segmentation, and in a maritime environment, getting it right is the difference between a contained incident and an operational crisis.
Two connectivity vectors that need to be called out and considered specifically are remote access and wireless networks. In the 2026 Dragos OT Cybersecurity Year in Review, remote access is highlighted as one of the most exploited entry points in OT environments. Every remote access pathway into your OT network should be controlled through a dedicated jump host or broker, logged, time-limited, and tied to a specific purpose. Persistent vendor remote access is unacceptable. Wireless networks such as Wi-Fi, cellular, satellite, and radio present another challenge on vessels and facilities. Operational wireless and radio networks must be separated from control networks, with the same considerations applied to wired connections. Satellite, cellular, and radio uplinks, including VHF/HF data links, VDES, and radio-based telemetry, used for navigation or cargo management that touch OT directly or indirectly must be mapped, controlled, and included in your segmentation design.
That’s the full architecture: enterprise systems at the top, two DMZ layers acting as controlled boundaries, six distinct OT environments underneath, and crown jewels classified on top of all of it rather than living in a zone of their own.
In the first post, we introduced crawl, walk, run as the way we work through every MTSA requirement in this series, and used segmentation as the example: crawl is a truthful picture of what you actually have, walk is turning that into intentional architecture, and run is proving the boundaries hold under real conditions. Here’s what that looks like applied to each layer of the architecture above.
Most environments drift over time: systems get added, vendors plug in remotely, undocumented connections accumulate. Before you redesign anything, you need to know where your assumptions and your actual network diverge, because that gap is usually where the highest risk lives.
Enterprise: This is the IT world most people already know — corporate and enterprise systems, finance platforms, HR tools, email, collaboration suites, and identity infrastructure, all designed for broad accessibility, which is also their liability. OT-adjacent systems (ERP modules, scheduling platforms, enterprise historians, analytics tools) sit closest to production, but they express intent, not control. Start by identifying every one of them that currently touches OT data or OT-adjacent platforms, and document what they actually connect to today, not what the last network diagram says.
Boundaries: This is where IT and OT actually meet, and where misconfigurations cause the most damage. Map every existing crossing point between enterprise and OT, including the ones nobody remembers configuring. Find the vendor remote access paths, the jump hosts, and any flat connections that have crept in without documentation.
OT: Once you’re inside the OT environment, the stakes change. Inventory what’s actually running across all six environments:
- Supervisory systems (SCADA, HMIs, alarm management, MES) are where operators interact with the operations. Stability and availability are engineering requirements, not preferences.
- Control systems (PLCs, RTUs, DCS controllers, SIS, drives) are where software meets physics. These must be deterministic, minimally connected, and fully independent from enterprise IT services.
- Production environments represent the live, in-service designation that cuts across supervisory and control layers. Changes here are infrequent by design and subject to rigorous review.
- Test and engineering environments are where changes are developed and validated before they touch anything real. These must share zero credentials, access paths, or live data with production. The moment that the boundary blurs, the integrity guarantee collapses.
- Backup and recovery systems embody the last line of defense. Backups must be logically isolated from production, stored offline or on Write Once, Read Many (WORM) media, and tested on a regular schedule. An untested backup isn’t a recovery capability; it’s a false sense of security.
- Facilities OT (HVAC, access control, CCTV, fire, and life-safety) is OT, but a separate domain from process control. It gets its own supervisory layer, its own DMZ, and its own enterprise interfaces. It never shares flat trust with process OT.
Crown jewels: Identify which specific assets would cause catastrophic consequences if compromised (safety systems, critical control logic, engineering workstations with write access to PLCs, authentication roots, configuration repositories, time synchronization authorities), regardless of which network segment they currently sit in.
Once you know what you’re actually working with, you can start making deliberate decisions about what should communicate, what shouldn’t, and where controls need to exist.
Enterprise: Logically separate enterprise systems from OT. Give OT-adjacent platforms only the access they strictly need, and document that access. Actual control decisions stay inside OT systems where they belong.
Boundaries: Build the Enterprise–OT DMZ (Purdue Level 3.5) and the OT DMZ on purpose. The Enterprise–OT DMZ hosts the integration middleware, API gateways, secure file transfer tools, jump hosts, and identity proxies that allow controlled data exchange without introducing direct trust. The OT DMZ mirrors this on the operational side, hosting patch servers, antivirus infrastructure, and vendor remote access brokers that carry too much enterprise exposure to live inside control networks. Everything crossing either DMZ should be designed to be inspected, logged, and contained. Compromises that reach these layers should stop there.
OT: Draw real boundaries between the six environments, and design each one to its own requirements. Supervisory systems (SCADA, HMIs, alarm management, MES) need stability and availability as engineering requirements, not preferences. Control systems (PLCs, RTUs, DCS controllers, SIS, drives) must be deterministic, minimally connected, and fully independent from enterprise IT services; this is where software meets physics. Production environments should see changes infrequently, by design, and subject to rigorous review. Test and engineering environments in particular must share zero credentials, access paths, or live data with production; the moment that boundary blurs, the integrity guarantee collapses. Backups should be logically isolated from production and stored offline or on Write Once, Read Many (WORM) media, tested on a regular schedule. Facilities OT gets its own supervisory layer, its own DMZ, and its own enterprise interfaces — it never shares flat trust with process OT.
Crown jewels: Formally classify these assets in your Cybersecurity Plan, and design stricter controls that travel with the asset rather than the zone: tighter access controls, enhanced monitoring, stronger backup requirements, elevated change governance. That’s what prevents a critical asset from being treated as ordinary simply because it happens to sit in a less sensitive part of the network.
Design only matters if it survives contact with reality. This is where you stop drawing lines on diagrams and start confirming they function as intended.
Enterprise: Test, don’t assume, that a compromise in your enterprise network cannot propagate directly into OT.
Boundaries: Do you have documented, enforced rules for what can cross each DMZ, confirmed under real traffic? Is every crossing point actually logged, not just designed to be?
OT: Are your test and engineering environments truly air-gapped from production? Are backups offline, tested, and genuinely restorable — remember, an untested backup isn’t a recovery capability, it’s a false sense of security. Is facilities OT really on its own network segment, or quietly sharing a VLAN with IT workstations?
Crown jewels: Have you formally identified your crown jewels, and are they documented in your Cybersecurity Plan? Are the controls applied to them actually reflecting their criticality, and revisited every time the architecture changes, or are they being managed the same way as everything else?
An architecture like this only works if the boundaries hold, and the only way to know they hold is to test them, not assume them. But segmentation only contains an incident: it doesn’t guarantee you recover from one, and it doesn’t guarantee you saw it coming in the first place. That’s resilience: the capability that determines how well you survive what you can’t prevent, and it’s the subject of the next post in this series.
- Network Segmentation Architecture Diagram showing how to segment OT networks across DMZ, control, and production zones to limit adversary movement.
Want help mapping your OT network segmentation?
