OT vs IT: Navigating CMMC Controls in Industrial and Critical Infrastructure Environments

Cybersecurity Maturity Model Certification (CMMC) has introduced a significant evolution in how organizations, particularly government contractors and critical infrastructure operators, are required to manage and demonstrate cybersecurity. While its roots are in safeguarding Controlled Unclassified Information (CUI) as part of U.S. Department of Defense (DoD) contracting, its impact is increasingly felt in Operational Technology (OT) environments. This article aims to clarify, with technical rigor, the friction points, alignments, and divergent architectures between IT (Information Technology) and OT regarding CMMC controls, with practical considerations for CISOs, IT directors, network engineers, and operational personnel.

Table of Contents

• Historical Context: IT and OT Security Paradigms

• CMMC in Brief: Foundations and Evolution

• Dissimilar Architectures: Asset Differences between IT and OT

• Security Controls: Mapping CMMC to OT Realities

• Network Segmentation: The Heart of Secure Connectivity

• IT/OT Collaboration: Bridging the Cultural and Operational Divide

• Deployment Nuances: Where Controls Fit—and Don’t

• Operationalizing Compliance: Pragmatic Recommendations

Historical Context: IT and OT Security Paradigms

The schism between IT and OT is as much historical as technological. IT environments—think enterprise data centers, email servers, and cloud—originated with confidentiality and data integrity as cardinal virtues. When the Morris Worm (1988) and the rise of worms and viruses catalyzed the emergence of antivirus and firewalls, IT quickly adopted a systematic, layered defense.

In contrast, OT — covering everything from DCS in power plants to SCADA in manufacturing — originated with availability and safety as its prime concerns. A plant’s downtime was more costly than data leakage; thus, protocols like Modbus (1979) and serial comms prioritized determinism and uptime over cryptographic hygiene. It wasn’t until the Stuxnet incident in 2010 that the real-world consequences of vulnerable OT systems became public knowledge and galvanized a slow pivot toward cybersecurity in these domains.

Cultural Annotation: Why “If it ain't broke, don’t patch it” Lingers in OT

The legacy in OT is often decades-old equipment running “secure by obscurity” protocols, with vendor lock-in and uptime mandates that make patching a hazardous proposition. This historical inertia must be remembered when shoehorning CMMC controls into OT.

CMMC in Brief: Foundations and Evolution

CMMC emerged to standardize cybersecurity practices across organizations handling CUI within the DoD supply chain. It is an amalgamation of NIST SP 800-171, NIST SP 800-53, and other frameworks, arranged into levels (as of CMMC 2.0: Foundational, Advanced, and Expert).

Of note for OT practitioners: CMMC’s controls assume an IT-centric view. Direct translation into OT is not always feasible without modifications—both technical and operational.

Core CMMC Domains Relevant to OT

• Access Control (AC)

• Asset Management (AM)

• Incident Response (IR)

• System & Communications Protection (SC)

• System and Information Integrity (SI)

Each of these domains possesses controls that may be difficult (or impossible) for legacy OT, especially regarding encryption, patching cycles, and user authentication.

Dissimilar Architectures: Asset Differences between IT and OT

IT and OT networks are fundamentally built using different architectures and design objectives. This matters for practitioners considering CMMC compliance.

Typical IT Architecture

• Hierarchical networks with segmentation via VLANs, firewalls, ACLs.

• User-centric computing, authentication via LDAP/Active Directory.

• Regular patching, employing antivirus/EDR, endpoint logging, and backup routines.

Typical OT Architecture

• Flat networks (historically): limited internal segmentation; many systems, one broadcast domain.

• Devices: PLCs, RTUs, HMIs, historians with limited compute/storage, often without full OSes.

• Protocols: clear-text, deterministic, non-routable (e.g., serial-based); no native authentication/encryption.

• Patching constraints: Only possible during major downtimes; harsh penalties for unplanned changes.

Bottom Line on Asset Management

Asset inventory—the heart of CMMC controls—is straightforward in IT, where tools like Active Directory and SCCM reign. In OT, bespoke tools or manual inventory are often required, as devices may lack SNMP or other discoverable agents.

Security Controls: Mapping CMMC to OT Realities

Not all controls can or should be implemented equally across IT and OT. Here are key considerations for each CMMC-relevant domain.

Access Control (AC)

• IT: AD-integrated accounts, MFA, role-based access with fine-grained control.

• OT: Many controllers lack the concept of user accounts; “admin” is often hard-wired. Implementing RBAC requires compensating controls—think jump hosts, secure enclaves, or network zoning.

