A manufacturer’s cybersecurity priorities must make sense to the people responsible for keeping production running. A recommendation that looks straightforward on an office network may require vendor input, a maintenance window or a different approach on equipment supporting a physical process.
The starting question is therefore broader than “Which devices are vulnerable?” Ask which business and production activities depend on those devices, how people access them, and what a security change could disrupt. IT, engineering, maintenance and plant leadership need a shared view of those decisions.
This guide provides a practical way to organize that work across IT and operational technology, or OT. The examples are hypothetical planning situations, not customer incidents or instructions to make unreviewed changes to production equipment.
Begin with one process and its dependencies
Choose a production process important enough to matter, but small enough that its owners can review it together. Map the systems supporting it: planning applications, engineering workstations, operator interfaces, controllers, network infrastructure, remote support and relevant suppliers.
The CISA and partner OT asset inventory guidance recommends defining scope and responsibilities, collecting asset attributes, organizing assets and maintaining the inventory. An address list alone misses the relationships needed for operational decisions.
For each important asset, capture its function, owner, location, support status, communications and recovery dependencies. Validate the map with the people who use and maintain the equipment. Record unknowns explicitly rather than assuming that an undocumented connection is absent.
For example, a hypothetical packaging line may depend on an office-hosted scheduling service and a vendor-supported engineering workstation. Reviewing the controllers alone would miss both dependencies. The useful output is a shared process map with accountable owners, not simply a larger device count.
Review the boundaries between IT, OT and suppliers
Network separation should be evaluated through the communications that are actually permitted. NIST’s Guide to OT Security discusses segmentation and isolation in the context of operational performance and safety. A diagram labeled “segmented” is not evidence that the intended boundaries are enforced.
Have the responsible teams review required flows and access rules before changing them. Ask which connections support operations, which are temporary, and who approves exceptions. Treat a vendor support route as a business dependency with an owner, rather than an unexplained permanent opening.
For remote access, request a review of who is allowed in, how identity is verified, what systems they can reach and how access is withdrawn. Where feasible and operationally approved, favor individually accountable access and time-bounded authorization over shared, indefinite arrangements. Validate the design with the equipment vendor and plant team; do not infer that an office-network control will suit every device.
Assess and remediate without surprising production
OT assessment methods need explicit approval. NIST SP 800-82 Rev. 3 recommends evaluating scanning effects in an offline environment before production use. Do not launch an unfamiliar scanner or deploy an agent to a production network simply because it is standard in IT.
Start with approved documentation, inventories and existing monitoring evidence. Agree with operational owners what additional discovery is needed, which methods are acceptable and when work can occur. Passive observation also needs approved placement and handling of the information collected; it is not a blanket authorization to monitor any connection.
When a weakness is confirmed, separate the desired treatment from the implementation plan. NIST’s patch management guidance includes preparation and verification as part of managing a change. For plant equipment, ask the team to document vendor compatibility, prerequisites, a rollback method, a suitable window and the acceptance checks required before returning to service.
If a fix must wait, give the exception an owner, interim measures and a review date. “Cannot patch” should start a risk-treatment discussion, not close it. Consider what access can be constrained or monitored while a tested permanent change is prepared, and document what those measures do not address.
Make monitoring useful to both security and operations
Agree what should prompt investigation: unexpected remote access, unapproved engineering activity or a change outside an authorized maintenance window. The joint event logging guidance calls for collaboration between IT and OT personnel and warns that excessive logging can affect constrained OT equipment.
Choose supported telemetry sources and define who reviews them. An alert should contain enough context for an operational owner to decide whether activity is expected. Review maintenance calendars and vendor arrangements alongside detection rules so legitimate work can be distinguished from activity needing investigation.
The MDR evaluation guide explains why response permissions matter as much as monitoring coverage. In a plant, explicitly identify actions that require operational approval. Detection does not create permission to disconnect equipment or interrupt a process.
Practice recovery and decision-making together
Ask how the process would be recovered if a supporting workstation or application became unavailable. Identify the people, configurations, software, vendor assistance and business approvals required. A backup file is useful only within a recovery procedure the organization can carry out.
NIST’s incident response guidance treats response and recovery as coordinated activities and supports exercises with relevant parties. Use a tabletop discussion or a safely scoped recovery test to examine the handoffs; agree the method before involving production assets.
In a hypothetical exercise, loss of a scheduling service might leave the line technically operable but make order sequencing uncertain. That is a business decision for production leadership to resolve with IT, not a question an external analyst should answer alone. Capture the decision, escalation contacts and conditions for returning to normal operation.
Build a roadmap around decisions you can complete
Use the following sequence as an adaptable planning aid, rather than a universal implementation timetable:
- Establish the baseline: select one process, validate its dependencies and name the decision owners.
- Address agreed priorities: review remote access and boundaries, validate important findings and approve suitable remediation plans.
- Verify and sustain: confirm completed changes, exercise one recovery scenario and assign responsibility for keeping the map current.
Track unresolved ownership, overdue exceptions and verified improvements alongside technical findings. Set priorities through cyber exposure management so business impact and remediation constraints remain visible. Keep the manufacturing review scope and incident response responsibilities tied to those dependencies. Expand the work to another process once the first review produces usable decisions.
Reduce risk with operational ownership
Manufacturing security improves when technical evidence and production knowledge lead to agreed action. Start with a bounded process, validate its dependencies and work through assessment, change and recovery decisions with the people accountable for operations. The goal is a defensible, maintainable approach to risk reduction that respects how the plant actually works.