iFAKT GmbH - Manufacturing Cybersecurity - Protecting Plants With Microsoft Defender for IoT 00:00:00 Speaker: Imagine a plant running normally when unexpected traffic hits a controller. The security team wants to investigate, but cutting that connection could interrupt a process that's still running safely. So what should the team do? First, we'll work through asset discovery, safer containment, and where Microsoft security tools fit. Because behind that network alert, there's equipment moving material in process and people who need to stay in control. Before we talk about detection, I'd start with the plant's operating limits. When a security event reaches production, you need to understand which physical functions must keep working while the team decides how to respond. That changes how you frame the problem. Protecting a plant means protecting the ability to control equipment, keep workers safe, and produce goods within the conditions the process actually needs to run correctly. OT versus it the boundary that matters. Operational technology or OT monitors and controls. Physical equipment that includes the systems that read process conditions and send commands to equipment. Where a change in a digital signal can change something on the factory floor. Information technology or it supports business information and services. Those systems increasingly exchange data with production. So an issue in a business service can affect work at the plant, even when the machines themselves remain untouched. The boundary depends on the process, not just the department. A computer might run a familiar operating system, yet support an operator who needs its readings to decide whether equipment can continue running within approved limits. I wouldn't judge that computer by its hardware alone. You need to ask what the process loses if the computer stops responding, and whether the people running that process still have the information and control they need. Why the office laptop playbook doesn't work here. Take a compromised office laptop as a comparison. Your security team might isolate it from the network quickly following an approved response plan, because the expected disruption stays within a known and fairly limited scope. That same action needs a different review around live equipment. If a computer provides process visibility or supports a control function, disconnecting, it could remove something the operator needs while leaving the physical equipment running behind it. The decision still needs urgency. A suspected compromise might threaten the process directly, so the team needs to weigh the risk of allowing communication against the physical effects of cutting IT safety procedures guide that decision. Cybersecurity response needs to work within the plant's established rules for safe operation, with people who understand how the equipment behaves when communication or control becomes unavailable. Product quality delivery and what available actually means product quality creates another set of consequences. A process can keep moving while losing a condition that affects the finished product, which means continued output alone doesn't tell you whether a production remains acceptable. Think about a process that needs a controlled temperature. If operators can no longer trust the reported temperature, they need a way to judge the material already in process, even if the equipment hasn't stopped. Delivery commitments come into this as well. An interruption can affect the order currently running and the work scheduled after it, particularly when the plant has limited room to recover lost production time. Those commitments don't override safety. They do explain why a plant needs response choices that account for the actual process, rather than treating every loss of network access as an acceptable cost. Availability also needs a practical definition. Here. A device that answers a network request might still fail to provide the control or process information that production needs, so simple connectivity won't settle the question. I'd ask what people can still do safely. Can the operator judge the process state? Can the equipment remain within its operating limits, and can the plant determine whether the product meets its requirements? Those questions give security work a clear operational purpose. The aim is to preserve trustworthy control of the process while addressing the threat, rather than choosing between security and production as though they're separate jobs. The office laptop comparison helps expose the difference. In one case, disconnecting the device may contain a problem with a tolerable interruption. In the other. The same action may change conditions around operating equipment. A hypothetical factory and following the process. That's why the process needs to anchor this discussion to work through those choices without drifting into abstract network advice. Let's follow one hypothetical factory situation and keep asking what each decision means for the people running it. Our hypothetical plant packs finished goods into cartons for shipment products, travel through a conveyor, pass through a packing machine, and reach a label station before the sealed cartons move toward the end of the line. Several controllers handle different parts of that work. A programmable logic controller, or PLC runs machine control logic using signals from the equipment to decide when an action should start, continue, or stop during the machine's cycle. One PLC coordinates the packing machine. In this example, it receives signals about product position and machine. State then runs the approved logic that controls the sequence of movements needed to place products into cartons. The operator works through a human machine interface, or HMI. That's the operator's connection to the process, where they can read machine status, review alarms and enter permitted commands without opening the engineering tools used to change controller logic. An HMI and an engineering workstation have different jobs. The HMI supports running the machine, while the engineering workstation holds software that qualified engineers use to inspect, maintain and, where permitted, change the controller's program or settings. In this plant, several machines share one engineering workstation. It sits in the maintenance area and engineers use it for different equipment. Because each machine doesn't have its own dedicated computer with all the required tools. The alert. What we actually know. That arrangement gives our suspicious connection a specific setting. Traffic from this workstation could relate to several machines, so its presence on the network doesn't tell us which job someone intends to perform or which controller they need. Earlier in the shift, a supplier helped troubleshoot the label station. For this hypothetical visit, the supplier connected remotely and used the shared engineering workstation to examine the equipment involved. In a recurring problem with label placement, the maintenance engineer reports that the supplier's work has finished. Operators have returned to routine production. The label station appears to work as expected, and cartons continue moving through the packing machine toward the end of the line. Then unexpected engineering traffic reaches the Packing Machines PLC. It comes from the shared engineering workstation after the supplier's reported finish time, even though the work discussed with maintenance concerned the label station rather than the packing machine. That's the event we're trying to understand. We know the apparent source and destination of a connection, but we don't yet know whether it belongs to the supplier's work. Another engineers task or activity. Nobody approved. The timing raises a question, not a verdict. A supplier might finish speaking with maintenance while an engineering application remains open, or a local engineer might begin a separate task on the same workstation after that conversation ends. There could also be a mistake in the selected destination. An engineer working with several controller projects might open the wrong project or connect to equipment outside the intended job, which still needs attention even without malicious intent. Compromise remains another possible explanation for the traffic. Someone could be using the workstations access to reach equipment beyond the supplier's task, but that explanation needs evidence rather than confidence borrowed from an alarming sequence of events. For now, keep the observation narrow. Engineering traffic reached a controller that we didn't expect this workstation to contact at that time, and the apparent connection follows a remote maintenance session involving different equipment on the line. The asset discovery problem. Notice how much depends on the equipment names. If packing controller means one thing to maintenance and another thing in the network record, people could discuss the same alert while thinking about different physical machines. The shared workstation creates another source of uncertainty. Its network address identifies a connection point, but that address alone won't tell us which person used the engineering software or which maintenance task explains the contact. We need records that connect those details to actual equipment. Before anyone can judge whether this traffic fits the work, they need to establish which controller received it and what the shared workstation normally supports on this line. That takes us from an alert to an asset question. Can the plant connect each network identity to a real machine and a responsible person, or does the investigation begin with several people trying to decode an unfamiliar device name? An inventory needs to help someone find the equipment for the controller in our alert. That means a record that points to the right cabinet, identifies its production role, and names someone who can verify those details. Start with the device identity that survives routine network changes a network address helps locate communication, but the equipment record also needs a stable plant identifier, and where confirmed, the manufacturer model and serial number associated with that device addresses can change and old labels can stay behind. If maintenance replaces a controller while keeping its network address and unchanged. Inventory entry could lead an analyst to investigate the model and ownership details of the removed unit. Location needs more detail than the name of the site. Someone unfamiliar with the plant should be able to use the record to find the production area and cabinet without depending on whoever happens to remember the installation. The production role explains what the device supports. A useful entry describes its function within the machine. Rather than leaving the security team with a product name that says little about the equipment connected to it. Ownership needs the same care. I'd want a named person responsible for keeping the record accurate together with the responsible team, so the entry remains useful when that person changes roles or leaves. Reconciling equipment records with network observations. Equipment records give you one part of that picture. Engineering files and maintenance records may describe the installed hardware and its intended function, but they can miss equipment brought onto the network outside the usual purchasing process. Network observations answer a different question what's communicating? They can reveal and address or device that the equipment register lacks while leaving the physical location and reason for its presence unclear until someone checks it. Neither source should silently overwrite the other. When a network observation disagrees with an equipment record, retain the disagreement as something to resolve with the source and date attached to each claim about the device. Consider a spare controller kept ready for a machine replacement. Maintenance might record it as a spare, even while someone connects it for preparation, so its appearance on the network needs an explanation rather than an immediate change to its assigned role. Here's the thing about temporary gear it needs a built in expiration date. When an engineer brings in a laptop for a specific job, you're not just logging the serial number, you're recording who brought it, exactly where it's connected, and most importantly, when someone needs to confirm it's gone. Without that deadline, temporary equipment has a way of becoming permanent. Shared workstations create a different kind of problem. You can't pretend only one person uses them, but you still need someone accountable for keeping the record current. The trick is separating ownership from usage. The team responsible for the computer isn't necessarily the same as its permitted users. That distinction matters because a shared asset without an owner becomes nobody's problem when the details drift. Those forgotten remote access devices are a special category of risk. Picture a small box installed for a service visit two years ago still powered inside a cabinet. Still connected with nobody updating the plants records because nobody remembers it exists. That's not a documentation gap. That's a physical asset living off the books. When you find an unexplained entry, don't just label it unknown device and move on. That label describes your current state of knowledge, but it doesn't move you forward. Assign someone to locate and identify it. Give them a deadline, and suddenly that uncertainty becomes actionable work. The plant can actually complete verification dates need context. Confirming a cabinet label during a walk down supports the location record, but it doesn't validate the model number or firmware version. Checking a supplier document supports different details entirely. Don't treat both checks as proof of the whole entry. Be specific about what was actually verified. Here's where discipline matters most if the model looks plausible, but nobody has confirmed it. Label it as unverified and record why. An educated guess, repeated enough times becomes accepted plant knowledge. And that's how bad data spreads keep uncertainty visible in the fields themselves. The record needs practical update triggers, not calendar reminders. A controller replacement, a moved workstation, or a lone device arriving should prompt the responsible person to check the affected entry while the work is still fresh. Waiting for the annual audit means the details have already faded. You don't need perfect records before you start. What you need is a way to separate confirmed details from assumptions. Assign the gaps to someone and return to them later. An unfinished inventory that honestly marks its uncertainty still guides useful work. A finished inventory that hides its guesses spreads false confidence. Finding those gaps raises the next practical question how do you discover what's connected without treating each controller like an office computer and sending discovery requests that nobody has checked against the equipment's operating limits or supplier guidance? Passive discovery starts with communication. The equipment already sends. Instead of asking a controller to identify itself, a monitoring sensor examines a copy of existing network traffic and draws conclusions from what that traffic contains. No extra requests, no unfamiliar queries, just observation that gives you a less intrusive starting point. The monitored equipment doesn't need to answer extra discovery requests, because the sensor learns from exchanges that already take place as part of the plant's normal operation, its discovery without disruption. In our packaging example, that engineering connection becomes a source of evidence. Depending on the traffic captured and the protocol involved, it may reveal details about the communicating devices or the industrial functions being requested across that connection. The key distinction is between observing an exchange and initiating one. Passive analysis examines messages already passing between devices. Active discovery sends requests and learns from the responses, or sometimes from the absence of a response. Active discovery can answer questions that passive observation leaves open. A carefully selected request might help confirm device information, but its suitability depends on the exact equipment, its condition, and how the discovery tool behaves. There's no one size fits all answer here. I'd want approval for the method, not just the tools name. A scan described as gentle still needs review against the target equipment and supplier guidance, with testing that reflects the actual devices you intend to query. The label doesn't protect you, the testing does. The request rate matters, and so does the request itself. Equipment might handle ordinary production messages reliably while responding poorly to an unfamiliar query, an unsupported function, or more simultaneous connections than its software expects. That's not a theoretical concern. It's a real operational risk. That doesn't mean every active method needs a blanket ban. It means the plant should approve a defined scope and tested settings with someone able to recognize trouble and stop the activity if the equipment reacts unexpectedly. Controlled risk not no risk Microsoft Defender for IoT OT sensors support passive network analysis. They examine captured traffic using industrial protocol awareness, helping identify devices and interpret supported exchanges without installing an agent on each controller being observed by the sensor protocol awareness gives that analysis more meaning, where the sensor supports the protocol and receives enough of the exchange, it can interpret industrial communication beyond simply noting that two network addresses exchanged packets, it understands what the conversation means. Think about the difference between an address and a device. Description. A packet contains network information by design, but some industrial exchanges also carry device details that a suitable parser can extract and use to inform discovery. That's the difference between knowing something is there and knowing what it is. The amount of detail varies significantly. One conversation might expose useful identification information. Model number. Firmware version, vendor. Another provides only enough evidence to classify the device broadly, leaving its precise identity unresolved until someone checks another source. That's where confidence needs to stay attached to the result. If a sensor infers a device type from its communication pattern, treat that differently from a model identifier explicitly returned within a captured exchange. One is an educated guess, the other is evidence. Silence creates a separate limit, A connected device that sends nothing during the observation period may remain undiscovered through passive analysis, because there's no traffic available from which the sensor can learn about it. No traffic means no discovery. A short observation period can leave that gap hidden. Equipment used only for an occasional task might begin communicating later, so the discovery result describes what the sensor has observed so far. Not every device that could communicate duration matters. Visibility also depends on which traffic reaches the sensor. A device can communicate throughout a shift and still remain absent from discovery. If none of its exchanges pass through the network paths available to that sensor. The sensor can only see what it can see, so an empty result needs careful wording. Nothing observed describes the evidence you have. Nothing connected makes a much stronger claim that passive monitoring alone may not support in that part of the network. Precision in language prevents false conclusions for our suspicious connection. Keep the same discipline. The sensor may identify the participants and reveal useful protocol details, but any missing information should remain a question rather than becoming a confident guess about the equipment. Passive discovery gives you evidence without requiring new conversations with controllers. Its usefulness still rests on receiving the right existing conversations, which means the next design choice concerns how the monitoring sensor gains access to the traffic it needs. The switch configuration now becomes part of the monitoring design. Whoever manages the plant network needs to identify the ports, carrying the required conversations, and arrange for copies of that traffic to reach the sensor. One common method uses a switched port analyzer or span. This switch function copies traffic from selected ports or supported groups of traffic to a monitoring port, where the sensor connects and receives those copies for analysis. The choice of source ports needs care. Mirroring the port connected to our shared engineering workstation could capture its exchanges through that switch. Mirroring a different uplink might capture only the exchanges, leaving that part of the network. Same sensor. A completely different view. Direction matters too. If the configuration copies only traffic entering a selected port, the sensor might receive requests without their replies, leaving it with an incomplete exchange even though the monitoring connection appears healthy. 00:17:13 Speaker: Another option uses the network test access point or tap. A tap provides a dedicated way to copy traffic from a selected network link, with its outputs connected through a suitable monitoring arrangement to the sensor. A tap still needs an engineered installation. Its design, link compatibility, and output capacity need review, and inserting it into an existing production link may require a planned interruption rather than a casual cabinet visit. Neither method removes the need to choose the right link. A well installed tap on the wrong connection can faithfully copy traffic that tells you very little about the production assets you intended to monitor in the first place. For our packaging line, start by tracing the Workstation's actual route. Ask the network engineer which switches carry its connection to the packing controller, and whether that exchange crosses the production cell boundary or stays within the cell. That distinction changes the placement decision. A monitoring point at the cell's uplink can capture conversations crossing that uplink, but exchanges between devices connected within the cell may never travel through that same point. Shared services introduce other useful observation points where several production cells communicate with a common server. Monitoring the relevant server connection or aggregation point may reveal those exchanges without requiring a separate copy from every individual device port. Remote access deserves the same path. Check. Traffic arriving at a remote access gateway may differ from the onward connections created by an intermediate workstation, so one observation point might not capture both parts of the route. Write down what each monitoring point is intended to capture. For example, distinguish workstation to controller exchanges from connections entering through the remote access service. Those are separate coverage claims even when they support the same investigation. Then check whether the copying arrangement can carry the load. A mirror port receiving copies from several busy source ports can face more traffic than its own link can transmit, particularly during short bursts that average utilization figures conceal dropped copies can leave gaps without disrupting production. The original exchange may reach its destination normally, while the monitoring path loses packets, so a working machine doesn't prove that the sensor received a complete conversation about it. Capacity needs checking along the whole monitoring path, the switch mirror function, any traffic aggregation equipment, the sensors receiving interface, and the sensors supported processing capacity can each limit how much usable traffic reaches analysis. Routing boundaries need a separate check? A copy taken on one side of a router reveals the traffic present there, but it won't automatically include exchanges on other interfaces or conversations that remain inside another network segment. Address translation can complicate the record as well when a device changes addresses between network boundaries. Note where the copy originates so investigators know which identity they should expect in the captured traffic at that location. Check the arrangement with a known exchange during an approved task. Compare the expected participants and direction of communication with the sensors observations. Then examine monitoring health and packet drop indicators available from the equipment along that path. Repeat that check when the network path changes. Moving a workstation connection or replacing a switch can alter what reaches the monitoring port, even if the sensor stays powered and nobody reports a problem, sensor counts won't answer the coverage question. The youthful record names the conversations. Each monitoring point captures the paths it misses and the checks that support those claims, giving the next investigation a clear starting point rather than an assumed view of the plant. For the packaging line, I'd separate two kinds of conversations. There's the ones needed to run each machine, and then there's the ones that leave its production cell during a normal shift or a service task. Those two sets can give completely different impressions of the same machine. A controller might exchange data with a shared server, while its local exchanges with an operator station stay outside the monitored path. That leaves the inventory with evidence of the controller, but almost no evidence of its local relationships. Treat that as partial coverage, not a missing asset. When someone asks whether the packing machine is monitored, the answer should distinguish communication within its cell from communication crossing its boundary. Either view alone leaves questions unanswered. Encryption creates another kind of blind spot. Even when the monitoring point receives an entire session, encryption can prevent the sensor from interpreting what's inside. Receiving the packets doesn't guarantee access to the industrial messages they carry. connection details can still help the investigation, though. Depending on the protocol and where you're observing from, you may establish which systems connected and when, while remaining unable to determine which commands, files or user actions passed through that encrypted session. Think about the supplier session in our example and observe. Connection to the remote access service could establish that a session continued after the report had finished time, but it wouldn't by itself establish what the supplier actually did inside that session. Keep those claims separate in the coverage record session observed contents unavailable tells the next investigator more than a broad statement that remote access is monitored, especially when they need to distinguish access from an actual engineering action. Some equipment sits outside ordinary Ethernet monitoring entirely. A machine might include instruments connected through a serial link, with only a gateway presenting information to the Ethernet network. The visible gateway doesn't establish an individual network identity for every instrument behind it. The gateway creates a boundary in what you can infer. Supported protocol exchanges might expose some downstream details, but any claim about individual serial devices needs evidence from those exchanges or confirmation through other plant records and physical checks. Other assets never communicate over the monitored network at all. A standalone station can still affect production or product quality, so its absence from network discovery needs to remain separate from the question of whether it belongs in the plant inventory. Now, test coverage across changes in operating state routine production might exercise only part of the equipment, while a product changeover brings another station into use and starts conversations that don't occur during the rest of the shift. A changeover gives you a defined observation window. Ask the engineer responsible for that work which devices should become active. Then compare those expectations with what the monitoring system actually records while the approved changeover takes place. Maintenance can expose a different gap entirely. A technician might connect through a local service port rather than the Workstation's usual route. A coverage claim based on routine operation may say nothing about that temporary connection during the task. Use scheduled work to check that assumption. There's no need to create extra controller traffic just to prove visibility. When an approved maintenance task already provides a chance to observe the expected exchange and document any missing evidence. Supplier support needs its own coverage check. During an authorized session, establish which parts of the activity produce usable network evidence and which remain concealed by encryption, or occur through a connection outside the monitored paths. Record the operating condition alongside the result. A successful check during production doesn't settle coverage during maintenance, and a successful supplier session check doesn't prove that local engineering work follows the same route or leaves the same evidence. The result should leave room for a qualified answer. You might confirm visibility of a controller during production, while noting that its service connection remains unchecked. That gives the plant a specific gap to investigate during suitable plant work. That still leaves the meaning of the device's activity unresolved. Even after you confirm that the sensor receives its traffic across the relevant operating states, you need someone to explain which work those exchanges support and whether that work belongs there. Hearing a device is only the beginning. Understanding its work means connecting that observed activity to the equipment and process it supports. That way, an investigator can ask a more useful question than whether packets reached a known address for the packing controller. The next question concerns its place in production. Link that controller to the packing machine, then link the machine to the packaging line and the specific process step that depends on its work. Those relationships need to describe function, not just physical proximity. Two devices inside the same cabinet might support different parts of the process. One machine might rely on devices installed in several cabinets across the production area. A machine can also support more than one production route. If the packing machine handles different product families. Its relationship to each route helps explain which work depends on it during the shift being investigated. That's better than assuming every order uses it. That gives our connection a more precise meaning. Instead of describing traffic between two devices, we can describe an engineering workstation contacting the controller responsible for packing products currently moving through a particular production step. On this line. The relationships also help define what the workstation actually needs to reach. Its engineering software might support several controller families, but that capability doesn't establish a production reason for contacting every compatible controller available from the maintenance area. I'd separate technical capability from approved purpose for each machine the workstation supports. The responsible engineer should explain which engineering tasks require that relationship. A successful connection alone doesn't prove the connection belongs there. Permissions answer a different question from operational need. A user might hold broad rights because they support several machines, while a specific maintenance task requires access to only the label station and its associated controller. Our supplier task gives us a narrow reference point. If examining label placement requires information from the packing controller, the engineer can explain that dependency. If it doesn't, contact with that controller remains outside the task. As currently understood, that explanation needs to describe the actual dependency. Perhaps the label station uses a production value supplied by the packing machine, but reading that value and changing the packing machine's program would represent different kinds of work. Production execution records can add another piece of context a manufacturing execution system, or miss records and coordinates aspects of shop floor execution. The exact information available depends on how the plant has implemented and connected it. For this example, an Ms. record could identify the active production job. If the implementation records equipment assignments and job times, those details can help establish what the packing machine should have been doing when the engineering connection occurred. That doesn't establish which engineering action took place, though it gives the investigation an execution context, allowing someone to compare the observed connection with the job, machine assignment and production state recorded for that point in time. The timing needs care when records come from different systems, a job completion entered after the physical work finishes can create an apparent overlap. Investigators need to understand what each recorded event means before drawing conclusions from it. Business records explain a different set of dependencies. An enterprise resource planning system, or ERP, holds orders and planning information that can help identify the business work connected to the production job under investigation. At that time, an order link can turn machine impact into a planning question. If the affected packaging step belongs to an order awaiting shipment. The plant can ask which commitments depend on that work without expecting the network record to supply the answer. I'd keep that consequence grounded in the plant records and ERP. Due date alone doesn't prove that a shipment will miss its commitment. Remaining operations, available stock, and the actual state of production still affect that judgment. The connections between these records need deliberate mapping. A machine name used in execution records may differ from the equipment reference used in planning. Someone must confirm which references describe the same resource before connecting the associated work. You can keep the first version quite focused for our investigation. A confirmed relationship between the controller, packing machine, active job, and related order gives people a usable chain without requiring a model of every production dependency. Microsoft tools then need a defined place in that chain. The useful question becomes which evidence each tool contributes, and which production relationships the organization must supply before that evidence can support a sound decision about the packing line. I'd give defender for IoT a clear responsibility in the design. Its job is to turn monitored network activity into asset information, communication records and security alerts that the plant can use alongside its own approved equipment. Records define that responsibility as something you can check for the packaging line, specify which monitored assets should appear, which communication records investigators should receive, and where. Analysts should find the supporting detail. When an alert needs review, an alert needs an agreed interpretation. Depending on the detection involved, it might report a new communication pattern, a suspected threat or an industrial activity that deserves attention. Each requires a different explanation from the responsible engineer. The alert description sets the starting point for that review. Analysts should understand what the detection claims, what evidence supports it, and which parts of the event still need confirmation. Before anyone describes the activity as a compromise. That's where plant knowledge enters the tools operating model. When an engineer confirms an asset's identity or explains a legitimate communication relationship, that knowledge needs to become maintained. Context rather than remaining buried. In an email about one alert, keep the source of that context clear. Whether enrichment sits in supported product fields or a linked asset system. Investigators should distinguish what the sensor observed from what the plant verified through its approved records and engineering review. Those sources can change at different times. A replacement controller might appear in network evidence before the equipment register receives its update. The design needs a way to flag that mismatch without quietly choosing either record as correct. I draw a firm line around enforcement. The monitoring sensor gives you evidence about what's happening on the network. While a firewall applies communication rules at a boundary, it has its own management process and its own responsibility for those decisions it makes. Those two jobs can support each other without becoming the same job. A census observation might tell you to review a firewall policy, but recording unwanted traffic doesn't mean that traffic actually got blocked or that the destination stayed protected. Endpoint protection has another job entirely on systems where it's supported. It can look inside the computer and give you evidence about processes or files that a network sensor would never see, just from the traffic passing by. Neither view replaces the other for that shared engineering workstation. Network evidence shows you what it exchanged with the outside world, While endpoint evidence can help explain what happened inside that workstation, assuming the installed protection actually collects and reports that data. Safety systems keep their own engineered purpose defender for IoT isn't a safety controller, and its alerts don't validate a protective function or tell you whether equipment can keep operating within the limits. The plant's safety design defined. That separation needs to survive procurement and deployment discussions. If someone expects one monitoring product to discover everything, block every threat, protect workstation software and guarantee safe operation, the architecture needs fixing before the purchase becomes an operating assumption. Start with the supported architecture for your site, then check the current Microsoft documentation for the sensor management environment and services. Your design depends on. Product names alone won't settle those choices. You need to confirm which deployment options remain supported, which capabilities belong to each option, and whether your proposed combination matches the documented requirements, not an older presentation or a remembered implementation. Identify which components must communicate the direction of those connections and the service dependencies involved. Then compare those requirements with the plant's permitted connectivity before committing to the design. Separate required connectivity from optional connectivity. If a capability depends on an external service, describe that dependency explicitly so the plant understands which result it's buying and which approved communication path supports that result. I'd record those decisions alongside the architecture's review date. Microsoft supported deployment guidance can change, so the record should identify the documentation you checked and the assumptions that need another review. When the deployment changes or expands. The sensor now has a defined job. It contributes security evidence, relies on approved connections, and depends on people maintaining its configuration. That means it also introduces equipment and a management path the plant must protect. Start by deciding who can reach the sensors management interface. The supplier working on the label station shouldn't gain access to monitoring administration just because their approved connection lets them reach equipment on the packaging line. Routine operator access needs the same separation. An operator who needs production information shouldn't need sensor administration rights, and a maintenance account shouldn't inherit those rights just because somebody used it during installation. Use a dedicated, controlled route for administration where the deployment supports it. Separate management connectivity from traffic collection and restrict management access to approved systems and people rather than the wider plant network. Access should match the work someone actually performs. Reading, monitoring results, changing configuration and administering accounts carry different consequences, so use the supported access controls to avoid giving every person the broadest available permissions. Shared administrator accounts weaken accountability. Give administrators named identities wherever supported, protect their credentials through the approved process, and define how access gets removed when someone changes responsibilities or leaves the organization. Assign responsibility for the sensor software its host where relevant management accounts and supporting connections. That way, a fault doesn't disappear between the plant network team and central security. Confirm the supported update procedure for your deployed version. Check any compatibility requirements and agree Who reviews release guidance before scheduling work that could interrupt monitoring. Treat an update as a controlled change. Record the starting configuration. Follow supported backup and recovery guidance and define the checks needed afterward to confirm that collection and administration still work as intended. A completed update doesn't tell you whether the sensor still receives traffic, keeps the intended configuration, or passes information onward through the connections that particular deployment uses. You need to verify that yourself for your selected deployment mode. Compare Microsoft's documented destinations, ports, and connection requirements with the site's outbound access rules, including any proxy or traffic inspection requirements along that route. Avoid solving a connection problem with unrestricted access if a required service remains unreachable. Identify the failing dependency and resolve that specific issue through the site's approval process, rather than opening broad internet access from the management network. Keep any required secrets in approved storage limit who can change them, and assign responsibility for renewal where certificates or other expiring credentials support the connection. 00:34:12 Speaker: Then ask what happens when the internet connection fails? Distinguished local collection and analysis from cloud dependent management reporting or alert delivery. Confirm the documented behavior for your exact deployment. Instead of assuming everything stops or everything continues, test that behavior during an approved exercise. Establish which information remains available locally, what becomes delayed or unavailable centrally, and whether the available buffering and retention meet the plant's needs during an extended interruption. Confirm what information reaches the central servers afterward, identify any gap that remains, and avoid treating the first successful connection as proof that the missing period has been recovered. Define how someone notices lost power, failed hardware, or an unavailable management service. Make sure that notification doesn't depend entirely on the sensor that might have failed. Silence needs an explanation. The responsible team should distinguish an expected maintenance interruption from an unexplained loss of monitoring, with a contact route and response expectation that still work outside normal office hours. If monitoring must pause, record the affected scope, expected duration, responsible person and any temporary arrangements, then tell the people who rely on those alerts when the gap begins. Recovery should use instructions someone else can follow. Keep supported configuration backups and restoration procedures accessible through approved means and test recovery, without assuming that the original installer will always answer the phone when needed. Confirm that the expected traffic returns. That management access still follows the approved restrictions, and that central recipients receive the information they need before declaring the monitoring service restored. That gives the next stage a better foundation. When we begin learning normal plant traffic, we need to know whether a quiet period reflects the equipment's behavior or a monitoring interruption that nobody recorded on the packaging line. The exchanges you expect while cartons move through the machine may differ from those you expect when the line stops for cleaning during production, repeated exchanges can establish a fairly steady pattern, but that pattern belongs to that product and operating state, so it shouldn't become the reference for every activity the equipment performs throughout the week. Cleaning can change that pattern without indicating a security problem. Where the equipment design includes a cleaning mode, operators may select different sequences, and some production related exchanges may pause while other approved communication continues during that work. Ask the process owner what changes during cleaning. Their explanation gives analysts a reason to expect certain differences, rather than forcing them to decide whether unfamiliar traffic looks harmless based only on how often it appears. An engineering application that rarely communicates during production might exchange diagnostic information during scheduled work, making an unusual connection understandable within that specific approved task and time. Product changeovers deserve their own reference as well. Selecting a different product or transferring an approved recipe can produce exchanges that don't occur during a long run, even though they belong to the machine's intended operation. I choose the learning period around the work the line actually performs. Then identify which activities remain unobserved. Instead of assuming elapsed time establishes a complete baseline if an unnecessary connection already exists when learning begins, repeated observation can make that connection familiar without establishing any legitimate reason for it to remain in place. Frequency doesn't grant permission, a connection that appears every shift still needs an explained purpose, and the person reviewing it needs enough plant knowledge to judge whether that purpose belongs to the equipment involved. Have we observed this before? Concerns the communication history. Should this happen requires an operational judgment about the work, the participants, and the circumstances in which the connection occurs. That distinction affects how you handle noisy alerts when analysts repeatedly encounter the same unexpected connection. An OT review should establish its purpose before anyone applies a broad suppression that could conceal different activity involving the same equipment. Ask which task requires the connection and who can explain that requirement. Rather than asking an engineer to approve everything associated with a familiar workstation or a known supplier. A narrow explanation supports a narrow alert decision. If the connection belongs to an approved changeover, any supported tuning should reflect that circumstance where practical, rather than treating all future contact between those devices as expected. An engineer might confirm a legitimate task while leaving its unusually broad communication unexplained. That means closing the alert shouldn't quietly close the separate question of whether that behavior needs correction. When maintenance introduces an approved communication relationship, link the explanation to the maintenance record and name the owner responsible for confirming that the relationship matches the completed work. A connection accepted for troubleshooting shouldn't become permanent just because the task finishes without anyone revisiting the exception. Assign someone to confirm whether it remains necessary after maintenance closes. If an approved modification changes routine communication, record when the new behavior should begin and who verified it. That lets later reviewers distinguish an intentional change from unexplained drift and alert decision that depends on a conversation nobody recorded leaves the next analyst repeating the same questions or accepting an exception without knowing the limits of its approval. It helps establish whether the workstation's contact with the packing controller differs from previous activity, but the work underway determines whether that difference has a legitimate explanation. Unfamiliar traffic can also belong to legitimate work, so the next judgment needs to connect the observed activity to what people were authorized to do at that moment in our hypothetical investigation, I'd ask maintenance whether that time marks the end of the conversation, the end of the approved work, or a confirmed disconnection from the engineering workstation. Those events might have different timestamps if the maintenance record only notes when the engineer closed the phone call. It can't establish when the supplier stopped interacting with software or when the remote session ended. Check that the address recorded at the event time belongs to the shared engineering workstation. Use the available network records and confirm device details to resolve any mismatch. Do the same for the destination before asking why someone contacted the packing controller. Confirmed that the captured destination actually identifies that controller at that time, rather than another device with an outdated label. A remote access record might identify the supplier account, while workstation records, where available, help establish whether that session overlapped with a local engineer using the same computer. Overlap would leave attribution unresolved. If two people could use the workstation during the relevant period. Investigators need evidence connecting the engineering action to a session rather than assigning it to whoever connected first. A useful explanation names the engineering application, the controller project, and the intended action that gives investigators details they can compare with the activity recorded around the connection. Approval needs that same level of detail. A request to troubleshoot label placement might permit inspection of related controller values, but the responsible engineer needs to confirm whether that permission actually included the packing controller. If the supplier reports reading a value needed for diagnosis, compare that account with the available evidence instead of accepting a broad statement that the traffic belongs to maintenance. The protocol detail can change the question where defender for IoT supports decoding and receives the relevant exchange. The evidence may distinguish an identification request from another supported industrial operation, subject to the protocol and detection involved. If the available record describes a connection without an interpreted operation, keep the investigation at that level rather than converting contact with an engineering port into proof of a program change. Incomplete capture needs an explicit note, a missing response, or an exchange that begins before capture starts can limit interpretation, even when the sensor correctly identifies the participants and recognizes the protocol carrying their communication. An alert label helps direct review, but investigators should check its supporting details and understand the detections, meaning before treating that label as evidence of a particular controller operation. The maintenance explanation might hold up if the approved task includes the destination, and the recorded activity fits the engineer's account. The connection can have a legitimate explanation despite appearing outside the expected work at first. For example, the engineer might confirm that the application selected a saved controller address from another project explaining the contact while leaving its possible effects to be checked. That explanation still needs corroboration. The selected project, available application records and the observed destination should fit together before the team accepts an accidental connection as the reason for activity. Nobody initially expected. If nobody claims the activity, the work approval excludes the destination and available session records contradict the reported finish. The team has specific reasons to investigate unauthorized use. Missing records still leave uncertainty and unavailable activity log doesn't prove compromise or excuse the connection. It limits what investigators can establish and should remain visible in their assessment of the competing explanations. The source might be confirmed while the user remains uncertain or the requested operation might be understood while its approval remains disputed. Avoid one verdict that hides those differences. The findings also define a narrower access question. Once the engineer establishes which controller interactions the labeled task requires, the plant can compare that need with the workstation's wider reach and identify communication that needs a tighter boundary. You decide which systems can communicate across that boundary, for what purpose, and through which permitted paths. That's better than allowing access simply because a route exists for the packaging line that starts with the production dependencies. If the packing controller and its operator station need direct communication to perform their assigned work. The boundary should preserve that relationship while limiting unrelated access from elsewhere. Equipment mounted together can have different access needs, while devices spread across the line might belong together because they support the same function and need similar protection. I'd group assets by function and consequence. Ask what work they perform together, what a compromise could affect, and which outside systems genuinely need access. Before deciding where one production zone ends and another begins. Sharing a conveyor doesn't establish that their controllers should accept engineering connections from every computer permitted to support either machine during normal work. Separate groups can still exchange required information. The design should state which communication supports their coordination, then provide a controlled path for that exchange without opening every other connection between the assets in those groups. If one group includes equipment whose loss of trusted control could have greater physical consequences, its access requirements deserve separate consideration, even when it shares a production area. IEC sixty two hundred forty three gives us useful terms for this design. This Industrial Cybersecurity Standard series describes zones as groupings of assets with common security requirements and conduits as groupings of communication channels, connecting zones under defined security requirements. Its assets belong together because the assessed risk and required controls support that grouping, not because somebody assigned them addresses from the same network range. A conduit defines the controlled communication between those zones. In practical terms, you describe the permitted participants and exchanges along with the security requirements for that path. So the connection has a stated purpose and limits. When someone proposes putting both machines in one zone, ask whether they share protection requirements or whether the grouping mainly avoids having to define their communication needs. Neither term certifies the resulting design. Using zones and conduits gives the team a structure for reasoning about access, but the boundaries still need to reflect the plant's risk assessment, and the controls actually implemented its role. Supporting several machines creates a requirement for selected access across boundaries, rather than a reason to place every supported controller inside one broadly reachable group. Describe each of those relationships separately. Access needed to support the label station should have its own stated scope, so that requirement doesn't quietly become permission to contact every controller reachable from the maintenance area within the monitored coverage. Its communication evidence helps identify which participants exchange traffic, giving engineers concrete relationships to examine when defining the paths between proposed zones. Observation still needs an engineering interpretation for each proposed path. Establish which function depends on it and whether the observed scope matches that function before treating the exchange as a requirement for the segmentation policy. A policy entry should connect the permitted source and destination to the work they support, allowing another engineer to understand why that access exists without reconstructing the original discussion. Enforcement belongs to the controls placed at the boundary depending on the design. Industrial firewalls or other configured network access controls apply the restrictions while defender for IoT contributes observations that help assess whether communication matches the intended policy. Any alternate route that bypasses those controls can undermine the restriction, even when the intended path has a carefully defined and correctly enforced set of access rules that makes shared services the next complication. A service used by several production zones can introduce connections across otherwise careful boundaries, so the design must account for those relationships rather than treating shared infrastructure as automatically trusted. On our packaging line, that might be a server collecting production values from several cells, while also feeding information to business applications outside the plant network. An industrial demilitarized zone, or industrial DMZ, helps organize that exchange. It's a controlled network area between enterprise and plant networks, where selected services can exchange information through separately restricted connections. Instead of giving enterprise systems direct access to production. Equipment placement alone doesn't provide that control. The design needs rules on both sides, with each connection limited to its stated purpose. Otherwise, a server in the industrial DMZ just becomes another broadly connected computer. Take a historian collecting process values over time. A plant historian might retain detailed production records locally, while an approved transfer supplies selected information to a separate historian or reporting service sitting in the industrial DMZ. Business reporting can then use that separate service. The exact arrangement depends on the historian supported architecture, but the intention is to let reporting consume production information without giving report users a direct route to controllers Data direction and connection direction need separate descriptions saying that values move toward the business doesn't establish which system initiates the connection, what replies it needs, or whether the same connection supports additional functions. Manufacturing applications can need a different exchange. An application supplying production instructions to the packaging line might pass approved information through an intermediate service, with a defined plant side connection, retrieving or receiving the information required for execution. Name the application function behind each connection. Manufacturing integration is too broad when it could mean transferring an order, reporting completion, or distributing reference data. Those functions can require different participants and permissions. Files need a managed exchange as well. Instead of sharing a folder across enterprise and production networks, the plant can use a controlled transfer service with defined destinations, access permissions and checks appropriate to the files involved. Receiving a file doesn't authorize its use. A file can reach the approved transfer location while still needing engineering. Review before a plant application accepts it, particularly when its contents influence how production work proceeds. Less visible services need equal attention. Name resolution translates a server name into a network address, so a production application that appears self-contained might still depend on a name service outside its immediate production area. Record which name service the application actually queries if that service becomes unavailable. Establish whether existing connections continue and whether new connections still work. Don't assume the machine's current activity proves the dependency doesn't matter. Time services create another shared dependency. Devices may rely on a common time source for consistent records or application behavior, so specify the approved source and the permitted path instead of allowing arbitrary access to whichever server responds. Authentication can spread dependence across production cells. A shared identity service may support several applications, but each application's authentication requirement needs a defined connection rather than broad network access to everything associated with that identity environment. Backups introduce connections that people sometimes overlook. A backup server may contact systems in several cells using powerful credentials, which means it's permitted. Reach deserves the same scrutiny as the production applications everyone already knows about separate backup access from general administration. The systems involved need only the connections and rights required by the supported backup method, rather than a standing allowance for unrelated traffic between the server and every protected cell. For each shared service, describe both ends of the exchange record which plant systems depend on it, which connection each function requires, and whether that connection lets one production cell initiate communication toward another through the shared infrastructure. A common destination shouldn't imply common access. Two cells can use the same service, while rules keep their connections separate, with access restricted on the service itself as well as at the network boundaries, that produces a more useful dependency record. It explains which shared functions must remain reachable without granting unrestricted access across production cells, and gives plant engineers specific assumptions they can challenge before anything changes. Those assumptions still need a practical check before applying the boundaries to live equipment, the team needs to establish whether the proposed restrictions preserve the service exchanges required by the plant's actual work. I test the proposed rules against a complete production cycle, start with the captured exchanges, then ask the control engineer which required operations haven't occurred during monitoring, and what additional connections those operations will need. Build the test around functions, not just addresses for every proposed restriction. Identify the operation it could affect, and the evidence that would show that operation still works, including any checks needed at the machine. A restart deserves its own test. The packaging line might continue an established exchange throughout production, yet need a different connection when an application starts and retrieves the information required to resume its work. A running machine won't exercise that dependency for you during an approved restart test. Check the sequence from application startup through readiness for production, rather than stopping the test when the computer reconnects to the network. Recipe downloads can expose another missing requirement. In our hypothetical plant, a product change might require an approved set of machine parameters to move from an engineering application to equipment that receives no such transfer during routine packing. 00:51:33 Speaker: Check the transfer through to its intended result. The engineer needs to confirm that the correct approved recipe reaches its destination and that the application reports completion, rather than accepting a connection attempt as proof of success. Failover needs an explicit place in the test plan, where a supported design includes a standby server or alternate communication path. The rule set needs to accommodate the intended transition without allowing unrelated traffic through that same boundary test the supported transition under controlled conditions. Check whether the alternate system can perform the required function, and whether returning to the normal arrangement still works. Those directions can involve different participants or connection behavior. Maintenance introduces a different test condition. An approved diagnostic task might require a connection that production never uses, so the engineer should specify whether that requirement belongs in a permanent rule or a controlled temporary change. Keep the scope tied to the actual task. If a test needs a temporary allowance, record its intended removal and check afterward that the final policy matches the approved design rather than the broader test configuration. The change plan needs named decision makers before enforcement begins, identify who approves the plant interruption, who applies the rules, and who decides whether an unexpected equipment response requires stopping the test or restoring the previous configuration. Give those people observable decision points. A test instruction should explain which failed function, missing response or equipment condition triggers a pause, with the responsible engineer defining those limits. Before anyone changes the firewall policy. Rollback needs more than a saved configuration. Confirm who can restore it. How they'll reach the firewall if the change blocks their normal management route, and what plant checks must follow before the test can close. Restoring rules might not restore an interrupted application session. The rollback procedure should account for any approved reconnection or restart work the equipment requires, so nobody assumes that loading the previous configuration immediately returns production to its earlier state. Apply changes in the scope the team can assess where. Practical. Test a defined set of restrictions during an agreed window, giving engineers enough time to check the affected functions before moving to the next change. Successful access is only half the test. Confirm that the required exchange works. Then verify through an approved method that a connection the policy should deny actually encounters the intended restriction, rather than an unnoticed permissive rule. Logical separation needs that enforcement check. Assigning systems to different virtual local area networks. VLANs separates their local network traffic, but routing between those networks can still permit communication unless configured. Controls restricted. Check the rules on the path. Traffic actually takes a carefully reviewed firewall policy. Won't limit an exchange routed elsewhere, and a broad allowance earlier in the rule sequence can defeat the narrower restriction people believe they've applied. Close the change with the tested configuration. Recorded note which production conditions passed, which remain untested, and who accepted those limits. So the next maintenance window starts with clear evidence rather than recollections of a successful installation, one boundary still needs a more specific operating model. The supplier's route into our engineering workstation has to support approved service work while keeping that access limited to the equipment and circumstances the plant actually intends to permit. Supplier access should begin with a named person and a work request for the label station job. That request should identify the supplier, engineer the approved equipment, the permitted work and the period during which the plant expects access. A company name isn't enough for attribution. If several supplier engineers share one login, the plant can't reliably distinguish their sessions, revoke one person's access, or establish who connected. When the supplier changes its support staff give each approved engineer an individual identity. The plant also needs someone responsible for confirming that the person still works for the supplier and still needs access, rather than relying on an account created years earlier. The work request should govern access activation. An existing account can remain unavailable for plant connections until an authorized person approves a specific task, with access limited to the entry point and destinations required for that work, approval needs a defined finish as well as a start. If troubleshooting runs beyond the agreed period, extending access should require a recorded decision rather than leaving the session available because nobody knows whether the supplier has finished. Multi factor authentication adds another check at the remote access boundary. It asks for more than a password proof from an approved authenticator, so possession of a stolen password alone doesn't satisfy the sign in requirements. Choose a method the access service actually supports where practical prefer phishing resistant authentication and agree how external engineers enroll and recover access without creating a help desk shortcut that bypasses the protection when a phone goes missing. Successful authentication still leaves the destination to decide. The remote access service should give that engineer access to the approved support route, rather than placing their external computer directly onto a network with broad reach into production. A managed jump host provides that intermediate step. The supplier connects to a controlled computer, and that computer provides the onward access permitted for the task, keeping the external device separate from direct connections to plant assets. the jump host needs a tightly defined purpose, limit its available destinations and permitted applications through supported controls, so using it for label station support doesn't also provide a general route to every machine the supplier might recognize. Decide how files cross that boundary to clipboard sharing. Drive redirection and file transfer can create additional access paths, so enable only the functions the approved work requires and record how the supplier should exchange necessary material. Session records should explain access without overstating what they prove. Capture the named identity approval reference, entry time, destination and session end where supported. Then retain those records through a controlled process that investigators can actually use. Recording the session itself can add detail if the access platform supports recording, establish who can review it, how long it remains available, and what privacy or contractual requirements apply before turning that capability on, check whether onward activity retains the supplier's identity. Some arrangements show only the jump host at the destination, so the records must preserve the link between the external session and its onward connections without depending on someone's memory. Expiry needs to affect access, not just the approval document. Verify whether the chosen platform ends an active session when its permission expires, or merely prevents another login because those behaviors leave different exposure after the work window closes. Give maintenance away to confirm closure for our label station task, the responsible engineer should be able to verify that the supplier session has ended and that the temporary permission no longer allows another connection. Unmanaged connections need a replacement plan? Locate supplier installed routers, cellular connections, and remote control applications, establish who depends on them, then move legitimate support onto the approved route before removing the old connection through a controlled change. Removal needs verification at the equipment and account level. Unplugging a device won't remove a separate software account, and disabling an account won't disconnect an independent cellular route, so check each access mechanism identified during the work. That leaves the supplier with a defined route to the workstation once the authorized session reaches it. The next concern is protecting that engineering workstation without disrupting the tools and access the engineer needs to perform the approved job. The workstation holds more than a set of engineering applications. It may also hold controller projects, licensed software, and saved credentials that let an engineer move from inspecting equipment to changing how that equipment behaves. Protect those resources according to what they let someone do. A project file can contain machine settings and program logic, while stored credentials can grant access beyond the computer where somebody originally entered them during commissioning. Local administrator rights deserve a specific review. Establish which tools genuinely need elevated rights and when, rather than letting a requirement from one installation become the permanent privilege level for everyone using the workstation controller projects need controlled storage and clear status. An engineer opening a local project should know whether it matches the approved machine configuration, represents unfinished work, or belongs to equipment that no longer uses that program. credentials need similar care where the tool supported use approved credential storage and separate identities, and remove saved access that no longer belongs to the workstations assigned. Engineering responsibilities. Trusted device access can also involve removable media. If engineers use portable drives to transfer projects or connect licensed hardware, define which devices are permitted and how necessary transfers receive checks without breaking the supported engineering workflow. Endpoint protection needs testing with those workflows before installing anything. Check support for the operating system and engineering applications, including vendor guidance about security software drivers and any restrictions attached to the installed versions. A successful installation doesn't prove compatibility. The test needs to exercise the actual engineering work, including opening existing projects, communicating through required adapters, and completing approved diagnostic tasks using representative equipment or a suitable test environment. Pay attention to delays as well as failures. A tool might still launch while scanning, file inspection or. Another security control slows an operation enough to confuse the engineer or interfere with an expected application response. Exclusions need evidence and limits. If a supplier requests one, establish the exact affected component and supported remedy. Then document the narrow exception instead of excluding the entire engineering software directory without further review. Microsoft Defender for endpoint can contribute protection where the system is supported, confirm the supported operating system, available capabilities and licensing for that installation. Then test the intended configuration against the engineering tools before enabling it in production. Choose response settings deliberately controls that quarantine files, block applications, or restrict a computer's connections. Need review against the workstations role because a security action can also remove something required for an authorized engineering task. Endpoint evidence adds detail to the investigation. For example, where collection supports it, an analyst could examine the application process involved in an unexpected connection, rather than attributing every exchange to the workstation as a whole. Keep collection limits explicit. The available endpoint records depend on configuration and supported capabilities, while Agentless defender for IoT monitoring continues to cover observed industrial traffic, including devices on which endpoint software can't be installed. Some older workstations won't support a current endpoint agent. Installing an unsupported package creates another uncertain component, so document that limit and choose protections the plant can operate while preserving the workstations required. Engineering functions restrict what those legacy systems can reach and receive, keep access limited to the necessary people and equipment, and remove unrelated uses such as general web browsing or email, where they aren't required for the engineering work. Recovery needs more than copies of project files. Preserve the supported installation, media drivers, license arrangements, and configuration needed to rebuild the workstation using protected backups that don't depend on the original computer remaining available. Prove that the recovery method works on suitable spare hardware or another supported recovery target. Test whether the restored environment opens the required projects and recognizes the adapters and license components needed for engineering work. Replacement needs a written path record which application, hardware interface or supplier dependency keeps the older computer in service, then assign responsibility for resolving those constraints and testing the replacement before removing the existing system that record turns. We can't replace it into specific engineering work. Give each unresolved dependency an owner and a review date, so the decision remains open to reassessment rather than becoming a permanent exception. Nobody can explain now. The weaknesses need an order for action. Unsupported software, excessive privileges and missing recovery components create different problems. So the next step is deciding which repairs most reduce the plant's exposure and operational consequences. A vulnerability list needs a plant specific order of action. I'd rank each finding by whether it applies to the installed equipment, how an attacker could reach it, and what exploiting it could do to production. Start with the published weakness itself. Common Vulnerabilities and Exposures, or CVE, is a system of published records that gives known cybersecurity vulnerabilities, identifiers so different teams can discuss the same weakness without relying on a product description alone. A CV identifier gives the finding a reference. The associated record and supplier advisory help establish which products and versions are affected, but their presence in a report doesn't establish that your installed device has that weakness. Check the match before assigning urgency. A finding associated with a controller family might apply only to particular firmware releases, hardware variants, or enabled functions, so the investigation needs. The conditions described in the advisory firmware. Is the software running within the device for our packing controller, compare its confirmed firmware version with the affected range, including any qualifications the supplier gives about configuration or the functions needed for exploitation. An inferred version leaves the finding provisional if defender for IoT supplies identification information from observed traffic. Check whether that information is precise enough to support the match, rather than assuming every field has equal certainty. Record uncertainty separately from the repair priority potentially affected version confirmation needed creates a defined verification task, whereas declaring the controller vulnerable without that check can send engineers toward a change that addresses the wrong device. Then examine what the severity score actually describes. A common vulnerability scoring system score, often called a cvss score, expresses technical severity under stated assumptions, rather than calculating the operational risk for your particular packaging line. The score helps compare weaknesses, but it needs context. Read the conditions behind it, including whether exploitation requires network access, existing privileges or user interaction because those conditions affect which plant systems face a credible threat. Reachability turns those conditions into practical questions. Identify whether an attacker could reach the affected service from the supplier access route, the shared workstation or another plausible starting point using the access rules. Actually, enforce a permitted route doesn't prove exploitation. It establishes exposure while evidence that someone used the weakness requires further support. So keep those judgments separate when explaining why a finding deserves attention ahead of another. Evidence of exploitation changes the urgency. A supplier advisory or reliable security report confirming exploitation in the wild gives the team a stronger reason to act, especially when the required access conditions exist at the plant. Local evidence needs careful wording to traffic directed at an affected service might warrant investigation, but claiming successful exploitation requires evidence supporting that conclusion not merely a matching vulnerability record and an unusual network connection. A controller supporting a function whose failure could create dangerous conditions deserves close attention. Control engineers should explain the credible effects and the protective measures already in place, but that doesn't automatically put every controller first. An exposed engineering computer with a less severe individual finding might provide access to several production systems, giving an attacker opportunities that the controller's own network position doesn't offer. Compare the paths, not just the devices in our hypothetical plant, the packing controller could have the greater direct consequence while the shared workstation presents the more accessible route toward that controller and other equipment. Both findings belong in the same assessment. The team should explain whether its priority addresses an immediate exposure, a high consequence weakness, or an access path that connects the two, rather than letting device labels decide the order. Document why the first item comes first. An actionable priority identifies the affected equipment, the confidence in the match, the credible access conditions, and the production consequence that justifies acting before the other findings in the queue. That ranking also needs a review trigger, a newly confirmed firmware version, evidence of active exploitation or a change in reachable services can alter the order even when the published severity score hasn't changed at all. Once the team has established why that asset deserves attention, it needs a practical way to reduce the identified exposure. While the software change remains unavailable, waiting for a patch shouldn't mean waiting to reduce exposure. The plant needs a temporary operating arrangement that addresses the identified weakness, with clear conditions for how long that arrangement can remain acceptable while engineering prepares the change. Supplier approval needs to answer a specific technical question. Ask whether the proposed update supports the installed hardware, engineering software and application configuration, and whether applying it changes anything the machine requires to perform its approved functions. An available update isn't automatically ready for this installation. The supplier might require an intermediate firmware release, a corresponding engineering tool update, or additional checks that affect how the plant prepares and schedules the work. Compatibility testing should resolve those requirements before the production window. Use a representative test setup where practical, and document any differences from the installed machine that limit what a successful test tells you about the eventual change. Restart requirements determine more than the length of the download. Establish whether the update restarts the controller interrupts attached devices or requires applications to reconnect. Then include the resulting equipment checks in the time requested from production. The maintenance window needs room for a failed attempt. Allow time to apply the change. verify the required functions, and recover if those checks fail. Rather than reserving only the supplier's estimated installation time for the work, a compensating control reduces risk while the underlying weakness remains, so its purpose should describe how it restricts the conditions needed for exploitation during this temporary period. For our packing controller, that could mean restricting one engineering path. If the vulnerable function is reachable through the shared workstation. An approved temporary rule could limit that connection to a defined maintenance period, provided engineering confirms the restriction won't interrupt required work. Access restrictions can narrow the remaining opportunity further, temporarily limiting which authorized engineers can use that path, and requiring approval for each use gives the plant more control over exposure. While the update awaits its agreed window. Closer monitoring needs a defined question and someone watching for the answer. Ask the security team to review activity involving the affected service within available coverage, with an agreed escalation route if traffic falls outside the temporary operating conditions. 01:09:10 Speaker: Monitoring won't remove the weakness. It can shorten the time between observable suspicious activity and review. But the risk decision must still account for activity that produces no usable alert or occurs outside that coverage. Record the remaining risk in terms the owner can judge. State which equipment remains affected, what temporary restrictions apply, what production conditions those restrictions permit, and which unresolved exposure the organization accepts until remediation can proceed. Acceptance needs a person with the authority to carry it. That owner should understand the operational consequence and the remaining uncertainty, rather than receiving a form that treats approval as an administrative step after the technical discussion has finished. Give that decision a review date and clear limits. A missed maintenance window, an unavailable compensating control, or a change in operating requirements should bring the decision back for review instead of silently extending permission to continue unchanged. Collect the approved update instructions. Required tools and configuration records beforehand, with the responsible engineer checking that each item matches the equipment scheduled for work. Backups need to support the actual recovery method. Confirm that the saved controller, project, device configuration, and any other required material can restore the intended state using the supplier's supported procedure, rather than assuming a successful backup message proves recoverability. Check whether rollback is supported before promising it. Some updates restrict returning to an earlier release, so the recovery plan may require different steps or replacement hardware that must be available before work starts. Define when the team abandons the update attempt. The plan should name the failed checks or time limit that trigger recovery. Who authorizes that decision and how the plant confirms acceptable operation after either outcome. The temporary arrangement also needs current information to remain defensible when new security guidance appears. The next question is whether it changes the assumptions behind these restrictions or the remaining exposure at this particular plant before treating it as an emergency. Establish what the report adds to the evidence about your equipment and its exposure under current operating conditions. Threat intelligence provides information about how attackers operate. It can describe methods used to gain access, weaknesses being exploited, or infrastructure, such as domains and internet addresses associated with suspicious activity. During a reported campaign, those categories support different decisions. A report about stolen supplier credentials raises different questions from a report about a controller flaw, even when both mention manufacturing and arrive with an urgent recommendation to investigate. The useful part is the connection to your plant. Read past the affected industry and identify the conditions the reported activity requires. Then compare those conditions with confirmed equipment and services rather than matching on a familiar manufacturer's name. Suppose a new report concerns an industrial remote access product. In our hypothetical plant, the first task is to establish whether that product actually provides the supplier's entry route, including whether the affected component is present and enabled. A supplier's use of the product elsewhere doesn't establish local exposure. The connection into this plant might use a different service, so the person responsible for remote access needs to confirm the installed arrangement before the report drives production decisions. Reports about attacker methods need a broader comparison. If the reported method involves abusing legitimate remote support software, searching only for a malicious file could miss the relevant question about how approved access is being used. Ask which part of the method could work here. An attacker might need a particular account privilege or an onward connection to engineering equipment, giving the team specific conditions to check against the plant's current access arrangements. Suspicious infrastructure needs careful interpretation to an internet address associated with an attack. Can change ownership or host unrelated services, so a match requires attention to when the report observed it and what role it played. The observation date belongs beside the indicator, a connection to that address months before the reported campaign doesn't carry the same meaning as a connection during the documented activity, though neither timing alone settles whether the plant experienced compromise. Source confidence and local confidence are separate judgments. A reliable report can accurately describe an attack while leaving uncertainty about whether this plant meets its conditions. So record both judgments instead of borrowing certainty from the publisher, check what the source actually claims. Observed exploitation carries a different meaning from a researcher demonstrating a possible attack, and an assessment of likely targeting needs different treatment from evidence that a specific organization has already been affected. Trace urgent claims back to their supporting material. If several notices repeat one original report, they don't represent independent confirmation, even though seeing the same warning repeatedly can make the evidence feel stronger than it actually is. Emergency changes need a defensible local reason. The decision should explain which reported condition exists here, what evidence supports that match and why. Waiting for the normal change process would create an unacceptable exposure. Uncertainty doesn't always justify waiting. Where credible reporting points to immediate danger, the plant may need precautionary action, but the decision should name the unresolved facts rather than describing an unconfirmed threat as an established intrusion. Give OT a bounded question to answer. Instead of forwarding a long advisory with. Please assess. Identify the suspected equipment and asked the responsible engineer to confirm the installation against the reports stated conditions, then ask about the barriers that already exist. Does the reported method require access that the current boundary prevents, or is the relevant service available through a route? The report assumes an attacker can obtain ask when action can happen safely. The answer needs to reflect the equipment's current operating state and the next suitable opportunity, not simply the next empty slot on somebody's calendar during an otherwise busy shift, return that answer with its limits intact. Security needs to know whether engineering confirmed no affected equipment, found a blocked route, or identified exposure that requires action. When the process reaches an agreed condition that creates evidence the wider investigation can use. The external report supplies a hypothesis, while the plant supplies confirmed equipment, reachable services and operating constraints that help investigators decide whether observed activity belongs to a larger security event. Microsoft Sentinel is a security information and event management platform, a SIM that collects security records and helps analysts connect events from different sources around a common question. Collection is just the starting point, though, for our packaging line. The useful result connects the controller alert with records about access and activity elsewhere, letting an analyst investigate without separately requesting every supporting log from its owner. Start with the supported defender for IoT integration. For your deployment, check Microsoft's current connector documentation against the sensor management arrangement and destination environment you actually use, including prerequisites, permissions, and the information that integration delivers into Sentinel. Be precise about what arrives an integration. Delivering alerts doesn't necessarily deliver every packet, every asset field, or every observation available elsewhere. So establish which investigation questions the received records can answer before designing rules around them. Verify delivery using an approved identifiable event. Compare its source details with the record received in Sentinel, checking the fields and arrival delay so analysts understand what survives the transfer and what requires investigation in the originating system, then connect the other relevant records. Identity logs can establish authentication events, remote access logs can describe sessions, and firewall logs can show permitted or denied connections where those systems record and forward the required information. Each source answers a different part of the question. In our example, a controller alert near a supplier login becomes more informative when remote access records identify the assigned session and firewall records describe the onward connection. Business system logs can contribute another timestamped event to where an application records and exports suitable audit information. A production instruction change, or job related transaction might help explain what business activity coincided with the network event under review. Coincidence still needs interpretation, though. A shared time window helps identify records worth examining, but an analyst needs supporting identifiers and event details before claiming that one activity caused another or belonged to the same person. Time handling deserves an explicit collection standard. Preserve the event time and its time zone meaning. Distinguish it from the Time Sentinel received the record and document sources whose clocks or timestamp formats introduce uncertainty into comparisons. Late arrival can distort an apparent sequence if a remote access service forwards records after a delay. Sorting only by receipt time could place the login after the controller alert, even though the login occurred first. Asset identifiers need an equally deliberate mapping. Carry the source identifier alongside a confirmed plant reference where practical, so records naming and address, host name or application resource can be related without discarding how each source originally identified it. That mapping needs a time dimension. If an address belonged to a different device last month, today's inventory association shouldn't silently determine which machine investigators believe generated an older event. Retrieved from retained security records. Control who can query the combined information. Bringing supplier identities, plant connectivity and business activity together creates a sensitive record of operations, so configure supported access controls around investigation duties and review who receives broader visibility. Check access beyond the main incident record queries, exported results, linked workspaces and shared reports can expose different portions of the evidence, so test what each assigned role can actually retrieve rather than trusting a role name. Retention needs a reason tied to the investigation. Decide how far back analysts must compare activity. How readily older records must be searchable, and which contractual or legal restrictions govern information about suppliers and employees. Make the costs part of that decision. Collection volume, retention settings and the way older data gets queried can affect spending. So select the evidence needed for defined questions rather than forwarding every available record without review. Mismatched retention creates a predictable limit. Keeping controller alerts longer than remote session records could leave an old incident visible while removing the evidence needed to attribute access. So document those differences before somebody needs that history. The result should change how analysts work. Instead of opening another isolated OT alert queue, they should be able to follow the relevant records across sources, understand the gaps, and keep their findings attached to one connected investigation. Extended detection and response. XDR connects supported security signals so analysts can examine related activity across protected systems using the evidence available from the services connected to it. The distinction concerns the evidence behind the investigation, where Sentinel can relate records collected from many sources. Defender XDR uses integrations across supported Microsoft security services to help investigate activity within their respective areas of coverage. For our engineering workstation, that could add a closer view if defender for endpoint protects that computer and collects the relevant records, investigators may find a process associated with a connection together with information about its execution. That detail can sharpen an otherwise broad question. Instead of asking only why the workstation contacted equipment, an analyst might ask whether the application involved belongs to the approved engineering environment or represents something that needs further examination. Process evidence still has limits, though. A recognized engineering application can perform unauthorized work, so its presence gives the investigator a more specific subject to examine without establishing that the activity belongs to the supplier's approved task. Identity evidence contributes a different perspective depending on the connected services and their coverage. Defender XDR can expose identity related detections and supporting activity that help analysts examine whether access to a protected environment deserves closer review. Identity coverage needs its own boundary. Signals involving a cloud account won't automatically describe every local account or supplier identity used inside the plant, particularly where those identities belong to systems outside the connected security services. Other connected workloads can supply additional evidence. A supported email security service, for example, might contribute information about a suspicious message affecting someone involved in the investigation. If the relevant mailbox falls within that service's coverage, treat that as a possible connection to examine the existence of an email alert involving an engineer doesn't establish a relationship to controller traffic, even when the timing makes both events worth considering within the same investigation. The available evidence depends on what's actually connected. Check which security services contribute signals, which assets and identities they cover, and whether the required collection remains active before expecting defender XDR to explain activity throughout the manufacturing environment. OT evidence needs a separate integration check. Verify Microsoft's current documentation for how defender for IoT alerts and incidents become available within the supported investigation experience for your chosen deployment, rather than assuming every deployment follows an identical route. A common portal doesn't guarantee identical evidence. Establish whether analysts receive an alert and associated incident, selected supporting details, or a link to another investigation location, and test that experience using the permissions your analysts actually hold. Incident handling needs an explicit agreement to. If the supported arrangement associates OT alerts with wider incidents confirm how ownership and status changes behave, including what investigators must update elsewhere when the records don't share the same lifecycle. Don't treat automatic grouping As a final finding, a system generated association can point analysts toward related evidence, but the incident still needs review before anyone claims that the endpoint activity and the OT event share a cause. Now separate investigation rights from response rights. An analyst may need permission to inspect workstation evidence while having no authority to isolate that workstation. Because visibility supports assessment and containment changes the operating environment, those permissions should remain deliberate even within one portal. Review the supported role controls and device scoping for the deployed services, then test whether each investigator can read the required evidence without receiving unnecessary response capabilities. Administrative access deserves the same scrutiny. Someone maintaining an integration might require configuration privileges, but that responsibility doesn't automatically justify permission to execute every available response. Action against computers supporting production or engineering work. Keep the operational authority separate from technical capability. A button becoming available to an account doesn't establish that its holder has plant approval to use it, so the access design must reflect the organization's agreed decision rights. That distinction lets investigators follow evidence without silently gaining control authority. With endpoint identity and OT evidence available through verified paths. We can now examine how a suspected intrusion might cross from enterprise access into the plant. Let's extend our hypothetical case with evidence from the investigation. The identity service flags a supplier account, sign in for review, and investigators find a remote session associated with that account before the unexpected packing controller traffic. That gives us a sequence to test. The working explanation is that someone entered through supplier access, use the engineering workstation and contacted the controller, but each connection between those events still needs evidence. Start with what makes the sign in suspicious. In this example, the identity record reports an unfamiliar access location which warrants review but could also reflect the supplier's approved network arrangements rather than someone using stolen credentials. Record the authentication results separately from that assessment. A successful sign in confirms that the service accepted the presented authentication, while the question of who actually controlled the session remains open until investigators obtain further supporting evidence. The remote access record provides the next connection. Suppose it contains a session identifier linking that authenticated account to access to our engineering workstation, giving investigators a firmer association than two events occurring near each other. Preserve that identifier in the shared incident record. It lets another investigator check the association directly without depending on a narrative that gradually turns probably the same session, into an accepted fact. As people discuss the case for this hypothetical case, the endpoint telemetry shows an unfamiliar executable starting under the sessions user context, and it happens shortly before the engineering application contacts the packing controller. That observation strengthens the concern, but it leaves a gap. Just because something runs under the same user context doesn't prove that executable directed the engineering application or caused the controller exchange the network monitoring court. So you look for evidence that could close that gap process relationships, command details or application records might support a connection. If those don't exist, the proposed link stays an assumption instead of a confirmed part of the chain, the network alert anchors the controller end of the investigation. Its supporting record establishes the observed exchange from the workstation, and investigators compare that event with endpoint activity without claiming either source describes everything happening inside the controller. Maintenance records give you a separate check on the explanation. In our case, suppose the approved work record only names label station diagnostics, and the responsible engineer confirms the unfamiliar executable wasn't supplied or requested for that task. Keep those findings distinct from each other. The work record establishes the documented scope, while the engineer's statement adds informed testimony about the task from a named source investigators can contact if later evidence challenges that account confirmed events belong beside their source references. Working assumptions need the reasoning behind them. Missing evidence needs a question that somebody has responsibility for trying to resolve, right those statements so they survive a handover Account authenticated and session reached workstation describe supported events here an attacker controlled that session remains an assessment until the combined evidence supports that stronger conclusion. Missing evidence deserves more detail than logs. Unavailable state whether the workstation never collected the required activity, the records expired or retrieval remains pending. Each situation creates a different limit on what the investigation can establish. Assign one person to own the investigation throughout that owner maintains the current assessment, coordinates evidence requests, and makes sure contradictory findings receive attention. Instead of letting separate teams close their own alerts with incompatible explanations, the control engineer should review claims about engineering activity and task scope in the shared incident record. That way, security analysts don't build an intrusion narrative around a misunderstood maintenance operation. The record should explain why the assessment changes if further evidence identifies the executable as unauthorized and connects it to the engineering activity the owner can document. Why compromise now fits better than the remaining explanations. 01:26:48 Speaker: Eventually, the team must move from explanation to a decision. Once the evidence points toward compromise, the investigation owner needs to present what's confirmed, what remains uncertain, and which affected systems require a response decision from the people responsible for production. Who needs to join that response decision right now? For our packaging line, I bring the security analyst together with the control engineer and shift operator, then involve the designated safety staff and supplier according to the decisions under consideration. Each person needs a specific job. In that conversation, the analyst explains the suspected threat and its urgency. The control engineer identifies which equipment functions could change if the proposed response interrupts communication or access. The operator contributes what the equipment is doing now. That includes anything unusual at the machine, the material currently moving through it, and whether the displayed status matches what the operator can observe on the floor. Safety staff assess questions within their assigned responsibilities, where a proposed action could affect protective functions or safe operating conditions, they help determine which established procedures and restrictions govern the decision before the team proceeds. The supplier can answer equipment specific questions local staff can't resolve. Ask for the expected behavior under the proposed interruption, with an explanation grounded in the installed configuration rather than a general assurance about the product. Family advice and authority. Need separate names? A supplier might explain a controller's behavior, but the plant must identify who can accept the operational consequences. Instead of treating outside technical advice as permission to act during this response, its analysts keep the threat assessment current and communicate changes in urgency. That way, plant staff aren't making decisions against an assessment. Security has already revised that coordination needs a plant contact. Who can answer the response procedure should identify the person on duty and their deputy, rather than relying on an engineering manager who might be unreachable when the incident occurs. Decision rights need to be specific to the action network. Isolation, changes to accounts and a production stop can involve different authorities. Even when one incident creates the need to consider all of them. Network authority needs a defined operational boundary state who can approve isolation affecting the packaging line, who assesses its process consequences and who performs the change once the required approval or emergency authority applies. Account changes need their own approval conditions. Removing access might affect people or services beyond the suspected session, so the authorised decision maker needs to understand the account's use before approving a change, with wider consequences. Production stops follow the plant's established authority and procedures. The incident process should identify who can direct that decision under the circumstances, while preserving existing emergency powers when people need to act immediately to protect safety. Agree those responsibilities before the call becomes an argument. A useful instruction names the role, its authority and the escalation route, including what the team does when the usual approver doesn't respond within the required time. Urgent decisions still need a brief explanation. The person requesting action should state the observed threat, the likely cost of delay, and the uncertainty that remains. Giving plant staff something concrete to weigh against operational consequences before an analyst requests a memory capture or another live system procedure, the control engineer should assess whether that collection could affect the computer's current work or demand resources. The process depends on some evidence may disappear while that assessment takes place. Security should explain which records are short lived and why they matter, allowing the plant to judge urgency without assuming every collection request deserves immediate access to operating equipment collection should fit the conditions, not dictate them. Where live capture carries unacceptable operational risk, use available evidence from other sources and record the resulting limitation. Rather than pressuring an engineer to approve a procedure they can't assess. Safe process control takes precedence over a perfect evidence set. If urgent action prevents collection, document what the team couldn't preserve and why with the decision time and responsible roles so later reviewers understand the trade off. Before choosing containment, the operator and control engineer need to establish what's moving, what remains under control, and which interruption the equipment can tolerate at that moment. Containment starts with choosing which access to remove. For a hypothetical line, the team considers ending the supply as access, restricting the engineering workstation or blocking the confirmed connection to the packing controller while preserving required machine communication. Those choices interrupt different parts of the suspected intrusion. The engineer needs to assess each one against the installed configuration, including whether it affects commands, operator readings or any service required to keep equipment within its approved operating conditions. Ending supplier access might remove the external entry point before proceeding. Confirm whether the action terminates the existing session, prevents reconnection or both, and whether anything already running on the workstation would continue. After that session ends. The controller might remain reachable from inside the plant if the suspected activity can continue locally on the workstation. Closing the supplier session addresses one root without necessarily stopping the activity that prompted the containment decision. Restricting the workstation could interrupt that onward activity. The engineer must first establish whether the computer currently performs only engineering work or also supplies information or services the running line requires beyond the supplier's maintenance task, a targeted restriction may preserve more required functions than full isolation. That depends on whether the available control can separate the unwanted connection from legitimate exchanges, and whether engineering can verify the resulting behavior without creating another uncontrolled interruption. Blocking the confirmed path narrows the action further. For example, the network team could propose denying the workstations connection to the packing controller while leaving, the controllers required exchanges with its operator station and other approved systems intact. The engineer still needs to assess the interrupted exchange. If an engineering operation is underway. Cutting communication could leave a tool reporting an uncertain result, so the team needs equipment specific guidance about what interruption means in that state. Preserving operator visibility needs an explicit check. After any proposed restriction, the operator should retain the readings and permitted controls needed for the current process, with engineering defining how to verify those indications remain trustworthy. The response plan should name the expected result. Supplier session ended. Workstation connection denied. Operator status still updating. Gives the team observable conditions to check. Rather than treating a successful firewall change as proof containment worked, apply only the containment steps approved for those conditions. Record the exact target and scope before execution. Then have the responsible engineer and operator check the agreed process indicators as the network or access restriction takes effect. Keep fallback communication outside the affected root. If the change could interrupt the normal messaging or remote support channel, agree and approved alternative that lets the operator, engineer and security lead remain in contact throughout the action. That fallback needs a quick check before execution. Everyone involved should know whom to contact if machine behavior changes, what information to report, and who can direct the next step without relying on the restricted workstation. The person applying the restriction needs an approved way to reverse that specific change. That means access that won't disappear when the restriction takes effect, plus a clear trigger for using it if the process checks fail. Engineering and security need to judge whether reversing the restriction still makes sense or whether the plant must move to another approved operating condition instead. Its use and any controlled shutdown must follow the plant's established safety procedures for the actual hazard and equipment state. An analyst shouldn't assume that stopped equipment always means safer equipment. The people authorized under those procedures decide which action fits the conditions. That includes how the process reaches a safe state and what must remain powered or controlled along the way. In our example, the suspicious connection might disappear after the restriction, but the team should check that observation against monitoring health and the expected blocked path before declaring the access contained. Even with the immediate route contained and the line under control, the plant still needs to determine what changed during the incident before trusting the equipment's operating state again. For the packing machine, the responsible engineer should identify the approved program revision and configuration that represent the machine's intended state at this point in its service life. A controller project saved before the incident might still lack an authorized modification. Age alone won't establish whether restoring that project would return the machine to its intended configuration. Compare the candidate recovery version with completed engineering changes, including any machine adjustments that should appear in the program or associated settings, but haven't reached the central project archive. Through a supported comparison method and under appropriate equipment conditions, the engineer can check the installed program against that approved reference. Investigate differences before deciding what requires restoration. Some differences may relate to legitimate changes or values maintained during operation. The engineer must distinguish those from unexplained changes using the controller's supported tools and engineering records. Communication settings, device assignments, and retained parameters can affect machine behavior even when the main control logic matches. The recovery scope should reflect what this installation actually stores separately. If rebuilding it forms part of recovery, use verified installation media and approved software packages. Don't treat an image taken from the suspect machine as a clean starting point. Protected storage with restricted write permissions and a separate recovery copy, where appropriate, reduces the chance that the same compromised credentials could alter both the working system and its replacement material available. Integrity checks can establish whether a recovery file matches its recorded copy. Engineering approval establishes whether that copy represents the configuration the machine should actually run. A file can remain unchanged since storage, yet still contain the wrong revision, particularly when several similarly named projects exist for machines with closely related equipment or functions. The engineer and operator should follow the machine's established startup sequence, checking readiness conditions before introducing material. Don't assume a restored controller is immediately ready for normal production for our packing machine. Those could include the expected sequence of movements and responses to product position signals. Check those under the plant's approved procedure before unrestricted flow resumes. Confirm that the operator station receives current status required. Production information reaches the machine and completion information returns to the intended application. Do this wherever those exchanges form part of this line's approved operation, a service might reconnect successfully while supplying an outdated product selection or incorrect parameter set. Compare the information used by the equipment with the production job authorized for restart quality. Staff should determine which checks apply to the first output after recovery, and which material from the uncertain period needs holding or assessment under the plant's existing quality procedures. Confirm that packaging and product identification meet the applicable requirements. The relevant production records should support the result, rather than relying only on a machine status that reports a successful operation, namely approved configuration, the completed restart checks and any remaining restrictions. That way, the next shift understands exactly what engineering and quality have released for use on the line. If staff couldn't identify the correct project or verify a required service, promptly turn that gap into a specific correction, its completion should be demonstrable through a later recovery check. The next exercise should prove that someone can retrieve the approved material, perform the required checks, and reach the same release decision without depending on whoever solved it. This time, I'd start with work that helps people assess an incident faster rather than work that changes what equipment or engineers can reach during production. Playbooks use Azure Logic apps with supported connectors and permissions, determining which external systems they can query, notify, or update as part of that workflow. When a relevant OT alert arrives, a playbook could retrieve the associated asset owner from an approved register and attach that information to the investigation that works, provided the lookup returns a reliable match. If the register contains two possible owners or no matching asset, the workflow should flag that uncertainty instead of selecting whichever entry happens to appear first in the response. Through a supported connection to the service management system, automation can create a ticket containing the incident reference, affected asset and unresolved questions. It shouldn't declare a root cause. Nobody has established a workflow can notify the designated plant contact, but a successful send doesn't establish that someone read the message or accepted responsibility for the requested review during that shift. Expired credentials, unavailable connectors and changed record formats can stop enrichment or ticket updates. Give those failures an owner and make them visible outside the failed workflow. If a proposed action could alter control system connectivity or production access, require the authorized person to review its exact target scope and expected effect before execution can proceed. If the target changes after someone approves it or the request sits unanswered beyond its permitted period, the workflow should stop and request another decision rather than reuse stale permission. Bring the supplier access case back to the group. Present the evidence in stages, and ask participants to work through the automated handoffs using their actual roles. Suppose enrichment returns an outdated contact and the ticket reaches an unstaffed queue. Ask who notices how they escalate and whether the approval request still reaches someone authorized to decide. Have participants explain how that loss changes their confidence. Which automated steps can still use other evidence, and which conclusions must wait because the expected observation is no longer available. If someone assumes the absence sensor would confirm that containment worked, pause there and ask what the team can actually establish from the records still available to it. Asset ownership can be tracked through the proportion of In-scope records, with a verified responsible team and a usable contact. Don't count every populated owner field as complete record, which required communication paths remain unchecked. How long those gaps stay open and whether plant checks resolve them. Don't award progress merely because another sensor starts reporting. Measure the interval from an actionable alert to a documented assessment by the right people. Review whether faster handling leaves more assumptions unresolved or sends work back for correction. Track whether the assigned team can perform the agreed recovery checks successfully. Defects found during the test should receive correction and another test, rather than disappearing into a closed exercise report. A larger alert count might reflect better visibility. Noisier rules or newly observed activity judge expansion by whether people can make and verify safer decisions with the evidence available. If automation delivers more notifications but nobody can approve the resulting action, the plant has gained a faster way to send an unanswered question. That might be a plant where supplier support reaches several production areas, and where the plant manager and engineering lead agree that narrowing that reach deserves scheduled work. The easiest site isn't always the best place to start a plant with brand new equipment, but no engineering time available can leave your project stuck. Waiting for decisions. While a facility with mixed equipment and committed owners can give you a workable scope to work with. Keep that initial scope small enough that you can actually finish it. Pick a production area where your team can review the equipment, network connections, and support arrangements together, and set clear boundaries on which adjacent systems stay outside the first deployment. Give the site lead real authority to secure people's time. Central security can provide technical guidance, but someone at the plant needs to coordinate engineering participation, operating windows and decisions that would otherwise compete with immediate production demands. Agree on the entry conditions before any installation work begins, the project needs to know which asset records require verification, which passive observation points need checking, and which plant contact will accept an incident handoff during each operating shift. Turn those conditions into actual acceptance evidence. Instead of accepting inventory complete, ask the site team to demonstrate that a selected alert can connect to the correct equipment, record and route to someone responsible for that equipment test the handoff across a real shift boundary. The outgoing contact should transfer an unresolved example to the incoming contact through the agreed process. Letting the project find gaps before a live incident depends on that transfer coverage acceptance should involve the local network owner. Have that person confirm the agreed monitoring paths alongside the control engineer, and record any excluded equipment or operating conditions as limits on the deployments accepted scope. Separate observation readiness from permission to change access. A site can complete its monitoring checks while still needing engineering work before segmentation changes, so the rollout schedule shouldn't treat sensor acceptance as approval for immediate enforcement. Build enforcement into the maintenance plan in stages. Start with a defined boundary or access relationship whose consequences the local team can assess and reserve the equipment checks and recovery tests needed before expanding the restriction. A completed change should release the next stage only after review. If the maintenance window ends with unresolved behavior or an unproven recovery step. Keep that stage open rather than carrying uncertainty into another production area. Schedule recovery tests as actual plant work, they need assigned people an agreed environment and enough time to demonstrate the relevant recovery procedure, rather than an assumption that engineering will fit the test around another shutdown. Expansion should reuse the decisions that survived those checks. Central teams can provide policy templates, acceptance criteria and role descriptions from the first site, reducing repeated design work without pretending that another plant has identical operating requirements. Treat each template as a proposal at the next site. A rule allowing an engineering service might suit one controller installation, yet fail at another, where the installed equipment requires a different supported connection or maintenance method. Process differences can change the consequence of the same restriction. A connection interrupted between batches might create a different problem from that connection disappearing during continuous operation, so the local process owner needs to assess its timing. Supplier arrangements need a fresh check as well. One site may receive support through the corporate service route, while another has a separate equipment contract that requires negotiation before the same access policy can take effect. Keep local departures visible and owned. Record wire site differs. Who approves that difference and what would permit it to adopt the shared policy. So exceptions remain engineering decisions rather than undocumented habits. I'd make readiness a joint sign off. Central security confirms that the agreed evidence and controls work, while plant representatives confirm the operating checks and available recovery arrangements for the scope being released. That sign off should name the people who inherit the system before moving the project team elsewhere. Ask the incoming owners to explain who can authorize the next response and under which operating conditions they can safely proceed. Finding the controller leaves a decision unfinished. Visibility becomes useful when its record leads to a named owner, and an approved response that the plant has tested under the conditions where it might actually be needed. An identified controller without a tested containment path leaves the response unresolved. How do you divide containment authority between your security team and the people running the plant, especially when they disagree about timing?