IT/OT Separation Services: What They Cover and How to Evaluate Them

The Scenario That Triggers This Conversation

Most building owners and plant operators don't go looking for “IT/OT separation” on their own. The phrase enters the room through one of a few predictable channels:

• An insurance renewal questionnaire asks whether operational technology is segmented from the business network, and the honest answer is “not really.”
• A ransomware event elsewhere in the portfolio — or in the news — jumps from IT into OT, and leadership wants to know why that couldn't happen here.
• An IT security team takes responsibility for the BAS network and discovers the controls VLAN, the corporate VLAN, and the guest VLAN are all routed flat through one firewall rule.
• A regulator, auditor, or tenant asks for documented segmentation and the existing diagram is a Visio file from 2018.

The owner then calls a provider, the provider says “we do IT/OT separation,” and the proposal that comes back ranges from a two-week VLAN engagement to a year-long redesign with monthly retainer fees. The gap is real: the term doesn't mean one thing. Knowing what the work should actually contain is how you tell a complete proposal from a partial one.

What “IT/OT Separation” Actually Means

IT and OT serve different goals and have different failure modes. IT prioritizes confidentiality and integrity of data; an outage is disruptive but rarely physical. OT prioritizes availability and safety; a write to a register or a BACnet Present_Value moves something physical — a damper, a valve, a chiller stage, an access-control relay. Separating the two means more than putting them on different VLANs. The goal is to ensure that:

• A compromise on the IT side cannot reach the OT side through the network, shared credentials, or trust relationships.
• The OT side can still send the data the business needs (energy metering, alarm telemetry, occupancy data) without exposing its control surface.
• Vendors and integrators who need into OT come in through a controlled path that is auditable and revocable.
• Each side can be operated and patched on its own cadence without breaking the other.

That set of properties is what a separation service is supposed to deliver. It is a network engagement, a governance engagement, and an identity engagement — in that order.

How the Work Maps to Standards

Two public references are doing most of the load-bearing work in this space:

• NIST SP 800-82, Guide to Operational Technology (OT) Security. The current revision (Rev 3) covers network architecture, segmentation, remote access, monitoring, and recovery for OT environments. It is freely available from NIST and is the most common reference cited by insurers and U.S. federal stakeholders.
• ISA/IEC 62443 series. The zone-and-conduit model in 62443-3-2 (security risk assessment) and the system security requirements in 62443-3-3 are what most mature providers structure their methodology around. A “zone” is a group of assets with shared security requirements; a “conduit” is the channel between zones, and the conduit itself has security requirements distinct from the zones it joins.

The older Purdue Enterprise Reference Architecture (commonly referenced as Levels 0–5) still shows up in vendor decks and remains a useful mental model, but modern guidance treats it as a starting point rather than a prescription — the strict hierarchy doesn't map cleanly onto cloud-connected building stacks, IoT gateways, or remote-access brokers.

A practical translation of the 62443 zone model for building automation is covered in IEC 62443 Security Zones for Building Automation. That entry is the right next read if you're trying to figure out where your zones actually are before you talk to a provider.

What a Complete Separation Service Includes

Use the following list as a scope checklist against any provider proposal. A complete engagement covers all of these; a partial engagement should be explicit about which it is leaving out.

• Asset inventory. Every controller, gateway, BACnet router, JACE, PLC, HMI, IP camera that owners assume is “BAS” and IT assumes is “facilities’ problem.” Without an inventory, segmentation rules are guesswork.
• Data-flow mapping. What talks to what, on which protocols, in which direction. BACnet/IP broadcasts, Modbus/TCP polls, Niagara Fox connections, vendor cloud callbacks, NTP, DNS, syslog. Each flow either survives separation or it gets re-routed through a controlled conduit.
• Zone definition. Group assets by criticality and protocol family. Field-controller zones, supervisory zones, the DMZ that hosts analytics or remote-access brokers, the corporate IT zone, the vendor-access zone.
• Conduit design. For every place a zone boundary is crossed, define what is allowed: source, destination, protocol, port, time window, identity. Default-deny at the boundary, not at the host.
• Remote access architecture. Vendors don't connect to controllers directly. They authenticate to a broker, the broker authorizes the specific target, and the broker proxies the protocol traffic. See Secure Remote Access for Cyber-Physical Systems for the architecture patterns that meet this requirement.
• Identity and credential rework. Shared vendor logins, default passwords on field controllers, and service accounts that no one owns — all addressed during the engagement, not noted as “future work.”
• Monitoring and detection. Logging from boundary devices and the remote-access broker forwarded to a system the owner controls. The audit data has to survive a vendor relationship ending.
• Documented governance. A network diagram that reflects reality, a written zone-and-conduit policy, a change process for adding new flows, and an offboarding procedure when a vendor leaves.

