BLOG

Functional Safety and Cybersecurity: Why IEC 61511 and IEC 62443 Must Be Designed Together

For most of their history, functional safety and cybersecurity have been treated as separate engineering disciplines with separate standards, separate teams, and separate deliverables. IEC 61511 governs the design of safety instrumented systems: how safety functions are specified, how SIL levels are determined, how SIS hardware is validated, and how the safety lifecycle is managed. IEC 62443 governs the cybersecurity of industrial automation and control systems: how networks are segmented, how access is controlled, how vulnerabilities are managed, and how security levels are assigned to zones.

Treating them separately creates a gap. IEC 61511 designs a safety function that protects against a process hazard initiating from a physical cause: equipment failure, process upset, human error. If a cyberattack can modify the SIS logic, bypass a safety function, or prevent a safety function from executing when the hazard condition occurs, the SIL calculation that justified the safety design is no longer valid. The functional safety design assumed the safety function would work. A cyber compromise can make that assumption false.

TRITON demonstrated this gap in 2017. The attackers did not target the process control system to cause an upset. They targeted the safety system specifically, to prevent it from responding when they eventually caused an upset. The functional safety design of the facility was irrelevant if the SIS could be disabled by a cyberattack. This is what IEC 62443 and IEC 61511 together are designed to prevent, but only if they are applied jointly rather than in separate workstreams.

What IEC 61511 Covers, and What It Misses on Cybersecurity

IEC 61511 is the international standard for the functional safety of safety instrumented systems in the process industry. It defines the safety lifecycle from initial concept through decommissioning, covering hazard and risk analysis, safety requirements specification, SIS design and engineering, factory acceptance testing, installation and commissioning, operation and maintenance, and decommissioning.

IEC 61511 Clause 8.2.4 explicitly addresses cybersecurity: it requires that a security risk assessment be carried out to identify security vulnerabilities that could compromise the safety function. This clause establishes that cybersecurity is a functional safety obligation, not a separate IT responsibility. But IEC 61511 does not specify how to conduct that security risk assessment or what controls to implement. For that technical detail, it refers to IEC 62443.

What IEC 62443 Covers for Safety Systems

IEC 62443 provides the technical implementation framework that IEC 61511 Clause 8.2.4 requires but does not specify. Applied to safety instrumented systems, IEC 62443 addresses:

Zone and conduit design for SIS networks: the SIS should be in a dedicated security zone, separated from the BPCS by a controlled conduit that prevents unauthorized commands from the process control layer from reaching safety controllers
Security Level assignment: IEC 62443-3-3 Security Level 2 is typically the minimum for SIS zones; SL 3 is appropriate for high-consequence chemical and petrochemical environments
Access control for SIS programming: the engineering workstation that can program the SIS should be dedicated to that purpose, on an isolated network, with all access logged and session-recorded
Integrity requirements: IEC 62443-3-3 SR 3.1 requires communication integrity for the SIS zone, preventing unauthorized commands from being injected through the conduit

Why Treating Them Separately Creates Dangerous Gaps

The SIS Isolation Assumption

The standard IEC 61511 assumption is that the SIS is physically and logically isolated from all other systems. In practice, this assumption is violated in most installations. Engineering workstations that program the BPCS are frequently the same workstations used to program the SIS, creating a direct pathway from the process control network to the safety system. Historian connections that read SIS data for monitoring purposes create bidirectional pathways that, if not controlled, can carry commands as well as data.

A SIL 2 or SIL 3 certified safety function provides the specified risk reduction only if the safety system executes that function correctly when required. If a compromised engineering workstation can modify the SIS logic, the SIL certification of the hardware is irrelevant: the function it executes may no longer be the function it was designed and certified to perform. Control system integrity controls for the SIS programming interface are the mechanism that preserves the validity of the SIL design basis.

The SIS/BPCS Interface: The Most Dangerous Attack Point

In most chemical and petrochemical facilities, there is a defined interface between the safety system and the basic process control system. The BPCS sends permissive signals to the SIS and receives status data from it. The SIS sends final element commands and shutdown signals to the BPCS. This interface is designed for operational communication, not for security. In many installations, it is implemented as an uncontrolled Modbus or DCS-specific communication that crosses from the BPCS zone into the SIS zone without a formal conduit control.

This interface is the highest-risk point in the combined functional safety and cybersecurity architecture. An attacker who can reach the BPCS and who understands the SIS interface protocol can potentially send commands to safety controllers through the interface, bypassing the SIS isolation entirely. Zone and conduit design under IEC 62443 that explicitly addresses this interface, treating it as a controlled conduit with defined allowed communications, is the technical control that closes this gap.

Cybersecurity-Induced Safety Failures

The most direct consequence of failing to integrate IEC 61511 and IEC 62443 is a cybersecurity-induced safety failure: a process hazard condition occurs, the SIS is supposed to respond, and it cannot because a cyberattack has modified its logic, disabled its communication with final elements, or put it into a fail-safe state that prevents the safety function from executing. This failure mode does not appear in a PHA that considers only physical hazard initiators.

How IEC 61511 and IEC 62443 Align, and Where They Diverge

