InfoSec Made Easy
OT Security Leadership | NCSC Guidance Series
Why logging and monitoring is your last line of defense in OT — and what effective OT visibility actually requires
All security controls, however well-designed, carry the possibility of failure. Boundaries can be breached. Segmentation controls can be circumvented. Authentication mechanisms can be defeated. Protocols can be exploited. There is no configuration of preventive controls that provides absolute certainty that an OT environment will never be compromised. This is not a counsel of despair — it is a statement of operational reality that serious security programs accept and design around.
Principle 7 of the NCSC's Secure Connectivity Principles for Operational Technology is the control that remains effective even when every other control has been bypassed: comprehensive logging and monitoring. When an attacker defeats your boundary, navigates your segmentation, and reaches a critical OT asset, monitoring is the mechanism by which that activity can be detected. Without monitoring, compromise can persist for months or years before being discovered. With effective monitoring, organizations can detect, investigate, and respond to compromises while the window for containment is still open.
The NCSC guidance frames monitoring starkly: it is your last line of defence when designing secure connectivity. For security leaders, this principle demands investment in visibility that matches the investment in preventive controls. A highly secured OT environment with poor monitoring is an environment whose security posture cannot be verified — you cannot know whether your controls are working if you cannot see what is happening inside your environment.
The Goal of Logging: More Than Just Collection
Many OT organizations have some logging in place. Fewer have logging that is actually useful for detecting security compromises. The NCSC guidance draws a clear distinction between logging as data collection and logging as security capability: the end goal of logging is not to collect logs, but to make compromise detection easier.
This distinction has practical implications for how logging programs are designed. Collecting everything and storing it somewhere is not a monitoring program — it is a data accumulation exercise. An effective monitoring program starts from a threat model: what are the specific ways that attackers might exploit this OT environment? What would those attacks look like in the log data? What logging and packet captures are needed to support the detection of those specific attack patterns? The answers to those questions drive the design of the monitoring program — ensuring that the logs collected are the ones needed to detect the threats that matter, not just the logs that happen to be easiest to collect.
For OT environments, this threat-informed approach to logging design is particularly important because OT systems often have limited logging capabilities compared to modern IT systems. You may not be able to collect everything — so you need to be intentional about what you collect and why. Understanding where attackers are most likely to be active in your environment allows you to concentrate logging and monitoring resources where they will be most effective.
💡 Pro Tip: Before expanding logging coverage in your OT environment, conduct a threat model exercise that identifies the three to five most likely attack scenarios relevant to your specific environment and threat context. Then work backward from each scenario: what would this attack look like in log data? Do we currently collect the logs that would show this activity? This exercise almost always reveals specific, high-priority logging gaps that are more important to close than expanding general coverage. Fix the highest-risk gaps first, then broaden coverage systematically.
Establishing a Baseline: The Foundation of Anomaly Detection
Effective monitoring requires a baseline — a documented picture of what normal activity looks like in the OT environment. Without a baseline, everything is noise. With a well-established baseline, deviations stand out and can be investigated efficiently. In IT environments, establishing baselines is challenging because the diversity of user behavior and application activity creates complex, hard-to-characterize normal patterns. In OT environments, this challenge is significantly easier — OT systems operate in highly repetitive, predictable patterns that are relatively straightforward to characterize.
A well-characterized OT baseline documents the specific communication patterns for each connection in the environment: which devices communicate, at what frequency, using what protocols, with what command types and data value ranges. Because OT processes tend to be highly consistent — a pump runs at a specific speed, a temperature is maintained within a specific range, a sensor reports readings at a specific interval — the baseline for these systems can be very precise. Deviations from this precise baseline are meaningful signals, not background noise.
This characteristic of OT environments — the predictability and repetitiveness of normal operations — is one of the reasons that anomaly detection can be particularly effective in OT security. The NCSC guidance acknowledges this explicitly, noting that OT systems' relatively static, repetitive processes characterised by consistent command structures create favorable conditions for anomaly detection. A device that has been communicating with a specific controller at five-second intervals for years, which suddenly begins communicating with a different device or using a different command set, is showing behavior that is anomalous in a way that is immediately distinguishable from background variation.
However, the guidance also includes an important caution: anomaly detection should not replace technical controls. Anomaly detection is a detective control — it identifies what is happening. It is not a substitute for the preventive controls that restrict what can happen. An anomaly detection system that fires an alert when a prohibited command is issued is less effective than an architecture where that command is blocked before it can be issued at all. Monitoring and preventive controls work best as complements, not substitutes.
OT-Specific Monitoring Considerations
The NCSC guidance identifies several OT-specific monitoring requirements that go beyond standard IT security monitoring practices. These reflect the unique operational context of OT environments — environments where changes are tightly controlled, where maintenance windows are planned in advance, and where operational processes have specific characteristics that create both monitoring opportunities and monitoring challenges.
Unauthorized activity detection: In OT environments, changes are managed through strict controls including detailed planning, change logs, and advance notifications. This makes unauthorized changes — those that occur outside the change management process — particularly detectable. Monitoring should specifically look for activity that does not correspond to a documented, authorized change. This requires integration between the monitoring system and the change management process: the monitoring system needs to know what changes are planned so it can distinguish authorized maintenance activity from unauthorized changes that mimic maintenance activity.
The guidance includes an important process note: monitoring rules that are disabled during maintenance windows to reduce false positives must be re-enabled when the maintenance window closes. This is a control that is easy to overlook in the operational pressure of managing a complex maintenance event — but leaving monitoring disabled after maintenance is complete creates exactly the detection gap that a sophisticated attacker would exploit by timing their activity to follow a known maintenance window.
Break-glass access monitoring: Break-glass accounts — emergency access credentials that bypass normal authentication controls — represent a specific high-risk monitoring requirement. These accounts exist for legitimate emergency purposes, but their use should be extraordinarily rare. The guidance specifies that any attempt to use a break-glass account should trigger the highest criticality alarm in the Security Operations Centre. Break-glass access is not a mechanism for convenience or for bypassing security controls when they are inconvenient — it is for genuine operational emergencies, and every use should be treated as a potential security event until investigation confirms otherwise.
Data flow monitoring: Continuous monitoring of data flows within and between network segments validates that segmentation policies are working as intended and provides early detection of compromise or misconfiguration. In a well-segmented OT environment, the communication patterns between zones should be highly consistent — the same types of traffic, in the same directions, at roughly the same volumes. Deviations — new traffic flows between zones, increased data volumes that might indicate exfiltration, unusual protocol types crossing zone boundaries — are indicators worth investigating.
📋 Example: OT Monitoring Program Design
A water utility designs its OT monitoring program around its three highest-priority attack scenarios: (1) an attacker using vendor remote access credentials to access SCADA and attempt to modify setpoints; (2) ransomware propagating from a compromised workstation into the OT network; (3) an insider changing PLC parameters outside a change management window. For scenario 1, monitoring captures all sessions through the vendor remote access gateway, alerts on any command that would modify a setpoint or configuration, and cross-references session activity against the vendor support schedule. For scenario 2, monitoring tracks lateral connections between network zones, alerts on new connections between the IT and OT network, and monitors for encryption activity that could indicate ransomware. For scenario 3, monitoring alerts on all PLC programming commands that occur outside approved change windows, with immediate notification to the control room and security team. Each monitoring use case is designed around a specific, credible threat — not generic security best practices.
Building OT-Capable SOC Operations
Effective monitoring requires not just the technical capability to collect and analyze OT logs, but the organizational capability to respond to what monitoring reveals. In most organizations, the Security Operations Centre was built around IT security monitoring — the threat intelligence, detection logic, playbooks, and analyst skills were developed for IT environments. Extending this capability to OT requires both technical integration and significant knowledge development.
OT-specific monitoring tools have matured significantly, with dedicated OT network monitoring platforms that understand industrial protocols, build OT-specific asset inventories from network traffic, and detect OT-specific threats. Integrating these tools with existing SIEM and SOC platforms allows OT security events to be contextualized within the broader threat picture, and allows the SOC to respond to OT events using established incident response processes rather than improvising in OT environments they may not fully understand.
The analyst skill gap is equally important. SOC analysts who are expert in detecting and responding to IT security events may not understand the operational significance of an OT security event — what it means for process safety, what the appropriate response is, and when escalation to operations engineering is required. Closing this gap requires training, knowledge sharing between security and operations teams, and the development of OT-specific playbooks that give analysts clear guidance for the most likely OT security scenarios.
💡 Pro Tip: One of the most effective investments in OT SOC capability is a joint tabletop exercise that brings security analysts and operations engineers together to work through a realistic OT security scenario. The exercise reveals knowledge gaps on both sides: security analysts learn what operational significance specific OT alerts have, and operations engineers learn how to recognize and report security events. The relationships and shared understanding built in these exercises pay dividends when a real incident occurs and fast, coordinated response is needed between security and operations teams.
The Role of Device Manufacturers in OT Logging
The NCSC guidance acknowledges a systemic challenge in OT monitoring: many OT devices were not designed with security logging in mind. Legacy PLCs, older SCADA components, and some field devices may have limited or no logging capabilities — they simply do not generate the log data needed to support security monitoring. This creates monitoring gaps that cannot be closed by deploying better monitoring tools, because the data is not being generated at the source.
The guidance calls on manufacturers to ensure that standard logging and forensic features are robust and secure by default. This is a long-term improvement to the OT security ecosystem, but it takes time to work through the installed base of existing devices. In the interim, organizations should compensate for device-level logging limitations through network-level monitoring — capturing packet data at network boundaries and segments that can provide behavioral visibility even when device logs are unavailable — and by ensuring that the devices at the boundary and in management infrastructure have comprehensive logging enabled.
The NCSC has published specific guidance on digital forensics and protective monitoring specifications for network device and appliance manufacturers. For organizations selecting new OT devices and network infrastructure, using these specifications as evaluation criteria in procurement can help ensure that the next generation of OT equipment provides the logging capability needed for effective security monitoring.
📋 Key Ideas: What Strong Principle 7 Implementation Looks Like
- Logging design is threat-informed: monitoring is built around specific, credible attack scenarios, not generic data collection.
- A documented baseline of normal OT communication patterns enables anomaly detection that distinguishes meaningful deviations from background variation.
- Monitoring covers all connectivity at zone boundaries, all vendor and remote access sessions, all change activity, and all break-glass account use.
- Break-glass account use triggers the highest criticality alert; every instance is investigated as a potential security event.
- Monitoring rules disabled during maintenance windows are formally re-enabled when the window closes, with process accountability for this step.
- OT monitoring is integrated with SOC operations, and analysts have OT-specific training and playbooks to respond to OT security events appropriately.
- Network-level monitoring compensates for device-level logging gaps in legacy OT systems.
Monitoring as a Compliance and Governance Tool
Beyond its primary security function, comprehensive OT logging and monitoring serves important compliance and governance purposes. Regulatory frameworks governing critical infrastructure increasingly require organizations to demonstrate active security monitoring — not just to have controls in place, but to be actively watching for threats and capable of detecting security events in a timely manner. An OT environment with comprehensive monitoring can provide regulators with concrete evidence of active security oversight: alerts triggered, investigations conducted, incidents detected and responded to, normal baselines established and maintained.
Monitoring data also provides the evidence base for demonstrating that other security controls are working as intended. Segmentation policies can be validated through traffic flow monitoring — do the logs show that traffic is following the expected patterns and that prohibited flows are being blocked? Vendor access controls can be validated through session logs — are vendors accessing only the systems they are authorized to access, during authorized windows, with activity that corresponds to their stated purpose? This monitoring-based control validation is increasingly what regulators and auditors want to see, rather than just documentation of control design.
💠Final Thought
You cannot defend what you cannot see. In OT environments, where the consequences of undetected compromise can include physical harm and essential service disruption, the inability to detect threats in a timely manner is not just a security gap — it is an operational and safety risk. Comprehensive logging and monitoring is not the most technically complex of the eight NCSC principles, but it may be the one with the most direct impact on the organization's ability to respond to real-world threats. Every security control in the preceding principles is more effective when monitoring can verify that it is working — and can detect when it is not. Invest in visibility with the same seriousness you bring to prevention, and you will have a security program that is both proactive and resilient.
This article is part of the InfoSec Made Easy series on the NCSC Secure Connectivity Principles for Operational Technology. Read the full series at www.infosecmadeeasy.com.