Industrial control systems underpin some of the most critical infrastructure in the UK. They manage energy distribution, water treatment, manufacturing processes, and transport systems. They were not designed with cybersecurity as a primary requirement. Many of them are still running software and firmware written before the threat landscape that now targets them existed.
That gap between the design assumptions built into these systems and the reality of the environments they now operate in is where ICS security sits. Not as an academic discipline, but as a practical engineering and operational challenge with physical consequences when it goes wrong.
This guide explains what ICS security involves, why it differs from IT security, the techniques used to assess and improve it, and what organisations responsible for industrial control systems need to understand to protect them properly.
In This Guide
- What Is ICS Security?
- ICS Security vs IT Security
- Why ICS Security Matters
- ICS Security Techniques
- Security for Industrial Protocols and Embedded Systems
- Where ICS Security Fits in the Development Lifecycle
- What Good ICS Security Output Looks Like
- How CyTAL Approaches ICS Security
- Common Questions About ICS Security
What Is ICS Security?
ICS security is the discipline of protecting industrial control systems from cyber threats. Industrial control systems are the hardware and software combinations that monitor and control physical processes: programmable logic controllers that manage manufacturing equipment, distributed control systems that regulate industrial processes, supervisory control and data acquisition systems that provide visibility and control across large infrastructure assets, and the communication networks and protocols that connect them.
The scope of ICS security covers the full range of assets and activities involved in operating these systems securely. That includes the security of the devices themselves, the protocols they use to communicate, the networks they operate on, the software used to configure and manage them, the interfaces through which operators and engineers access them, and the connections between OT networks and the IT infrastructure and cloud platforms they increasingly connect to.
What ICS security is not is a specialisation that sits at the margins of cybersecurity. Industrial control systems underpin critical national infrastructure across energy, water, transport, and manufacturing. The organisations that operate them, and the manufacturers and system integrators that build and maintain them, carry significant responsibility for the security of systems whose failure could cause physical harm, environmental damage, and disruption to services that people depend on.
ICS Security vs IT Security
ICS security and IT security address related problems using overlapping but distinct approaches. Understanding the differences is necessary for organisations that are applying IT security frameworks and tools to OT environments, which is one of the most common and consequential mistakes in industrial cybersecurity.
IT security focuses on confidentiality, integrity, and availability, in that order of priority in most frameworks and programmes. The primary assets are data and the systems that process it. The primary threats are data theft, unauthorised access, and service disruption. The tools, frameworks, and practices that have evolved to address those threats are mature, widely deployed, and well understood.
ICS security inverts that priority order. Availability comes first, because the systems being protected are often running processes that cannot be safely interrupted. Safety comes before security in environments where a system that fails insecurely can cause physical harm. Integrity matters in a different sense: not just the integrity of data, but the integrity of the commands being sent to physical equipment and the sensor data being used to make control decisions. Confidentiality, while still relevant, is typically a lower priority than in IT environments.
The tools and frameworks designed for IT security do not map cleanly onto OT environments because of these different priorities. Aggressive scanning that is routine in IT security can disrupt OT devices that were not designed to handle unexpected network traffic. Patch management practices that are standard in IT are often impractical for OT systems where patching requires process downtime and vendor validation. Vulnerability disclosure timelines designed around IT software lifecycles do not reflect the operational realities of industrial systems with decade-long deployment periods.
Why ICS Security Matters
The threat to industrial control systems is real, active, and escalating. Nation-state actors have demonstrated both the capability and the intent to target industrial infrastructure, with documented incidents including attacks on energy distribution, water treatment, and manufacturing systems across multiple countries. Criminal groups have extended ransomware campaigns to industrial operators, recognising that the operational consequences of system unavailability create pressure to pay that is often greater than in pure IT environments. Supply chain attacks targeting the software and devices that underpin industrial systems have demonstrated that the attack surface extends well beyond the operational boundary of any individual organisation.
The consequences of a successful ICS attack are not limited to the operational disruption that any significant cyber incident produces. Manipulation of physical processes can cause equipment damage, environmental harm, and in the most serious cases, harm to people. The 2021 Oldsmar water treatment incident, in which an attacker briefly changed the chemical dosing levels in a Florida water system, demonstrated how directly a cyber compromise of an industrial control system can translate into a potential physical safety event. The Triton malware, designed specifically to disable safety instrumented systems in industrial facilities, demonstrated that threat actors are explicitly targeting the safety systems whose purpose is to prevent physical harm.
For manufacturers and system integrators, the ICS security imperative extends beyond their own operations to the products and systems they build. A manufacturer that ships a product with exploitable vulnerabilities in its protocol implementation has created risk not just for itself but for every organisation that deploys that product. The regulatory and contractual frameworks that are developing around ICS security, including IEC 62443 and supply chain security requirements from operators of critical infrastructure, reflect a recognition that product security is a shared responsibility across the industrial supply chain.
ICS Security Techniques
ICS security draws on a range of techniques adapted from IT security and developed specifically for OT environments. The right combination depends on the specific systems being assessed, the phase of the lifecycle they are in, and the risks being addressed.
Network segmentation and architecture assessment reviews the boundaries between OT networks and IT networks, external connections, and the internet. The architecture of an industrial network determines a large proportion of the attack surface it presents. Connections that were established for operational convenience without security review, poorly defined boundaries between IT and OT environments, and remote access infrastructure that was added without appropriate controls are consistently among the most significant findings in ICS security assessments.
Configuration review and hardening assesses the security configuration of industrial devices, control systems, and network infrastructure against defined security baselines. Default credentials, unnecessary services, insecure protocol configurations, and missing authentication controls are common findings that represent significant risk and are often straightforward to remediate once identified. Configuration review is one of the highest-value activities in ICS security because it finds problems that are easy to fix and carries low operational risk.
Vulnerability assessment identifies known and unknown vulnerabilities in the components and systems within scope. For ICS environments, this requires tools and methods specifically designed for OT systems, because standard IT vulnerability scanning can disrupt industrial devices that were not designed to handle the traffic it generates. Passive assessment techniques that observe rather than probe are often the appropriate approach for production environments, with active assessment conducted in test environments where possible.
Protocol security testing examines the security of the protocols used by industrial control systems, which is where a significant proportion of ICS vulnerabilities are found. Industrial protocols were largely designed for reliable communication in trusted environments, not for security against adversarial inputs. Vulnerabilities in how devices implement these protocols, in how they parse and respond to protocol messages, represent a large and frequently underassessed part of the ICS attack surface. Protocol security testing requires tools that understand the specific protocols being tested and can generate the protocol-aware test cases needed to find implementation vulnerabilities.
Security for Industrial Protocols and Embedded Systems
Industrial protocols are the communication layer through which ICS components exchange commands and data. They are also one of the most significant and least well-assessed parts of the ICS attack surface. Understanding why protocol security matters and what assessing it properly requires is central to any serious ICS security programme.
The protocols used in industrial environments, including Modbus, DNP3, IEC 61850, IEC 60870-5-104, and DLMS COSEM among others, were designed for reliability and interoperability in environments that were assumed to be physically isolated and operationally trusted. They were not designed with the assumption that the devices implementing them would receive malformed, malicious, or unexpected messages from an attacker on the network. As industrial environments have become more connected, that assumption has become progressively less valid.
Vulnerabilities in protocol implementations typically arise in the parsing logic that processes incoming messages. A device that receives a message with a field value outside the expected range, a message length that does not match the declared length, or a command sequence that violates the protocol state machine may crash, expose sensitive information, enter an undefined state, or execute unintended behaviour. These are not hypothetical vulnerabilities. They are consistently found in real products when subjected to systematic protocol security testing, including in products from well-established vendors with mature security programmes.
Embedded systems compound the protocol security challenge. The devices that implement industrial protocols are often resource-constrained embedded systems with limited processing power, memory, and storage. They may run operating systems or runtime environments that do not include the security features available in standard IT systems. They may have been in production for years or decades without security updates. And they often cannot run the endpoint monitoring agents that IT security monitoring relies on, making their behaviour visible only through the network traffic they generate.
Effective security assessment of industrial protocols and embedded systems requires tools that understand the specific protocols being tested and can generate test cases that are structurally plausible but contain specific targeted flaws. Random or generic test inputs will be rejected at the protocol framing layer before reaching the application logic where most vulnerabilities sit. Protocol-aware fuzz testing , using tools with formal models of the protocols being tested, is the approach that finds the vulnerabilities others miss.
Where ICS Security Fits in the Development Lifecycle
ICS security is most effective when it is integrated throughout the development lifecycle of industrial products and systems rather than assessed as a final step before deployment. The earlier a vulnerability is identified, the cheaper it is to fix and the lower the risk that it reaches a deployed product.
At the design stage, ICS security shapes architecture decisions. Which protocols will the product implement? How will it handle invalid or unexpected inputs? What authentication will be required for sensitive commands? How will the product behave when it receives a message that violates the protocol specification? These questions are cheapest to answer before implementation begins, because the answers determine the architecture, and architectural changes after implementation are expensive.
During development, component-level and integration-level security testing verifies that the implementation matches the security design. Protocol implementation testing at the unit level finds parsing vulnerabilities before they are integrated into a production firmware image. Interface testing at the integration level finds vulnerabilities that only appear when components interact. Both are far cheaper to address at this stage than after a product has been deployed to thousands of sites.
Pre-release security assessment provides the documented evidence that regulatory compliance and customer assurance requirements demand. IEC 62443-4-1 Practice 6 requires vulnerability testing with negative testing and robustness testing for all external interfaces. This evidence needs to be produced before the product ships, not after a vulnerability is reported in the field. The quality of this evidence determines whether certification can be obtained and how credibly the manufacturer can respond to customer security questions.
Post-deployment, ICS security becomes an ongoing responsibility. Vulnerabilities are discovered in deployed products. The threat landscape evolves. Deployment environments change. Manufacturers that treat security as a development activity rather than a product lifecycle responsibility will find themselves managing a growing backlog of unaddressed vulnerabilities in deployed products, with limited ability to respond credibly to the customers and regulators who are asking increasingly specific questions about product security.
What Good ICS Security Output Looks Like
The output of ICS security activities determines whether they produce genuine security improvement or generate documentation that satisfies compliance requirements without informing the decisions that reduce risk. Understanding what good output looks like helps organisations commission security work that produces results they can act on.
Technical findings need to be precise. A finding that describes a vulnerability class without documenting the specific input that triggered it, the specific device behaviour that resulted, and the specific conditions under which the vulnerability is exploitable does not give the engineering team what it needs to understand, reproduce, and fix the problem. Good ICS security output documents findings with enough precision that an independent assessor could reproduce them and verify that remediation was effective.
Risk scoring needs to reflect the ICS context. A vulnerability that would be rated medium severity in an IT environment may be rated critical in an ICS environment if its exploitation could affect a safety system or a process with physical consequences. Generic severity ratings drawn from IT vulnerability frameworks without adjustment for the ICS deployment context do not support meaningful prioritisation for industrial products and systems.
Compliance mapping needs to be specific and traceable. IEC 62443-4-1 Practice 6 SVV-3 requires that vulnerability testing evidence includes traceability from test cases to the security requirements being verified. A security testing report that documents findings without connecting them to specific IEC 62443 requirements, or that asserts compliance without the technical evidence to support it, will not satisfy a certification audit. Good ICS security output is structured from the outset to satisfy these requirements, not retrofitted to meet them after the fact.
Remediation guidance needs to be actionable in the ICS context. A recommendation to apply a patch that the vendor has not validated for the device in question, or to change a configuration that would require a process shutdown to implement, is not actionable in the short term. Good ICS security output includes interim mitigations for findings that cannot be immediately remediated, not just the theoretically correct long-term fix.
How CyTAL Approaches ICS Security
CyTAL provides security assessment and assurance for manufacturers, operators, and system integrators across the industrial sectors where ICS security failures have physical consequences: industrial control systems, smart energy infrastructure, telecoms, and cyber-physical systems including access control.
Our ICS security work is built around the specific systems and protocols being assessed. We use tools and methods designed for operational technology environments rather than adapted from IT security tooling. Where protocol security testing is required, we test against formal models of the specific protocols in use, generating protocol-aware test cases that target the boundaries and edge cases where implementation vulnerabilities are most likely to be found.
ProtoCrawler is CyTAL’s automated protocol fuzz testing platform. It supports more than 100 protocols including Modbus, DNP3, IEC 61850, IEC 60870-5-104, GTP-C, GTP-U, DLMS COSEM, MQTT, SS7, and Diameter. It generates protocol-aware test cases systematically from formal protocol models, captures findings with the precision that useful security output requires, and produces structured reports that map directly to IEC 62443 compliance requirements. For the full list of supported protocols, see the protocol models page.
Common Questions About ICS Security
What is the difference between ICS security and OT security?
The terms are often used interchangeably, and the distinction is not always meaningful in practice. Operational technology security is the broader category, covering all technology used to monitor or control physical processes. Industrial control system security is a subset of OT security that focuses specifically on the control systems used in industrial environments: PLCs, DCS, SCADA systems, and the protocols and networks that connect them. In most industrial contexts the two terms refer to overlapping and closely related concerns, and the techniques used to address them are largely the same.
Can ICS security assessments be conducted without disrupting operations?
Yes, with the right methodology. Passive network monitoring and protocol traffic analysis can be conducted without generating any traffic on the OT network. Configuration reviews and documentation assessments do not require active interaction with operational systems. Protocol security testing should be conducted on representative test instances rather than production systems where possible, and where testing on production systems is required, the methodology needs to be designed specifically to avoid operational disruption. CyTAL’s approach to ICS security assessment is designed around the operational constraints of the environments we work in.
What protocols does ICS security testing need to cover?
It depends on the specific products and systems being assessed. Common industrial protocols that require security testing include Modbus, DNP3, IEC 61850, IEC 60870-5-104, and DLMS COSEM for energy and utilities applications. MQTT and similar protocols for IoT and connected device applications. SS7, Diameter, GTP-C, and GTP-U for telecoms infrastructure. The full list of protocols supported by ProtoCrawler is available on the protocol models page
How does ICS security relate to functional safety?
Functional safety and ICS security address related but distinct risks. Functional safety focuses on ensuring that systems behave safely in the face of hardware faults, software errors, and operational failures. ICS security focuses on protecting systems from deliberate attack. The two disciplines interact because a successful cyber attack on an industrial control system may cause it to behave in ways that functional safety systems are designed to prevent. Triton malware, which targeted safety instrumented systems specifically, demonstrated that attackers understand this interaction and may target safety systems as part of an industrial attack. Organisations responsible for systems with functional safety requirements need to assess cyber security risk to those systems alongside their functional safety programme.
What does IEC 62443 require for ICS security testing?
IEC 62443-4-1 Practice 6 requires security verification and validation activities throughout the product development lifecycle, including vulnerability testing that covers all external interfaces using methodology appropriate for those interfaces. SVV-3 specifically requires robustness and negative testing techniques that systematically test system behaviour under invalid and unexpected inputs. IEC 62443-4-2 defines component-level requirements, including input validation (CR 3.5) and denial-of-service protection (CR 7.1) that can only be verified through technical testing. The evidence produced by this testing needs to include documented methodology, specific test cases, findings, and traceability to the requirements being verified. For a detailed explanation of how these requirements apply to protocol security testing, see the IEC 62443 page