The OT Side of the Boundary: What Industrial Control Flaws and the OT Coalition's Push for a Binding Directive Mean for Facility Compliance

By Josh Hammer, CEO, H&V Complynt

A building’s control systems do not become irrelevant to cybersecurity because they sit outside the IT department. If a building automation network, access-control system, or industrial controller can reach, or affect, the systems that handle controlled information, it deserves a deliberate place in your boundary analysis.

I have spent a decade in federal facility and control-system work, and I can tell you the most common belief I have to correct is that an air-gapped system is automatically safe. Facility teams see a network diagram with no connection to the enterprise side and conclude the equipment is out of scope. Almost every time, the diagram is the problem. During close-out, the installed as-builts rarely match the original submittals, and they are almost never updated afterward, especially when unpermitted renovation work is done. Facilities regularly go decades without updating those as-builts. So the “air gap” exists on paper and vanishes the moment you trace what is actually installed.

That leads to what I find on nearly every first walk-through of a facility: a stale asset inventory. Not a missing one, a stale one. Someone maintained it at some point, and it has drifted from reality ever since. The equipment nobody documented is precisely the equipment that ends up inside the boundary, and the diagram that says otherwise is not evidence.

The other recurring conflict I see is between IT and facilities teams when a compliance boundary gets drawn: remote access. Vendors and integrators connect to controllers through paths nobody approved or logged, and each team assumes the other owns that access. If you cannot produce the approval and the log, the boundary you drew on the org chart is not the boundary that exists in the building.

Recent vulnerability reporting and a policy proposal from the OT Cybersecurity Coalition have put renewed attention on OT visibility. Neither, by itself, creates a new contractor requirement. Both reinforce a more durable point: you cannot defend or demonstrate control over facility systems you have not identified.

Tier 1: Where the OT boundary actually sits

A mechanical room, a rooftop HVAC controller, a badging system, or a building automation network may be relevant to your compliance program, not simply because it is part of the building, but because of its function and connections.

Ask practical questions. Can the system communicate with a network that handles CUI? Does it provide a security function, such as controlling access to a room that houses CUI systems? Could its compromise affect the confidentiality, integrity, or availability of those systems? What remote connections can a vendor or integrator use to reach it?

The answers, not the system’s location or departmental owner, should inform your scoping decision. For CMMC, OT may qualify as a Specialized Asset when it can process, store, or transmit CUI but cannot be fully secured using ordinary IT controls. The classification and its rationale belong in the organization’s asset inventory and scope documentation. See our practical guide to mapping your CUI boundary.

Contractors routinely overlook OT for understandable reasons. The equipment may predate the contract. A facilities vendor may manage it. The IT asset register may not include it. And agent-based endpoint tools may not detect a controller that cannot run an agent.

These are explanations, not evidence that the systems are outside the boundary. OT is a classification problem before it is a hardening problem: identify the asset, establish its role and connections, then decide how it should be treated and controlled.

I also want to be honest about what that identification costs, because contractors are routinely surprised by it. A proper OT inventory, done correctly, takes weeks, not days, especially when legacy systems are involved. You are tracing networks that nobody documented, sometimes across decades of accumulated change. Clients typically expect a quick pass through the mechanical room and a spreadsheet by Friday. What they get instead is a series of conversations with facilities staff, a comparison of as-builts against what is physically installed, and the discovery that some connections were never drawn on any diagram. That expectation gap is the single most common reason OT scope gets deferred, and deferring it is how the stale inventory becomes a compliance finding later.

The broader OT picture includes more than factory machinery. NIST describes OT as systems that interact with or manage the physical environment, including industrial control, building automation, transportation, and physical access systems. Its SP 800-82 Rev. 3 remains the current final guide. The initial public draft of Rev. 4, published September 21, 2026, explicitly expands coverage to Building Automation and Control Systems. Comments are due November 30, 2026. The draft is guidance, not a new contractor mandate.

Our earlier post, “The Plant Floor Is the Next Compliance Frontier,” introduced why OT resilience matters. This article takes the next step: how to establish the boundary, assess the policy signals accurately, and produce evidence for facility-related control systems.

Tier 2: What the vulnerability reports do, and do not, show

Vulnerability reporting can help teams identify assets that need review. It can also mislead if a CVE is matched to the wrong product. A CVSS score describes severity, not proof that a flaw has been exploited in the wild. Before acting, check the vendor’s advisory, the CVE record, and, where relevant, the CISA Known Exploited Vulnerabilities Catalog.

That validation matters for three claims circulating in recent reporting:

• An article attributes CVE-2026-69880, CVSS 9.8, to memory corruption and remote code execution in Emerson Ovation DCS. I could not verify a matching NVD record or a primary Emerson or CISA advisory for that product-CVE pairing. Treat the claim as unconfirmed until an authoritative advisory supports it; do not use the article alone as a patch instruction. (Claimed report.)
• A report describes CVE-2026-76880 as a Siemens SIMATIC Energy Manager OPC UA remote-code-execution flaw. NVD instead identifies the CVE as a Wireshark RRC protocol-dissector denial-of-service issue, with a CNA-provided CVSS 3.1 score of 7.5. The NVD record does not support the Siemens product mapping. (Claimed report; NVD record.)
• A report attributes CVE-2026-72840, CVSS 8.6, to a Yokogawa CENTUM VP denial-of-service flaw. NVD identifies that CVE as an OpenWrt LuCI issue involving overly permissive access controls, with a CNA-provided CVSS 4.0 score of 8.7-not as a Yokogawa vulnerability. (Claimed report; NVD record.)

This correction does not make OT security less important. It makes disciplined asset identification and source validation more important. A vulnerability only helps you prioritize when you know which product and version it affects. And a vulnerability list, accurate or not, cannot substitute for knowing what is installed in your own facility.

The coalition’s policy request is not a contractor obligation

The OT Cybersecurity Coalition asked CISA to issue a binding operational directive establishing baseline OT security across federal civilian agencies. The coalition cited poor compliance with existing OT inventory requirements and proposed measures that include asset visibility, segmentation, controlled remote access, configuration baselines, incident readiness, and verified backups. The request is a policy proposal, not an issued CISA directive. (Coalition statement; report on the request.)

A binding operational directive is a formal direction from CISA to applicable federal civilian agencies. The coalition is asking CISA to create one for OT. It is not imposing a new duty on federal contractors. Contractors should read the request as a signal of the direction federal agencies may take, not as a current contractor mandate.

The request also underscores a basic operational problem: inventories are often incomplete even where requirements already exist. For contractors, the practical response is to improve their own inventory and boundary evidence, while separately confirming which obligations actually apply to their contracts.

Zero trust needs an OT-specific implementation

The NSA has published guidance urging zero-trust controls to protect Department of War operational technology. It is guidance, not a new mandate. The document emphasizes asset inventory, network visibility, segmentation, and secure remote access, including for legacy environments. (NSA guidance; coverage.)

In OT, zero trust cannot mean installing an agent on every controller or continuously changing access in ways that interrupt a process. It means verifying people, devices, and connections as far as the environment allows, then using compensating controls where it does not. A protected gateway, segmented zone, time-limited vendor session, and passive monitoring may be safer and more practical than an intrusive change to a fragile controller.

The principle is not “copy an IT design.” It is “remove unnecessary trust while preserving safe operations.” CISA’s guidance on adapting zero trust to OT likewise recognizes that OT has distinct constraints.

When a controller cannot be patched

Contractors ask me what to do when a controller cannot be patched, and my honest answer is that it depends, and there is a way to walk through deciding.

If the work sits inside a DoD RMF effort, we might document a formal risk acceptance and then build compensating controls to monitor that asset closely. The risk decision is owned, written down, revisited on a schedule, and paired with monitoring that would actually detect a problem. If the engagement is not directly supporting Department of War work, a lifecycle replacement plan is often the better path: accept the risk in the near term, plan the replacement into the budget cycle, and stop pretending the controller will be patched someday. The point is not that one answer is right. It is that the decision belongs to a documented process, not to a shrug. What is never acceptable is an unpatchable controller that nobody has assessed, nobody owns, and nobody monitors.

Facility requirements and the evidence they call for

Contractors supporting Department of War facilities may already face facility-related cybersecurity requirements. These include the DoW Control Systems/OT Security Requirements Guide, UFC 4-010-06, and UFGS 25 05 11. The precise applicability depends on the project, system, contract, and governing requirements.

For applicable systems, the work includes determining the impact rating and preparing system documentation and technical controls that support the Risk Management Framework process. That can help a system become technically capable of receiving an Authority to Operate (ATO). It does not itself grant an ATO: the authorized government officials make that decision. H&V does not issue ATOs.

There is evidence that this is not merely a theoretical need. The U.S. Army Corps of Engineers’ Huntsville Engineering and Support Center has sought technical and programmatic support that includes cybersecurity and facility-control-system inventories. (SAM.gov notice; USACE Operational Technology Division.)

I have also seen what happens when this scope gets taken seriously too late. A client of mine came close to losing a federal contract because of a facility-side gap in their control-system documentation, not because the equipment was insecure, but because nobody could produce the evidence that it was characterized, owned, and controlled. The near miss cost them a scramble to produce documentation under deadline, and it permanently changed how they scope facility work. The lesson I took from it is the one I pass on: the evidence burden for facility systems is real, and it arrives whether or not you prepared for it.

A useful FRCS inventory and evidence practice should cover:

