CMMC Level 2 Requirements for OT & "Specialized Assets": Implications for Industrial Network Security

CISOs, IT Directors, Network Engineers, and Operations professionals in industrial and critical environments are now navigating a rapidly shifting compliance landscape—one underscored by the CMMC (Cybersecurity Maturity Model Certification) framework. As CMMC becomes de facto for U.S. Department of Defense (DoD) contractors, those managing operational technology (OT) and "specialized assets" such as Industrial Control Systems (ICS), SCADA, Building Automation Systems (BAS), medical devices, and embedded controls face unique challenges aligning with CMMC Level 2 requirements. This article offers a technically rigorous exploration of these requirements, annotates historical context, and provides actionable guidance for fortifying specialized infrastructure against evolving threats.

Understanding CMMC: A Brief Historical Footnote

Launched in 2020, the CMMC was born out of frustration: a decade of NIST 800-171 self-attestations, mixed adherence, and repeated Defense Industrial Base (DIB) breaches drove the DoD to enforce supply chain hardening with auditable requirements. The CMMC 2.0 streamlines the original model, focusing Level 2 on the safeguarding of Controlled Unclassified Information (CUI). The goal: raise floor standards above the chronic misconfigurations, piecemeal diligence, and implicit trust commonly found across IT and OT.

Defining "Specialized Assets" in CMMC

CMMC's Assessment Guide introduces the notion of "specialized assets," i.e., systems that cannot readily meet all controls due to technical limitations or operational necessity. This includes factory floor PLCs, DCS, safety instrumented systems, diagnostic medical equipment, and legacy OS endpoints rarely (or never) patched. Here, default CMMC control implementation could jeopardize safety, uptime, or regulatory compliance—recognizing what IT professionals long learned from failed "patch all the things" dogma.

CMMC Level 2: The Technical Core for OT Environments

Level 2 maps nearly 1:1 with NIST SP 800-171 Rev. 2—110 controls across 14 domains. However, in OT environments, many controls interact awkwardly with reality. Let's examine several key domains and their OT implications:

Access Control (AC)

• Multi-Factor Authentication (AC.3.012, AC.3.020): OT assets often lack native MFA support. Workarounds include jump hosts for remote access with MFA enforced upstream, and session management at network perimeters.

• Least Privilege (AC.1.003): Asset-specific accounts (e.g., hard-coded creds in PLCs) must be inventoried; segmentation is typically enforced at the VLAN or firewall-level, with strong logging on device management interfaces.

Audit and Accountability (AU)

• Event Logging (AU.2.041, AU.2.042): Syslog or Windows event logging won't natively exist on many PLCs or RTUs. Forwarding protocol translation, asset gateway polling, or network TAPs for east-west visibility are often required.

System and Communications Protection (SC)

• Encryption Requirements (SC.3.177): Many fieldbus and serial ICS protocols (MODBUS, DNP3) are cleartext by design. When endpoints can’t be upgraded, mediating devices such as data diodes or protocol gateways under strict configuration may satisfy compensating control rationale.

Media Protection (MP), Maintenance (MA), Physical Protection (PE)

• Removable Media Control: Air-gapped or semi-isolated OT networks may rely on USB sneakernet for patching/configuring. Rigorous malware scanning policies must exist, ideally with removable media logging per CMMC expectation.

• Physical Access: Plant floor assets may not support modern badge-forced authentication; control is via site access procedures and video monitoring, informing the CMMC assessment with documented compensations.

Network Architecture: Bridging IT/OT Without Compromising Security

Historically, industrial organizations operated with "security by obscurity" or air-gaps—often illusory because of vendor access, porous remote connections, and shared WANs. Today, segmented network design, the "demilitarized zone" (DMZ) paradigm, and robust monitoring are table stakes.

Tactical Considerations

• Segment OT from IT with managed firewalls—flat LANs have proven disastrous in ransomware propagation (see NotPetya, 2017).

• Apply strict allowlisting for remote protocol flows; block all other traffic by default.

• Deploy jump hosts (bastion servers), enforcing identity/tracking at every cross-boundary step.

• Utilize network monitoring (NetFlow, DPI, or OT-aware IDS) for detection, since many OT endpoints are black boxes with little native visibility.

On Compensating Controls

CMMC assessments will scrutinize justifications for non-standard implementations. The official guide encourages documentation of technical infeasibility, but also expects rigorous network, process, and physical controls in return—not mere verbal assurance.

IT/OT Collaboration: The Cultural & Procedural Delta

The schism between IT and OT—rooted in historically divergent priorities (confidentiality vs. availability/safety)—amplifies CMMC's challenge. Avoiding finger-pointing is key:

• Joint risk assessments must include both IT and plant engineering roles.

• Asset inventories (critical for AC and IR domains) need periodic reconciliation. The “well, we don’t manage that” excuse does not satisfy CMMC reviewers.

• Incident response runbooks ought to address asset-specific recovery and service continuity as much as technical containment.

OT Asset Management: Inventory, Visibility, and Baseline Control

It is impossible to protect what is not inventoried. The CMMC framework heavily relies on accurate, up-to-date asset inventories. Recommendations here include:

• Automated asset discovery tools (passive network inventorying where possible to avoid disruption of sensitive endpoints).

• Tagging non-compliant or “specialized” assets, and correlating them with process diagrams and operational risk profiles.

• Explicit mapping of every asset to a responsible admin, supporting audit and accountability mandates.

Deployment and Maintenance: Patch, Monitor, Document

Patch management remains a perennial weak point in OT—frequent "do not touch" directives from OEMs can clash directly with CMMC. Workarounds include:

• Virtual patching (IDS-in-the-middle or application firewalls to block known exploits).

• Phased testing of updates in labs synchronized with downtime windows.

• Documented exception process, reviewed by IT/OT leadership, and revisited on a scheduled basis.

Human Factors: Training, Procedures, and Accountability

CMMC Level 2 does not ignore the human element—it calls out user awareness, code of conduct, and ongoing security training. This requirement can catch OT teams off-guard, particularly where contract labor or rotating shifts are the norm. Solutions include:

• Custom security training modules specific to OT environments.

• Scenario-driven tabletop exercises, blending IT and OT incident response, to build muscle memory and validate runbooks.

• Logging all privileged changes and physical accesses, backed by electronic sign-off, to drive accountability.

Documentation: The Backbone of Compliance

CMMC audits are as much about paper as they are about packets. Every deviation, control, monitoring process, and exception should be documented—not in a compliance-for-compliance’s-sake way, but as a practical, operationally meaningful record.

Conclusion: From Compliance to Control

Achieving CMMC Level 2 in OT-heavy environments is not a bureaucratic checkbox, but a push toward disciplined, evidence-based security management. It is a chance to break silos, adopt a realistic stance on specialized assets, and deploy modern architectures that defend as well as document. Effective compliance is never “one-size-fits-all”—it is a nuanced journey, demanding honesty about system constraints, creativity in compensating, and relentless focus on operational continuity.

As always, the most resilient organizations are those where IT, OT, security, and operations speak with context and technical precision—because the next audit, incident, or downtime event will not care where your network boundary used to be.