Federal OT Demilitarized Zone (DMZ) Design for Build Stages: Segmenting Engineering, Vendor, and Control Traffic Without Breaking Commissioning Workflows

Building an OT DMZ during a federal system’s construction phase is a different problem than designing one for a system already in production. The architecture has to serve multiple overlapping purposes at the same time: it needs to isolate the control network from enterprise traffic, support active vendor installation work, enable engineering workstations to reach field devices, and provide a staging path for firmware, configuration files, and software updates. All of that has to happen without creating security gaps that persist into operations or introducing latency and availability risks into systems that may have deterministic timing requirements.

Federal and defense environments add layers of constraint that most commercial OT build projects do not face. Change control boards, authorization boundaries, and RMF documentation requirements mean that every firewall rule, temporary conduit, and jump host credential has to be traceable, approved, and eventually dispositioned. A temporary path opened for a vendor during installation does not automatically close when the vendor leaves. If the program office does not build expiration controls and removal criteria into the commissioning plan from the start, those paths become permanent by default.

The commissioning phase is also when the most traffic crosses the most trust boundaries. Engineering workstations talk to PLCs. Vendor laptops connect to historian servers. Test harnesses inject simulated process data. Update staging servers push firmware to field devices. Each of those flows represents a deliberate exception to the segmentation model, and each one needs a defined lifecycle: when it opens, what it permits, who approves it, and when it closes.

This article focuses on the build-stage OT DMZ as an enabling architecture rather than a general security control. It covers how to structure the zone, what services belong in it, how to manage traffic flows across trust boundaries during commissioning, and how to transition cleanly from build to operations without leaving latent risk behind. For foundational segmentation principles and general DMZ design patterns, those topics are covered separately in Anchor Defense’s broader Operational Technology (OT) Security resources.

Build-Stage Reference Architecture for the OT DMZ

A build-stage OT DMZ sits between the enterprise network and the control network, but during construction it also has to interface with a third zone that most production architectures do not maintain: the staging and test environment. That staging zone is where firmware gets validated, configuration files get tested, and simulated process data gets injected before anything touches live field devices. The DMZ has to mediate traffic between all three of those zones simultaneously, which means the firewall policy during build is more permissive and more complex than it will be in production.

The reference architecture for a federal build-stage DMZ typically includes at minimum: a vendor access broker or jump host segment, an update and patch staging segment, a historian or data aggregation segment, a protocol mediation or data diode segment for control-plane traffic, and a test harness interface. Each of those segments should be logically separated even if they share physical switching infrastructure. The reason is operational: when commissioning is complete, you need to be able to remove the vendor access segment and the test harness interface without disrupting the historian replication or the protocol mediation paths that will remain in production.

The firewall policy at the DMZ boundary should be written in layers that correspond to commissioning phases. Rules that support vendor installation work are tagged as temporary. Rules that support engineering workstation access during configuration are tagged as commissioning-phase. Rules that support production historian replication and protocol mediation are tagged as permanent. That tagging is not just organizational hygiene; it becomes the basis for the rule review and removal process that the authorization package will require.

One design decision that programs frequently defer too long is where to place certificate services and time synchronization. Both are needed by field devices during commissioning, and both require a path through the DMZ. If those services are hosted in the enterprise zone, the DMZ has to permit inbound connections from the control network to reach them, which is the opposite of the default-deny posture you want for production. Hosting certificate services and NTP within the DMZ itself, or in a dedicated services segment adjacent to it, avoids that inversion and simplifies the production firewall policy.

Separating Engineering, Vendor, Test, and Control Traffic

During a build phase, four distinct categories of traffic cross the DMZ, and they have different trust levels, different authorization requirements, and different lifespans. Treating them as a single undifferentiated flow is the most common architectural mistake in federal OT build projects.

Engineering traffic originates from program-owned workstations operated by system integrators or government engineers. It needs to reach PLCs, RTUs, and HMI systems to push configuration, run diagnostics, and validate control logic. This traffic is relatively trusted but still needs to be logged, session-limited, and routed through a managed jump host rather than allowed direct workstation-to-device connectivity. The jump host provides the audit trail that the authorization package will require.

Vendor traffic is different. It originates from equipment manufacturers or software vendors who may be connecting from outside the facility, from a vendor-managed laptop on a guest network segment, or from a dedicated vendor workstation on a temporary VLAN. Vendor traffic should never share a jump host with engineering traffic. Vendor sessions need to be recorded, time-limited, and tied to specific change tickets. The vendor should not have persistent credentials; session credentials should be issued per engagement and revoked when the work order closes.