• Asset identification: equipment, location, owner, version, function, and criticality.
• Network boundaries: how IT and OT connect, and which routes are allowed.
• Vendor access: who connects, through which path, under what approval, and with what logging.
• Vulnerability management: risk-based review, safe testing, maintenance windows, and documented compensating controls where patching cannot happen immediately.
• OT-aware monitoring: visibility into protocols, connections, configuration changes, and unusual activity.
• Design evidence: diagrams, specifications, configuration records, test results, and change documentation.

Supply-chain controls add another dimension. The DoW class-deviation framework includes restrictions related to certain foreign-made unmanned aircraft systems and specified components, as well as covered semiconductor products and services involving entities that knowingly supply Huawei. Coverage depends on the applicable clauses and exceptions; it should not be generalized into a blanket ban on every product that contains a particular component. The official DoW class-deviation page is the appropriate place to verify the current text. Alongside OT vulnerabilities and CUI obligations, these restrictions show why facility environments carry both information-security and operational-resilience responsibilities.

Tier 3: Audit first, plan second, select tools third

A compliance tool is not a compliance process. A platform can help collect evidence and map controls; it cannot decide whether your building automation system belongs inside the boundary, establish what an undocumented controller does, or resolve a disagreement between facilities and IT about ownership.

Start with an audit of the environment. Then build a plan that defines the boundary, owners, priorities, controls, and evidence. Select tools after those decisions are made.

That is the model behind H&V Complynt. The Complynt platform supports automated control mapping, evidence collection, continuous monitoring, pre-built content packs, and policy-as-code across more than 150 frameworks. Our advisory work adds expertise for complex facility and control-system environments, including systems that do not behave like ordinary IT assets. Learn more about RMF Division 25 and FRCS hardening.

Complynt runs on FedRAMP High and DoD IL5 authorized infrastructure on Palantir’s federal cloud. That authorization applies to the hosting environment; it does not authorize or certify your organization. H&V does not issue certifications, guarantee assessment outcomes, or issue ATOs.

The sequence remains essential: audit first, build the plan, then select tools. Automation can help you maintain a sound scope and its evidence. It cannot determine the scope for you.

What to do this week

• Walk the facility. Do not assess it from the network diagram, because the diagram is the least reliable document on site.
• Treat the existing asset inventory as a hypothesis, not a record, and verify it physically.
• Pull the installed as-builts and compare them against the original submittals, and expect the two to disagree.
• List building automation, HVAC, access-control, and other control systems connected to or supporting the CUI environment.
• Trace their network paths and identify vendor or integrator remote access, including who approved it and whether it is logged.
• Record an owner, function, version, and classification rationale for each identified asset.
• Check vulnerability claims against vendor advisories and authoritative CVE records before assigning remediation priority.
• Where a controller cannot be patched, decide deliberately: risk acceptance with compensating monitoring inside an RMF effort, or a lifecycle replacement plan outside one. Document which, and revisit it.
• Budget weeks, not days, for the inventory if legacy systems are involved.

FAQ

Does the OT Coalition’s CISA request create a new contractor requirement?

No. The coalition asked CISA to issue a directive for federal civilian agencies. That request is not itself a directive, and it does not create a new obligation for contractors.

Is every building system automatically part of a CMMC assessment boundary?

No. Assess the system’s function, connections, and ability to handle CUI or affect systems that protect it. Document the classification and rationale; do not include or exclude equipment solely because it is “facilities” or “IT.”

Does the NSA zero-trust publication create a new Department of War mandate?

No. It is guidance. It offers approaches for improving OT security, including in legacy environments, but should not be represented as a new mandate.

If an OT system cannot be patched immediately, is that automatically noncompliance?

Not automatically. Inside a DoD RMF effort, a documented risk acceptance with compensating controls and monitoring may be appropriate. Outside that context, a lifecycle replacement plan is often the better path. Either way the decision must be documented, owned, and revisited.

How long does an OT inventory actually take?

Weeks, not days, especially with legacy systems. You are tracing networks that nobody documented, sometimes across decades of change. Contractors who budget a two-day walk-through are budgeting the wrong exercise.

Are network diagrams reliable evidence for scoping?

Rarely. Installed as-builts frequently differ from the original submittals and often go decades without updates, particularly after unpermitted renovation work. Treat diagrams as a starting point for physical verification, not as the record itself.

Can a compliance platform determine whether a facility system is in scope?

No. A platform can support mapping and evidence management, but people must assess the system and make the scoping decision. Audit and plan before selecting tools.

Read next in this series

• The Plant Floor Is the Next Compliance Frontier: FRCS, OT Resilience, and What Contractors Are Missing
• Technical Guide #4: How to Map Your CUI Boundary
• Technical Guide #3: How to Determine Whether You Handle FCI or CUI
• Explore RMF Division 25 and FRCS hardening services

For a first step, use our free readiness check.