# Why OT Security Is The New Priority for Defense Manufacturers > Secure manufacturing systems while meeting DFARS and CMMC requirements. Includes NIST 800-82 best practices, incident response planning, and a phased 90-day implementation roadmap. canonical: https://secureframe.com/blog/ot-security If you're a defense contractor managing manufacturing operations, you've likely mapped IT systems, implemented safeguards to protect CUI, and completed security assessments. But while NIST 800-171 compliance protects sensitive data, it doesn't protect the manufacturing systems that are vulnerable to compromise.  The Pentagon is starting to care more and more about this gap. The [DoD's Brilliant at the Basics campaign](https://secureframe.com/blog/brilliant-at-the-basics) features an OT security Top Ten list, and DoD CIO Kirsten Davies has highlighted the need for CMMC to address OT within the framework. As Davies [said in June](https://govciomedia.com/dow-cio-says-there-is-work-to-do-on-cmmc/), “Operational technology is so critical right now, and nowhere in CMMC was there even a mention of how to build cyber resilience for a manufacturing line.” This article covers what you need to do under current DFARS obligations, what the Pentagon is signaling about emerging requirements, and how to implement OT security best practices without disrupting production. ## How DFARS and CMMC apply to OT today ## How DFARS and CMMC apply to OT today [DFARS 252.204-7012](https://www.acquisition.gov/dfars/252.204-7012-safeguarding-covered-defense-information-and-cyber-incident-reporting.) requires applicable contractors to protect covered defense information on covered contractor information systems by implementing NIST 800-171. Because the requirement is tied to the contract and the information a system handles, OT is not automatically in or out of scope. An OT asset may fall within the covered system boundary if it processes, stores, or transmits covered defense information. Other assets may also be relevant when they protect the in-scope environment, such as identity services, firewalls, monitoring platforms, and vulnerability management systems. For example, an engineering workstation that receives CUI drawings and transfers production instructions to a controller may be in scope. An isolated manufacturing cell that never handles covered defense information may fall outside the boundary. In either case, you should document the asset’s data flows, connections, users, dependencies, and security role rather than relying on labels like “factory network” or “isolated system.” CMMC doesn’t add a separate set of OT-specific controls, but OT assets can still fall within the assessment scope. How an asset is assessed depends on its role and classification under the CMMC scoping guidance. A CUI asset, security protection asset, and specialized OT asset may have different documentation and assessment requirements. Use the Department’s current [CMMC scoping guidance](https://dodcio.defense.gov/CMMC/Resources-Documentation/), your system architecture, and your contract requirements to define your boundary, and confirm the clauses, versions, deviations, and safeguarding requirements that apply to each contract. ### What’s signaling future direction The Department has not published a new set of OT-specific CMMC requirements. However, it’s recently showing increased attention to manufacturing resilience and cyber-physical risk. Brilliant at the Basics** **includes an OT security Top 10, and the Department has publicly identified OT resilience as a gap in the current CMMC framework. At the same time, the Department [paused the transition to CMMC Phase 2](https://secureframe.com/blog/cmmc-news-2026-phase-2-pause) in July 2026 while a reform task force reviews the program. The Department says that review will consider how to replace compliance burden with more scalable, resilient cybersecurity measures, but it has not confirmed whether the revised program will add OT-specific requirements. For now, contractors should be guided by the requirements in their contracts, CMMC assessment obligations, and voluntary measures that strengthen production resilience. Current DFARS and NIST safeguarding requirements don’t make every OT best practice mandatory across every manufacturing system. ## Recommended reading A Guide to the DFARS Clauses Behind CMMC & How They’ve Changed in 2026 ## Asset discovery and contractual scope ## Start with asset discovery and determine your contractual scope You can’t protect what you don’t track. Document every OT component: PLCs, SCADA servers, HMIs, sensors, network infrastructure, and control logic. For each asset, capture owner, model, firmware version, network location, criticality level, support status, approved communications patterns, recovery dependencies, and replacement or risk treatment plan.  Next, determine which assets fall within your covered contractor information-system boundary using current CMMC scoping guidance and your documented system architecture. A system processing, storing, or transmitting covered defense information must implement applicable NIST 800-171 controls.  To clarify which NIST controls apply, document this contractual boundary by referencing the exact DFARS clause, the information systems and data flows it covers, and the OT systems within scope. ## OT security best practices for defense contractors ## OT security best practices for defense contractors Once you understand which OT assets fall within your contractual and compliance scope, the next challenge is protecting them without disrupting production or creating new safety risks. An effective OT security program can’t simply copy the tools and processes used in corporate IT. Controls must account for legacy equipment, specialized protocols, maintenance requirements, physical processes, and the consequences of taking critical systems offline. The best practices below align with guidance from [NIST 800-82](https://csrc.nist.gov/pubs/sp/800/82/r3/final) and the [Brilliant at the Basics OT Top 10](https://dowcio.war.gov/BrilliantBasics/). Not every measure is a contractual requirement for every manufacturing system, so tailor your approach to your environment, applicable contracts, production dependencies, and mission consequences. ## Recommended reading A Guide to the NIST 800 Series: Purpose & Who Should Comply ## Network segmentation ## Build network segmentation around mission consequence Physical or logical isolation reduces network-based exposure, but it doesn’t eliminate risk. Segmented networks still require controlled media, maintenance procedures, identity management, monitoring, and change-management practices. 1. Typical defense contractor architectures include three main segments: Corporate IT for business systems, email, and file storage 2. A demilitarized zone or secure gateway hosting monitoring dashboards and remote access controls, and 3. Production OT housing manufacturing systems, PLCs, and SCADA controllers  Traffic flows between these zones through firewalls and access control lists enforcing allowed communications. Within production OT, implement segmentation based on mission consequence. A critical assembly line that would halt production if compromised should operate in its own network zone with tighter access controls than non-critical manufacturing cells. Try to avoid rigid categorization, though: a test cell can be mission-critical if failure delays a qualification test or contractual delivery. Separate systems supporting safe shutdown, emergency procedures, or interlocks from systems that support routine production. This prevents compromised production controls from also compromising safety functions. It’s also important to create a dedicated third-party access zone. Vendor laptops, maintenance terminals, and remote-access sessions connect through this zone, not directly to production systems. Require authentication, time-bound credentials, and detailed logging. Lastly, establish controls for removable media, engineering workstations used to program or reconfigure controllers, physical access to network closets and control cabinets, and maintenance activities, since these are common compromise pathways. ## Identity, access control, and change management ## Strengthen identity, access control, and change management Access to OT systems should be tied to an individual user and a defined business need. Give each user a named account, remove shared and default credentials wherever possible, and limit privileges to what the person needs for their assigned role. This makes it easier to determine who accessed a system, what they changed, and whether that activity was authorized. Remote access requires additional protection because it creates a pathway from outside the production environment to critical systems. Require multi-factor authentication for connections to OT gateways and other sensitive entry points. Some legacy equipment can’t support MFA directly, so access may need to pass through a secure bastion or jump server that can enforce it. Record activity through that system and review the logs for unauthorized or unexpected behavior. Vendor and maintenance access should also be temporary rather than permanent. Instead of leaving third-party accounts active indefinitely, issue credentials for an approved maintenance window and configure them to expire when the work is complete. Record who requested and approved the access, which systems the vendor can reach, and what occurred during the session. The same level of control should apply to system changes. Updates to controller logic, security configurations, production recipes, or network rules can affect equipment availability and worker safety. Document proposed changes, test them in an isolated environment when possible, and require review from the appropriate OT, engineering, and safety owners before production deployment. Removable media and engineering workstations require particular attention because they can introduce malware or make direct changes to production equipment. Define which media is authorized, where it can be used, and how it must be scanned before entering the OT environment. Restrict personal USB drives and protect engineering workstations with authentication, compatible endpoint security, and monitoring. These workstations can modify PLC firmware and production logic, which makes them some of the most consequential assets on the production floor. ## Continuous monitoring ## Establish continuous monitoring without disrupting production OT teams need visibility into device health, network activity, and potential threats, but the monitoring itself shouldn’t interfere with production. Passive network monitoring is usually the safest place to start because it observes traffic and device behavior without sending additional requests to sensitive equipment. Active scanning requires more caution. Tools designed for conventional IT environments can overwhelm older devices, interrupt control communications, or cause unexpected equipment behavior. Before introducing active scanning or probing, review the proposed activity with engineering and operations teams and test it in a lab or controlled environment. Once monitoring is in place, focus on activity that could create a meaningful operational impact. This may include lateral movement between network zones, unauthorized devices, unexpected vendor sessions, failed authentication attempts, unusual transfers from OT to external networks, and firmware or configuration changes that bypass the approved change process. A baseline of normal communication patterns makes those events easier to recognize. Work with production personnel to understand which systems normally communicate, when maintenance activity occurs, and what legitimate exceptions look like. If alerts repeatedly flag authorized activity, operators will eventually stop treating them as useful. Detection priorities should reflect the consequences of an event, not an arbitrary expectation that every anomaly must be identified in real time. An attempt to change controller logic or cross into a safety-critical zone may require an immediate alert. Lower-risk deviations may be investigated over a longer period. Monitoring records also need appropriate protection and retention. Preserve logs in a way that limits unauthorized modification, and set retention periods based on contractual obligations, operational risk, investigative needs, and storage capacity. If a reportable DFARS incident occurs, additional evidence-preservation requirements may apply. ## Backup, recovery, and incident response ## Build backup, recovery, and incident response around OT realities Recovering an OT environment usually requires more than restoring conventional servers. Production may depend on controller logic, recipes, engineering project files, HMI and SCADA configurations, safety-system settings, software licenses, golden images, and vendor-specific tools. If those materials are missing or outdated, recovery can take significantly longer than expected. Start by identifying everything needed to rebuild each critical process, including dependencies that may not be obvious during normal operation. Protect recovery materials from unauthorized changes and keep the credentials needed to access them separate from the production environment. The only way to know whether those materials are complete is to test them. Restoration exercises should confirm that backups can be accessed, controller logic and configurations are authentic, required software and licenses remain available, and operations and engineering personnel can return the process to service safely. Testing should occur at a frequency that reflects the system’s risk and after material changes to the environment. Some legacy or highly specialized systems may be difficult to back up or restore. In those cases, develop manual-operation or degraded-operation procedures that can keep essential work moving. Shutdown, isolation, restart, and manual-control procedures can be tested through tabletop exercises, simulations, or controlled maintenance windows approved by operations and safety personnel. Incident response should account for these same operational dependencies. A response plan that focuses only on containing malware may overlook the consequences of disconnecting a controller, interrupting a safety function, or shutting down equipment in the wrong sequence. Security, operations, engineering, legal, compliance, and leadership should understand their roles before an incident occurs. ### DFARS incident reporting requirements [DFARS 252.204-7012](https://www.acquisition.gov/dfars/252.204-7012-safeguarding-covered-defense-information-and-cyber-incident-reporting.) requires reporting within 72 hours when a contractor discovers a cyber incident that meets the conditions in the clause. Those conditions include incidents affecting a covered contractor information system or covered defense information, as well as incidents affecting the ability to perform requirements specifically designated in the contract as operationally critical support. The clause also requires contractors to preserve identified system images and relevant monitoring or packet-capture data for at least 90 days after submitting the report. When malicious software is discovered and isolated in connection with a reported incident, follow the applicable DC3 or contracting-officer instructions. Your response process should make it clear who determines whether an incident is reportable, who submits the report, what evidence must be preserved, and when the prime contractor must be notified. Prime notification does not replace a direct reporting obligation. Test the decision process through recurring [tabletop exercises](https://secureframe.com/blog/cybersecurity-tabletop-exercises) so gaps can be corrected before a real incident forces the team to make those decisions under pressure. ## Supply chain risk management ## Manage legacy OT and supply-chain risk Many defense manufacturers rely on OT systems that can’t be patched, upgraded, or replaced without affecting production, safety, vendor support, or equipment certification. The goal is to understand those constraints and reduce the resulting exposure until the system can be remediated or replaced. For critical legacy equipment, compensating controls may include physical or logical isolation, tightly restricted communications, passive monitoring of inbound and outbound traffic, a secure gateway for external access, and stronger controls over removable media and maintenance activity. The right combination will depend on how the asset operates and the consequences if it’s compromised. Document why each legacy system remains in service, the risks it creates, and the controls being used to reduce those risks. The record should also identify an owner and a timeline or trigger for replacement, upgrade, or further treatment. This keeps temporary exceptions from becoming permanent by default. Suppliers can introduce similar risks through equipment, software, firmware, maintenance tools, and remote connections. Before purchasing or deploying a product, consider what the supplier can provide about its secure development practices, vulnerability-disclosure process, software components, patch availability, and end-of-support plans. Test new software and firmware in an isolated environment before introducing them to production. Vendor agreements can reinforce those expectations by defining how quickly suppliers must disclose vulnerabilities, provide patches, report incidents, and notify customers about end-of-support dates. They should also require vendors to follow your access-control and change-management procedures when performing maintenance. When a vulnerability is disclosed, avoid prioritizing it by severity score alone. Consider whether the affected asset is exposed, whether the vulnerability is exploitable in your environment, what process or safety consequence it could create, which compensating controls are already in place, and whether a patch can be tested and deployed safely. If immediate remediation would create greater operational risk, document the decision and monitor the compensating controls until a safer fix is available. ## Brilliant at the Basics OT Top 10 ## Apply the Brilliant at the Basics OT Top 10 The DoD’s[ Brilliant at the Basics OT Top 10](https://dowcio.war.gov/brilliantbasics/) reflects a broader view of cybersecurity than just protecting CUI. It focuses on the conditions that allow defense manufacturers to keep operating through a cyber disruption: knowing what’s connected, limiting access and movement, detecting unauthorized activity, recovering critical processes, and managing risks introduced by suppliers and legacy equipment. For contractors, the campaign offers a useful baseline for deciding where to focus first. It’s important to note that Brilliant at the Basics is not a compliance standard, and completing all ten practices does not establish CMMC compliance. The campaign is designed to help improve production resilience, worker safety, and reliable delivery within the defense supply chain. **1. Identity and access control **Implement named accounts, multi-factor authentication for remote access, and role-based access control. **2. Validated asset inventory **Maintain a living inventory of OT assets with owner, model, firmware, network location, criticality, support status, and replacement or risk-treatment plan. **3. Strict network segmentation **Separate IT, OT, safety, and vendor-access pathways through firewalls and access control lists. **4. OT-specific incident response and recovery plan **Document safe-shutdown procedures, backup and restoration processes, and DFARS incident-reporting decision tree. **5. Manage known vulnerabilities **Monitor CISA advisories and vendor bulletins. Prioritize remediation based on exploitability, exposure, process consequence, and compensating controls. **6. Remote access pathways **Create a dedicated vendor-access zone with authentication, time-bound credentials, and detailed logging. **7. Continuous monitoring **Use passive network monitoring to establish baselines and detect anomalies. **8. System resiliency **Back up controller logic, configurations, recipes, and engineering files. Test restoration at risk-based frequency. **9. Supply chain security **Vet suppliers and establish security requirements in vendor contracts. **10. Review processes **Establish formal change-management procedures with authorization before production deployment. ## 90-day OT security roadmap ## A 90-day OT security roadmap If you’re not sure where to begin, use the first 90 days to move through three stages: understand the environment, design the improvements, and validate that they work. The goal isn’t to secure every OT system in three months. It’s to replace assumptions with a reliable baseline, address the most consequential exposures, and create an accountable plan for the work that remains. Adjust the timeline to reflect your plant’s complexity, production schedule, engineering resources, safety-review process, and contractual deadlines. Changes that could affect physical operations should move only as quickly as they can be evaluated and tested safely. ### Days 1–30: Understand the environment ```
``` Spend the first month establishing what is operating, how it is connected, and which assets matter most. Build or validate an inventory that covers OT hardware, firmware, software, control logic, and external connections. For each asset, identify an owner, operational function, criticality, support status, and recovery or replacement needs. At the same time, map the network topology and important data flows. Identify which assets process, store, transmit, or protect covered defense information, and document how they fit within the applicable contractual and CMMC boundary. Pay particular attention to connections that may not be centrally managed, including IT-to-OT pathways, internet access, vendor connections, wireless networks, and removable media. By the end of the first 30 days, you should have an initial asset inventory, a current-state network diagram, a documented scope, and a prioritized view of its highest-consequence risks. ### Days 31–60: Design the improvements ```