Test and simulation traffic is the category that programs most often fail to plan for. Test harnesses inject synthetic process data to validate control logic before live process connections are established. Simulation servers may need to reach the same field device interfaces that production sensors will eventually use. This traffic needs a path through the DMZ that is completely separate from the vendor and engineering paths, because it will be removed at a different point in the commissioning sequence. Mixing test traffic with engineering traffic makes it difficult to validate that the test harness has been fully disconnected before cutover.

Control-plane traffic, meaning the actual process data and command traffic between the control network and any enterprise-facing systems like historians or supervisory dashboards, should be the most restricted category during build. It should traverse a protocol mediation or data diode path that enforces unidirectional flow from the control network outward. Even during commissioning, bidirectional control-plane traffic should require explicit approval and should be logged at the packet level.

Temporary Conduits, Expiration Controls, and Change Management

Every firewall rule opened during the build phase to support a temporary workflow is a conduit. Federal programs need to treat conduits as time-limited assets with defined expiration conditions, not as configurations that will be cleaned up later. “Later” does not happen reliably in federal acquisition environments. Programs run over schedule, personnel rotate, and the engineer who opened a rule for a vendor site visit in month four may not be on the program in month fourteen when the system is being authorized.

Expiration controls can be implemented in two ways. The first is technical: some firewall platforms support rule expiration dates or scheduled disable functions. If the platform supports it, use it. The second is procedural: every temporary rule is tied to a change ticket with a defined closure condition, and the change control board is responsible for reviewing open temporary rules at each commissioning milestone review. Both approaches should be used together, because technical expiration without procedural tracking means no one notices when a rule expires and a workflow breaks, and procedural tracking without technical enforcement means rules stay open past their closure conditions.

The change management process for build-stage DMZ rules needs to be faster than the standard enterprise change process, but it cannot be informal. Programs that route every firewall rule change through a full change advisory board cycle will find that commissioning work stalls waiting for approvals. The practical solution is a pre-authorized commissioning change category with defined parameters: rules must be temporary, must be scoped to specific source and destination addresses, must be logged, and must have a named owner and a defined removal condition. Changes that fit those parameters can be approved by the ISSO and the commissioning lead without a full board review. Changes that do not fit those parameters go through the full process.

Services That Belong in the Build-Stage DMZ

The build-stage DMZ is not just a firewall policy. It is a service hosting zone, and the services it hosts during commissioning are different from the services it will host in production. Getting that distinction right matters because services that are appropriate during build can become attack surface if they remain after cutover.

Services Required During Build

Update and patch staging is the most operationally critical build-stage service. Field devices, PLCs, and HMI systems need firmware and software updates during installation, and those updates cannot come directly from the internet or from the enterprise network without passing through a validation step. The DMZ staging server receives update packages from the enterprise side, validates them against known-good hashes, and makes them available to the control network side through a controlled transfer mechanism. That staging function should remain in production, but the specific update packages and staging paths used during commissioning should be reviewed and cleaned up before authorization.

Historian replication staging is another service that exists in both build and production, but with different configuration during each phase. During build, the historian may be receiving data from both live field devices and test harnesses simultaneously. The production historian configuration should only receive data from validated live sources. The transition from build to production historian configuration is a specific commissioning milestone that needs to be documented and verified, not assumed.

File transfer controls are needed during build to move configuration files, logic programs, and documentation between the enterprise and control network zones. A managed file transfer service in the DMZ, with logging and content inspection, is preferable to ad hoc USB transfers or direct workstation-to-device file copies. The file transfer service should enforce allowed file types and should log every transfer with the source, destination, filename, and approving user.

Services to Remove After Commissioning

Vendor remote access brokers, test harness interfaces, and commissioning-phase jump hosts are the services most likely to be left running after cutover. Each of them should have a named owner, a defined removal condition, and a verification step in the commissioning acceptance checklist. The verification step should require evidence of removal, not just a checkbox. For a jump host, that means confirming the host is decommissioned or reconfigured, not just that the firewall rule pointing to it is removed. A jump host that is still running but unreachable through the firewall is still a risk if it has credentials stored on it or if the firewall rule is later reinstated for troubleshooting.

Cutover Sequencing and Validation of Safety-Critical Traffic

Cutover from a commissioning configuration to a production configuration is the highest-risk phase of an OT build project. The DMZ firewall policy is changing, services are being removed or reconfigured, and the control network is transitioning from a test state to a live state. All of that has to happen in a sequence that preserves the availability of safety-critical and deterministic traffic throughout the transition.

The cutover sequence should be built around the principle that production traffic paths are established and validated before commissioning traffic paths are removed. That means the production historian replication path is confirmed working before the test harness interface is disconnected. The production firewall rule set is loaded and tested in a maintenance window before the commissioning rules are removed. The production jump host is provisioned and access-tested before the commissioning jump host is decommissioned.