System and Communications Protection (SC)

• IT: TLS everywhere, VPN for remote access, e-mail encryption mandatory on sensitive workflows.

• OT: Modbus/TCP, DNP3, and other protocols are natively unencrypted. Retrofits via data diodes, protocol gateways, or VPN tunneling (for new remote access) can help, but retrofitting legacy protocols to support strong encryption is a herculean effort (and may void vendor support).

System and Information Integrity (SI)

• IT: Patch management systems, AV/EDR sweep endpoints hourly/daily. IDS/IPS inline monitoring.

• OT: Many endpoints cannot be patched (vendor risk), nor can traditional AV/EDR be installed. Passive network monitoring, anomaly detection, and logging at perimeter ICS firewalls become compensating controls.

Network Segmentation: The Heart of Secure Connectivity

The Purdue Model for ICS (Industrial Control System) security, proposed in the 1990s, remains valid. It formally divides industrial networks into levels; with IT in Levels 4/5 and OT from Level 3 “Operations/Control” down to Level 0 “Physical Process”.

The Pragmatics of Segmentation Under CMMC

• Segregate IT and OT using firewalls, unidirectional gateways, or at least VLANs with strict ACLs.

• Only allow necessary (documented, risk-assessed) communication between IT and OT zones.

• Restrict remote access via jump hosts or VPNs that enforce comprehensive logging and session recording.

Annotation: Unlike generic IT segmentation, industrial segmentation must account for process-critical traffic—do not block protocols without deep process mapping, or risk unintended shutdowns.

IT/OT Collaboration: Bridging the Cultural and Operational Divide

Historically, IT and OT teams have different priorities and lexicons.

• IT: “Shut it down if there’s malware.”

• OT: “Shutting down the process costs millions and risks safety.”

Fostering Collaboration

• Joint risk committees—include both IT and OT stakeholders in risk assessment and control definition.

• Cross-training—network engineers must understand PLCs, while plant operators should know basic TCP/IP and threat models.

• Define “compensating controls”—if patching is unworkable, double down on monitoring and perimeter defense.

Deployment Nuances: Where Controls Fit—and Don’t

Not every CMMC control makes sense in OT, and in some cases, attempting literal compliance is counterproductive.

• Encryption at Rest: Encrypting PLC firmware or process data can be infeasible. Consider securing physical access and ransomware-resistant backups instead.

• Patching Cadence: Quarterly or biannual patch “windows” are the norm in regulated plants—document this, and ensure monitoring compensates for longer unpatched periods.

• MFA: Most OT protocols lack authentication entirely. Restrict who can access the PLC engineering workstation (jump boxes, physical tokens) instead.

CMMC is not “one-size-fits-all”. Document rationales, seek variances or alternate controls, and avoid bureaucratic or dangerous “checkbox” compliance.

Operationalizing Compliance: Pragmatic Recommendations

• Maintain an up-to-date asset inventory covering both IT and OT; invest in passive discovery tools or manual walks as appropriate.

• Segment IT from OT networks as strictly as process safety and reliability allows. Use firewalls, protocol-aware gateways, and network mapping.

• Enforce least privilege on all operational workstations; close “shared admin” or default manufacturer accounts where feasible.

• Document compensating controls for every CMMC requirement that is partially or wholly impracticable in OT—monitoring, network-based IDS, or procedural restrictions.

• Whitelisting over blacklisting: On OT HMIs and engineering workstations, application whitelisting is usually more viable than traditional AV.

• Resilience drills: Practice incident response for both IT-centric and process-centric scenarios; involve both teams.

Conclusion

The convergence of OT and IT under frameworks like CMMC is a complex, nuanced process. Recognize the technical and cultural differences between environments; advocate for informed, tailored implementations instead of rote control deployments. Remember, uptime and safety trump “checkbox” security—where controls fail, document rigorously and substitute better-context alternatives. Real cybersecurity in critical infrastructure is precise, pragmatic, and collaborative.

References

• NIST SP 800-171: Protecting CUI in Nonfederal Systems

• CMMC: Official CMMC Documentation

• NIST SP 800-82: Guide to Industrial Control Systems (ICS) Security

• ISA/IEC 62443: Security for Industrial Automation and Control Systems

• Purdue Reference Model: ISA Purdue Model

• Moore, T. (2010). The Impact of Stuxnet.

This article is written with a frank, technical perspective—no buzzwords, just reality. If you’re an engineer, operator, or security leader contending with CMMC (and tired of vendor smoke), stay vigilant, stay honest, and document everything.