Manufacturing cybersecurity is moving from perimeter protection toward a broader resilience model that connects industrial assets, enterprise dependencies, suppliers, recovery capabilities, and operational decision-making.
Research scope: This article examines the relationship between OT security, manufacturing resilience, IT/OT convergence, asset visibility, segmentation, recovery, and supply-chain dependencies. It is an analytical research article, not a report of a specific Kairos Vector client engagement.
Executive Summary
The security boundary around a manufacturing operation is no longer defined only by the plant network. Production depends on a wider technical and organizational ecosystem: industrial control systems, engineering workstations, identity services, enterprise applications, remote support, data platforms, suppliers, software, and recovery infrastructure.
This does not mean every connected system should be treated as an OT asset. It means that cybersecurity analysis needs to follow operational dependencies. A system outside the control network can still become relevant if its compromise prevents engineers from operating equipment, disrupts production planning, removes access to critical data, or blocks recovery activities.
NIST’s 2026 manufacturing work makes this shift particularly clear. Its initial public draft of SP 1800-41 focuses on responding to and recovering from cyberattacks in manufacturing ICS environments, with the explicit objective of improving operational resilience. NIST also published SP 1339 in June 2026, emphasizing the role of OT backup management in recovery. NIST SP 1800-41 and NIST SP 1339.
Research Finding 1: The Factory Floor Is Only One Part of the Risk Boundary
Traditional OT security programs often begin with a network boundary. The organization identifies the control network, separates it from enterprise IT, restricts traffic, and monitors the resulting architecture. That remains important, but it does not describe the complete operational dependency chain.
A manufacturing line can depend on engineering workstations for configuration, identity services for authentication, file services for engineering documentation, historians for process data, virtualization infrastructure for industrial applications, and enterprise systems for planning or maintenance. Remote support may introduce another dependency through a supplier or system integrator.
NIST has previously documented the productivity benefits and security consequences of connecting IT and OT networks in manufacturing environments. Its manufacturing guidance describes how increased connectivity and remote access can improve business processes while also creating opportunities for attackers to exploit weaknesses affecting ICS and ICS data.
Research implication: The relevant question is not simply “Is the OT network isolated?” It is “Which dependencies can affect the safe and reliable operation, monitoring, maintenance, or recovery of the industrial process?”
The Modern Manufacturing Dependency Chain
Figure 1. A conceptual dependency model for manufacturing cyber resilience. The layers are analytical categories, not a universal plant architecture.
Research Finding 2: Asset Inventory Is Becoming a Resilience Capability
Asset inventory is sometimes treated as an administrative requirement. In an OT environment, it is much more consequential. During an incident, responders need to know what a system is, where it is located, what process it supports, who owns it, what it communicates with, and what dependencies are required to restore it.
CISA and partner agencies published Foundations for OT Cybersecurity: Asset Inventory in August 2025. The guidance focuses on identifying and classifying OT assets and provides a foundation for understanding criticality and dependencies. The document also distinguishes asset inventory from safety analysis, making clear that the inventory guidance does not itself address OT safety topics.
| Inventory attribute | Why it matters during resilience planning |
|---|---|
| Asset identity | Prevents responders from confusing similar devices or systems during an incident. |
| Location | Connects digital assets with physical production areas. |
| Owner | Creates accountability for decisions and maintenance. |
| Criticality | Helps prioritize protection and restoration. |
| Communication dependencies | Shows which systems may affect or be affected by an incident. |
| Firmware and software information | Supports vulnerability, lifecycle, and change decisions. |
| Backup information | Helps responders determine whether restoration is possible. |
Research Finding 3: Segmentation Is About Required Communication, Not Just Network Separation
Network segmentation remains a core OT security measure, but a segmentation project can become ineffective if it is based only on IP ranges and firewall rules. The architecture needs to represent the industrial process and the communications that process actually requires.
ISA/IEC 62443-3-2 provides a structured approach for defining a system under consideration, partitioning it into zones and conduits, assessing risk for each zone and conduit, establishing target security levels, and documenting security requirements. This risk-based approach is more useful than treating every OT segment as equally important.
The practical lesson is that segmentation should be designed around business and process requirements. If a communication path is necessary, it should be explicit. If it is unnecessary, it should not exist simply because it has always existed.
Research Finding 4: Recovery Has Become a First-Class OT Security Control
Prevention remains important, but no industrial security architecture can guarantee that an incident will never affect operations. NIST’s manufacturing guidance states that defense-in-depth can mitigate cyber risk without eliminating it, which creates a direct requirement for response and recovery capability.
In May 2026, NIST released the initial public draft of SP 1800-41, specifically addressing response and recovery in manufacturing ICS environments. The project uses reference architectures and attack scenarios in a discrete manufacturing work-cell to demonstrate capabilities including event reporting, log review, event analysis, and incident handling and response.
One month later, NIST published SP 1339, the OT Backup Quick Start Guide. It identifies OT backups as vital for recovery from cyber or reliability incidents and recommends that backup management be integrated into change management, performed regularly, tested, and reviewed during recovery exercises.
Recovery is more than a backup
A recoverable OT environment needs usable backups, restoration procedures, compatible infrastructure, responsible personnel, defined priorities, and exercises that reveal where the recovery process fails.
The OT Recovery Chain
1. Detect
Identify the event and determine which systems, accounts, networks, or processes may be affected.
2. Contain
Limit the incident while protecting safety and avoiding unnecessary disruption to unaffected processes.
3. Restore
Recover systems and configurations in an order determined by operational dependencies and business priorities.
4. Validate
Confirm that restored systems behave as expected before returning affected processes to normal operation.
Research Finding 5: Supply-Chain Risk Does Not Stop at the Vendor Contract
Industrial supply chains introduce dependencies that are easy to overlook in a conventional network assessment. Manufacturers may rely on equipment suppliers, automation vendors, system integrators, software providers, managed services, maintenance contractors, and remote engineering teams.
The security question is not simply whether a supplier has a cybersecurity policy. It is whether the supplier relationship creates a technical or operational dependency that could affect the manufacturing process.
- Who can remotely access industrial systems?
- Which supplier accounts remain active between maintenance activities?
- Which software or firmware updates originate outside the organization?
- Which systems depend on vendor infrastructure for support or authentication?
- Can the organization operate if a critical supplier becomes unavailable?
- Does the recovery plan account for vendor participation?
This makes supplier security part of operational resilience rather than a procurement-only activity. The level of scrutiny should be proportional to the operational dependency and the consequence of compromise.
Research Finding 6: Remote Access Is an Operational Design Problem
Remote access can be essential to modern manufacturing. Vendors and engineers may need to diagnose equipment, maintain software, or support geographically distributed plants. Removing remote access entirely may therefore be impractical.
The better approach is to design remote access as a controlled operational capability. Access should have a defined purpose, accountable ownership, strong authentication, restricted authorization, appropriate monitoring, and a lifecycle that includes removal when the business need ends.
This principle is consistent with the broader OT security approach in NIST SP 800-82, which emphasizes that security controls must account for the unique performance, reliability, and safety requirements of OT environments.
Research Finding 7: Cyber Resilience Needs a Different Measurement Model
Counting vulnerabilities does not provide a complete picture of manufacturing resilience. A plant can have a long vulnerability list while maintaining strong segmentation, controlled access, reliable backups, effective monitoring, and tested recovery procedures. Conversely, a plant with fewer documented vulnerabilities may still have serious resilience gaps if critical dependencies are unknown.
| Measurement | What it reveals |
|---|---|
| Critical OT assets with verified ownership | Whether accountability exists for important systems |
| Critical assets represented in current architecture records | Whether the organization understands its operational topology |
| Approved remote-access paths | How much external access is formally controlled |
| Backup restoration tests completed | Whether backups are actually usable for recovery |
| High-risk findings beyond agreed remediation dates | Where risk acceptance or remediation is stalled |
| Incident-response exercises completed | Whether response procedures work under realistic conditions |
| Expired security exceptions | Whether temporary risk decisions are becoming permanent |
These indicators should not be interpreted as universal benchmarks. Their value comes from showing whether the organization is increasing visibility, reducing unnecessary exposure, and improving its ability to respond and recover.
A Five-Layer OT Cyber Resilience Model
The five layers should not be implemented as independent projects. Visibility informs architecture. Architecture defines access paths. Access and architecture influence monitoring. All four determine how practical recovery will be when a disruptive event occurs.
Why Operational Context Changes Security Decisions
The same technical weakness can represent very different operational risks in two industrial environments. A device that can be safely isolated in one plant may be tightly coupled to a continuous process in another. A maintenance activity that is routine in a discrete manufacturing line may be unacceptable during a constrained production window elsewhere.
This is why OT risk analysis needs participation from people who understand the process. Security teams bring expertise in threats, vulnerabilities, identity, architecture, and detection. Engineering and operations teams understand process dependencies, maintenance constraints, safety requirements, equipment behavior, and acceptable operational states.
A mature resilience program brings those perspectives together before controls are changed. The goal is not to lower the security requirement because operations are inconvenient. It is to select controls that reduce risk without creating an unmanaged operational failure of their own.