OT & ICS for CMMC

Why this guide exists

Most CMMC consulting was designed by people who came from IT security. Operational Technology (OT) and Industrial Control Systems (ICS) environments operate on different assumptions, different protocols, different risk models. Applied without translation, standard CMMC scoping over-protects some OT assets and badly under-protects others — producing engagements that cost too much and certify environments that wouldn't survive a real assessment.

This guide is for contractors with manufacturing floors, R&D test environments, energy infrastructure, water and wastewater facilities, building automation, or any other operational system that touches CUI or generates CUI as a byproduct of its operation. If that describes your environment, the standard CMMC playbook is not enough.

What makes OT/ICS different

Operational technology environments differ from traditional IT environments along several dimensions:

• Availability over confidentiality. The first priority of an OT system is to keep the physical process running. A 30-minute outage to apply a security patch can mean a 30-minute production halt costing tens of thousands of dollars. IT controls that assume routine patching and reboot windows don't translate.
• Legacy hardware with long lifespans. A PLC installed in 2008 is often expected to run for another 15 years. The hardware predates modern authentication, modern encryption, modern logging, and sometimes modern operating systems. Bolt-on security is what's available.
• Specialized protocols. Modbus, DNP3, OPC, EtherNet/IP, PROFINET — OT protocols that were not designed with security in mind. Most IT security tools cannot natively inspect or protect these protocols.
• Vendor-controlled environments. Many ICS systems are maintained by the vendor under support contracts that explicitly prohibit modification. Patching, configuration changes, monitoring agent installation may void warranties or violate support agreements.
• Real-world consequences. The wrong configuration change can damage equipment, harm operators, or take down a facility. Security testing that is routine in IT environments — vulnerability scanning, penetration testing — is sometimes physically dangerous in OT.

The standards that actually apply

Three standards govern OT/ICS security in the CMMC context:

NIST SP 800-82 Rev. 3

NIST SP 800-82 Rev. 3 (published 2023) is the foundational federal guidance for OT/ICS security. It provides the OT-specific overlay to NIST SP 800-53 controls and addresses the operational realities listed above. For CUI-handling OT environments, 800-82 is the reference document — not 800-171.

Critical sections include the Purdue Enterprise Reference Architecture (zones 0-5), guidance on safety instrumented systems, and the chapter on industrial control system security architecture. Read these three sections before designing any OT/ICS protection scheme.

ISA/IEC 62443

The international standard for industrial automation and control system security. The most relevant part is 62443-3-3, which defines the seven foundational requirements (FR1 through FR7) and the security level capabilities. 62443's zone and conduit model is the de facto architectural approach for OT segmentation and is referenced extensively in 800-82 Rev. 3.

For DoD facility-related work, ISA/IEC 62443 is increasingly the architectural language assessors expect to hear.

UFC 4-010-06

The DoD's Unified Facilities Criteria for Cybersecurity of Facility-Related Control Systems. Mandatory for DoD installations and increasingly referenced in defense contractor environments that mirror DoD facility patterns. UFC 4-010-06 codifies 800-82 and ISA 62443 patterns into specific design requirements for facility control systems.

The Purdue model, in practical terms

The Purdue Enterprise Reference Architecture defines six logical zones from the physical process at Level 0 to enterprise IT at Level 5:

• Level 0: Physical process (sensors, actuators, the actual equipment)
• Level 1: Basic control (PLCs, RTUs, control loops)
• Level 2: Supervisory control (HMIs, SCADA workstations)
• Level 3: Manufacturing operations (historians, MES, operations management)
• Level 3.5: The Industrial DMZ — the buffer zone between OT and IT
• Level 4-5: Enterprise IT (corporate network, ERP, business systems)

The architectural principle: traffic between levels must traverse the Industrial DMZ (Level 3.5). There should be no direct connections between the SCADA workstation at Level 2 and the corporate user laptop at Level 4. Where there are, that's where most contractor environments fail OT security assessment.

The CUI question in OT environments

OT systems generate, transmit, and store data. Whether that data is CUI depends on its content and on contract language. Common scenarios:

• Manufacturing telemetry from production lines building defense-articles is often considered Controlled Technical Information (CTI), a CUI category.
• R&D test bed data from environments developing classified or controlled systems frequently meets the CUI threshold.
• Configuration data describing the control system architecture itself may be Operations Security (OPSEC) related CUI.
• Process parameters for specialized chemical, biological, or weapons manufacturing processes are commonly export-controlled and subject to ITAR/EAR.

The first scoping question for any OT environment: does the data inside this system meet the CUI threshold? If yes, the system is in scope for CMMC and the OT-specific overlays apply. If no, the system can be scoped out, and the boundary needs to be defensible.

The three common scoping mistakes

Mistake 1: Treating all OT as in-scope

Contractors with manufacturing floors sometimes scope the entire plant floor as CUI-handling. The result: enormous scope, enormous engagement cost, and controls that don't actually map to the plant's operational requirements. The right move is to identify which specific systems actually touch CUI (often a small subset) and scope accordingly.

Mistake 2: Treating OT like IT

Applying IT controls directly to OT — deploying EDR agents on a PLC, running vulnerability scans against an HMI during production hours, requiring MFA for a SCADA login that needs to work during an emergency — produces broken environments. The right move is to apply NIST 800-82 Rev. 3 controls and use compensating measures where direct IT controls don't translate.

Mistake 3: Ignoring the IT/OT boundary

The Industrial DMZ at Purdue Level 3.5 is where most real CMMC assessment friction in OT environments happens. Contractors without a clearly architected and well-monitored boundary between OT and IT cannot defensibly scope OT in or out — the boundary itself is what makes the scoping defensible.

Architectural moves that work

Patterns we see succeed in OT/ICS environments under CMMC assessment:

• Explicit segmentation with documented zones and conduits. Network diagrams that show ISA/IEC 62443 zones, with named conduits between zones documented in the SSP. Conduits enumerate protocols, endpoints, monitoring, and access controls.
• OT-aware monitoring at the boundary. Cisco Cyber Vision, Claroty, Tenable OT, Dragos — passive OT monitoring tools that inspect industrial protocols without interfering with operations. Sit at the Industrial DMZ and watch what crosses.
• Read-only data extraction. Where OT data needs to flow to corporate (production reports, historian queries), use one-way data diodes or read-only paths to extract data without exposing the OT network to inbound traffic.
• Jump servers for OT administration. No direct access from corporate IT to OT control systems. All administrative access goes through a hardened jump server in the Industrial DMZ with MFA, session recording, and just-in-time access provisioning.
• Configuration backups and change management. The single highest-value OT security control we see in actual incidents is good configuration backup hygiene with documented change management. PLCs and controllers that have known-good configurations stored and the discipline to verify them.

Where Praedyn typically plugs in

Most CMMC consultants will tell you they "support OT environments." Few actually have the operational background to walk a plant floor, identify the in-scope systems, and design the segmentation. Praedyn's OT/ICS work draws on direct incident-recovery experience — multi-day SCADA recovery on AVEVA System Platform environments, STIG-hardened Windows Server 2022 in process-control roles, secedit policy rollbacks after misapplied STIG baselines, and the specific failure modes that come from applying IT security baselines to OT systems without translation.

If your environment includes meaningful OT/ICS, the OT & ICS Scope Architecture engagement is usually the right place to start — either standalone or run in parallel with a broader CMMC Readiness Assessment.