Validation of deterministic traffic is a specific technical requirement that programs often treat as a post-cutover activity. It should not be. If a control system has timing requirements, such as scan cycle times, polling intervals, or safety system response times, those requirements need to be validated in the commissioning environment with the production DMZ firewall policy in place before cutover. A firewall rule that introduces unexpected latency on a safety-critical path is not something you want to discover after the system is live. The commissioning environment should replicate the production DMZ policy as closely as possible during the final validation phase, so that timing and availability issues surface before they affect operations.

Rollback planning is required but frequently underdeveloped. The rollback plan for a DMZ cutover needs to specify which commissioning rules can be reinstated, under what approval conditions, and for how long. It also needs to specify who has the authority to declare a rollback, because in a federal environment that authority may not rest with the technical team. If the ISSO or the authorizing official needs to approve a rollback, that approval process needs to be pre-coordinated so it can happen within the change window, not after it closes.

Common Mistakes

The most operationally damaging mistake in federal OT DMZ build projects is treating the commissioning network as a temporary environment that does not need the same rigor as the production environment. Commissioning networks are where the security posture of the production system is actually established. Weak access controls, unlogged sessions, and undocumented firewall rules during commissioning become inherited vulnerabilities in the production system if they are not explicitly addressed before cutover.

A related mistake is writing the firewall rule set for commissioning convenience and then trying to derive the production rule set from it by removing rules. That approach produces a production rule set that is defined by what was not removed rather than by what was deliberately designed. The production rule set should be written independently, based on validated traffic flow requirements, and the commissioning rule set should be treated as a superset that is replaced by the production set at cutover, not trimmed down to it.

Programs frequently underestimate the number of distinct jump hosts they will need during build. A single shared jump host for engineering, vendor, and test traffic creates an audit problem: session logs from different trust levels are intermingled, and it becomes difficult to demonstrate to an assessor that vendor sessions were properly controlled. Separate jump hosts for each traffic category are operationally straightforward to implement and significantly simplify the authorization evidence package.

Failure to validate protocol mediation behavior under load is another common gap. Protocol converters and data diodes in the DMZ may behave differently under commissioning traffic volumes than under production traffic volumes. If the commissioning environment does not replicate production traffic patterns, performance issues in the protocol mediation layer may not surface until the system is live. That is a particularly serious problem for safety-critical systems where the protocol mediation layer is in the data path for protective functions.

Finally, programs routinely fail to generate the removal evidence that federal authorization packages require. A commissioning plan that says temporary rules will be removed is not the same as documentation showing they were removed. The authorization package needs records of the actual removal actions: who removed the rule, when, under what change ticket, and what verification was performed. Programs that do not build that evidence collection into the commissioning workflow end up reconstructing it from memory during the assessment, which is both unreliable and time-consuming.

Recommended Federal Approach

Start the DMZ design before the system integration contract is awarded, not after. The DMZ architecture affects how vendor access is structured, how test harnesses connect, and how the commissioning environment is built. If those decisions are left to the integrator, they will be made for integration convenience rather than for security and lifecycle manageability. The program office and the ISSO should have a DMZ reference architecture in the contract requirements, not just a general segmentation requirement.

Establish the traffic category taxonomy early. Define what engineering traffic, vendor traffic, test traffic, and control-plane traffic mean for this specific program, what trust level each carries, what access controls apply, and what the removal trigger is for each category. Document that taxonomy in the system security plan before commissioning begins, so that every firewall rule opened during build can be classified against it.

Build the commissioning rule inventory as a living document from the first day of build. Every rule that is opened should be entered into the inventory with its category, owner, approval reference, and removal condition. Review the inventory at each commissioning milestone. Do not wait until the pre-authorization assessment to discover what rules are open.

Run the production firewall policy in the commissioning environment for at least one full validation cycle before cutover. That means loading the production rule set, running the full suite of control system traffic, and validating that deterministic and safety-critical traffic meets its timing and availability requirements under the production policy. Any gaps discovered during that validation cycle are addressed in the commissioning environment, not in production.

Sequence the cutover to establish production paths before removing commissioning paths. Build the rollback criteria and approval authority into the change plan before the change window opens. After cutover, perform a structured verification of the DMZ service inventory against the production baseline, and generate the removal evidence records that the authorization package requires. Do not close the commissioning phase until that evidence is complete and reviewed by the ISSO.

For programs that are also managing RMF concurrently with build, align the commissioning milestone reviews with the RMF control assessment schedule. Controls related to access control, audit logging, and network segmentation should be assessed against the production configuration, not the commissioning configuration. If the assessment happens before cutover is complete, the program needs to document which controls are being assessed in their final state and which are still in a commissioning configuration, and it needs a plan for re-assessing the latter group after cutover.