Lifecycle Phase	IEC 61511 Requirement	IEC 62443 Equivalent or Complement
Hazard and risk analysis	Identify process hazards and determine required risk reduction (SIL)	Cyber HAZOP: identify cybersecurity threats as hazard initiators alongside physical causes
Safety requirements specification	Define safety function requirements and SIL targets	Security requirements specification for SIS zone: access controls, integrity requirements, zone architecture
SIS design and engineering	Design SIS hardware and software to meet SIL requirements	Apply zone and conduit architecture to SIS network; select components meeting IEC 62443-4-2 requirements
Factory acceptance testing	Verify SIS performs safety function correctly	Verify cybersecurity controls are implemented correctly; include security testing in FAT scope
Commissioning	Verify SIS is correctly installed and safety function is operational	Verify security architecture is correctly implemented; validate access controls and zone integrity
Operation and maintenance	Maintain SIS integrity and manage change	Manage cybersecurity controls for SIS through change management; monitor SIS zone continuously
Decommissioning	Remove SIS safely from service	Remove SIS credentials, access rights, and network connections; document decommissioning for security records

The Practical Integration Approach

Cyber HAZOP: Incorporating Cybersecurity into Hazard Studies

A cyber HAZOP extends the standard HAZOP methodology to include cybersecurity as a category of hazard initiator. For each safety-critical control loop and each safety function, the cyber HAZOP asks: what happens if the signal to this controller is falsified? What happens if the safety function is prevented from executing by unauthorized modification of the SIS logic? What happens if the BPCS/SIS interface carries an unauthorized command?

The cyber HAZOP output identifies which cybersecurity failure scenarios have the potential to result in the same consequence as the physical hazard scenarios already in the PHA. This is the mechanism by which OT cybersecurity for chemical plants and the functional safety program become a single integrated risk picture rather than two separate analyses.

Security Requirements Specification for SIS

The security requirements specification (SRS) for the SIS, developed in parallel with the safety requirements specification required by IEC 61511, defines the cybersecurity controls that must be in place to protect the safety function from cyber interference. It specifies the zone architecture for the SIS network, the allowed communications in the SIS/BPCS conduit, the access controls for SIS programming, and the monitoring requirements for the SIS zone. This document is the bridge between the IEC 61511 lifecycle and the IEC 62443 security architecture.

Procurement Requirements for SIS Components

IEC 62443-4-2 defines component-level security requirements for automation products including SIS controllers. When procuring new SIS hardware, specifying IEC 62443-4-2 compliance requirements means that the manufacturer has implemented security in the product design: authentication, audit logging, firmware integrity verification, and secure update mechanisms. Combining IEC 61511 SIL certification with IEC 62443-4-2 component security certification is the most complete assurance that a safety controller provides both the safety function and the cybersecurity protection needed to operate in a process environment with external connectivity.

Frequently Asked Questions

Does IEC 61511 require us to conduct an OT security assessment?

Yes. IEC 61511 Clause 8.2.4 requires that a security risk assessment be carried out to identify the security vulnerabilities of the safety instrumented system that could be exploited to compromise the safety function. This is a mandatory requirement of the IEC 61511 lifecycle, not an optional best practice. The standard does not specify the methodology for that assessment, but IEC 62443-3-2 security risk assessment provides the appropriate methodology. An IEC 61511 lifecycle that does not include a security risk assessment is not fully compliant with the standard.

Who should lead the integrated IEC 61511 and IEC 62443 program — the safety team or the OT security team?

The program should be led jointly, with functional safety engineers leading the IEC 61511 lifecycle activities and OT security practitioners providing the IEC 62443 technical controls and security risk assessment. The critical integration point is the cyber HAZOP, which requires both disciplines at the table simultaneously. Organizations that separate the two programs and try to integrate them at the documentation level, rather than at the analysis level, consistently miss the architectural gaps that create the most significant risks.

Our SIS passed its IEC 61511 SIL certification. Are we done?

A SIL certification confirms that the SIS hardware and software meet the specified safety integrity requirements under the assumed operating conditions of the certification. It does not certify the cybersecurity of the environment in which the SIS operates. If the SIS programming interface is accessible from the process control network without authentication, the SIL certification is valid for the hardware but the operating assumption, that the SIS is isolated and cannot be tampered with, is not met. IEC 62443 controls are what maintain the validity of that assumption in a connected facility. See the OT cybersecurity for chemical plants guide for the specific architecture that protects the SIL certification basis.

How does this integration affect our HAZOP studies going forward?

The practical change is that your HAZOP team needs to include cybersecurity threat scenarios as hazard initiators alongside the physical and procedural initiators already in scope. For each control loop or safety function, the team asks: can a cybersecurity failure cause this deviation? If yes, what are the consequence and the safeguard? The safeguards against cyber-initiated deviations are the IEC 62443 controls: zone isolation, access control, integrity monitoring. This does not require a separate cyber HAZOP workstream; it extends the existing HAZOP methodology with an additional initiator category.

Ready to assess your OT security posture?

We help industrial operators build practical OT security programs that account for operational and process safety constraints. Book a free consultation.

Book Your Free Consultation at aristacyber.io