What the Engagement Looks Like in Practice

1. Discovery and assessment (typically 2–6 weeks). Passive traffic capture on the existing network, asset enumeration, interviews with facilities and IT. Output is a current-state diagram and a gap list against NIST SP 800-82 or IEC 62443.
2. Target architecture design. Zones, conduits, firewall rule design, remote-access broker placement, identity model. Reviewed jointly by facilities, IT security, and the integrator.
3. Phased implementation. Network changes are staged to avoid breaking control logic. Common phases: stand up the new boundary infrastructure → migrate non-critical flows → migrate critical flows in a planned maintenance window → decommission the old paths.
4. Verification. Re-scan to confirm only allowed flows traverse the conduits. Test that the off-ramp works: when a credential is revoked or a session expires, access actually disappears.
5. Documentation handoff. Diagrams, policies, runbooks, and a known-state baseline that survives the provider leaving.
6. Ongoing monitoring (optional retainer). Many providers offer continued log review, quarterly architecture reviews, and a defined process for adding flows safely.

How to Evaluate a Provider

Questions that separate complete proposals from partial ones:

• Does the proposal name the standards it's aligning to (NIST SP 800-82, IEC 62443), or does it use generic language like “industry best practices”?
• Does it include an asset inventory and data-flow mapping step, or does it assume the owner provides those?
• Does it explicitly address vendor remote access, or only east-west network rules?
• Does it address identity and credential rework, or treat that as IT's problem?
• Who operates the result after handoff — the owner, the provider on a retainer, or no one? “No one” is a real and common answer that should be flagged.
• What is the rollback plan if a boundary rule breaks a control flow during cutover?

Before committing to a provider, a structured self-assessment of the current environment is a useful baseline. The checklist in How to Run a BAS Cybersecurity Audit covers most of what a provider's discovery phase will surface, and walking through it first lets you scope the engagement more tightly.

Common Pitfalls

• Buying VLANs and calling it separation. A VLAN is a segmentation primitive, not an access control. Anything that reaches the VLAN reaches every device on it. Separation lives at the conduit, not at the tag.
• Skipping the asset inventory. Without knowing what's on the network, the rule set will either over-block (breaking control logic) or under-block (leaving the original problem in place).
• Treating remote access as a phase 2 problem. Third-party vendor access is the path most OT incidents take. A separation engagement that defers remote-access design has deferred the most likely attack path.
• Leaving shared credentials in place. Network segmentation does not stop an attacker who already has a working set of vendor credentials. Identity work is part of the scope, not adjacent to it.
• Documenting once and never revisiting. Zones and conduits drift. Without a change process and periodic review, the diagram is wrong within a year.
• Confusing “air-gapped” with “separated.” Most BAS networks need some flows out (energy metering, alarm telemetry, vendor analytics). The goal is controlled flow, not no flow. A proposal that promises a true air gap is either inaccurate or about to break a business requirement.

When to Escalate

Bring in dedicated OT security expertise — either internal or an outside firm with verifiable references — when any of the following are true:

• The site supports a critical-infrastructure function (water, energy, healthcare, public safety) where availability or safety failures have regulatory or human consequences.
• A confirmed unauthorized access event has already occurred and the scope of exposure is unclear.
• The IT security team owns the BAS network but doesn't have BACnet, Modbus, or Niagara experience; their tooling will model the traffic incorrectly and the rule set will be wrong.
• You're moving from a single building to a portfolio and the ad-hoc separation approach won't scale.
• An insurer or regulator has set a specific remediation deadline and a partial engagement won't close the gap in time.

Source Attribution

The guidance in this entry draws on the following publicly available sources:

• NIST SP 800-82 — Guide to Operational Technology (OT) Security — National Institute of Standards and Technology. Network architecture, segmentation, remote access, and monitoring recommendations for OT environments.
• ISA/IEC 62443 series — International Society of Automation / IEC. Zone-and-conduit model, security risk assessment (62443-3-2), and system security requirements (62443-3-3).
• NIST SP 800-207 — Zero Trust Architecture — The per-request, identity-bound access model that underpins modern brokered remote-access design.
• CISA — Industrial Control Systems guidance — U.S. Cybersecurity and Infrastructure Security Agency advisories on OT segmentation and access control.

Additional patterns and field guidance from SiteConduit's work with building owners and integrators.