A new post published on ISASecure highlighted need for industrial asset owners to integrate functional safety and operational technology (OT) cybersecurity into a single lifecycle, arguing that the two disciplines address interconnected risks within the same industrial control systems. Rafael Barreto Jijón, managing director of OT-Knight, said safety instrumented systems (SIS) serve as a critical layer of protection against process hazards while also presenting targets for cyber-physical attacks. Drawing on the 2017 TRITON/TRISIS malware incident, he argued that attacks targeting safety systems can constitute both cybersecurity and safety incidents, requiring coordinated risk assessments, governance, engineering and operational responses.
He recommends aligning the ISA/IEC 61511 functional safety lifecycle with the ISA/IEC 62443 cybersecurity framework through joint risk assessments, reconciled safety and cybersecurity requirements, coordinated maintenance and change management, and integrated incident response procedures. He also called for shared assessment schedules and continuous evidence collection to verify that safety and cybersecurity requirements are met without compromising either discipline.
Barreto Jijón said existing ISA/IEC standards already establish requirements for addressing cybersecurity risks to safety systems, including vulnerability assessments, security resilience, access controls and separation of safety-related assets from non-safety networks.
In this context, he wrote in a post last week, “So stop running two parallel programs, and start operationalizing one lifecycle.”
He outlined that the mandate already runs both ways and that the standards already require it.
ISA/IEC 61511-1:2016 requires a security risk assessment to identify the security vulnerabilities of the SIS, and an SIS design that provides the necessary resilience against the identified security risks. It also requires access security for bypasses, the maintenance/engineering interface and I/O forcing and, where the SRS calls for it, documentation of how communications are made secure.
ISA/IEC 62443-2-1:2024 requires the asset owner to have policies and procedures to protect the safety system from interference by non-safety networks and their devices. It also requires the asset owner to operate the IACS as designed when disconnected from external networks, for example through fail-safe operation or safe shutdown, and change safety-system configuration only when configuration mode is enabled.
“ISA/IEC 62443-2-1 is explicit: where the asset owner has an ISMS, the IACS security program shall be coordinated with it (ORG 1.1). Most process operators also run functional safety management under ISA/IEC 61511-1 Clause 5. Three management systems, one governance logic,” Barreto Jijón detailed. “Run them on one spine: one governance policy, one Statement of Applicability that demarcates IT, OT and safety, including the IT/OT secure interface, and one combined internal audit and management review.”
He added, “And use one competence framework. You can’t secure an SIS if your security team doesn’t know what an SIF is — and a safety engineer who has never worked with zones and conduits will not see cyber as a common cause.”
Barreto Jijón identified that ISA/IEC 62443-3-2:2020 requires safety-related assets to be grouped into zones separated from non-safety assets, or the whole zone to be treated as safety-related. It requires each threat scenario’s consequences to be evaluated and documented, including the worst-case impact on personnel safety. It also requires the management accountable for the safety, integrity and process reliability to review and approve the risk-assessment results.
ISA/IEC 62443-3-3:2013 requires, at SL 3 and 4, the capability for zone boundaries to fail closed when boundary protection fails, designed not to interfere with the operation of an SIS or other safety-related functions.
He added that the workshops should be cross-staffed, with a functional safety engineer in the cyber risk assessment and a cyber-informed engineer in the HAZOP/LOPA. Teams should also share the consequences by adding cyber causes to HAZOP nodes and using HAZOP severity to rank cyber risk. Because HAZOP considers one cause–consequence pair at a time, they should also look for the multi-cause scenarios it missed. Two standing questions should be asked of every scenario: whether cyber could initiate or worsen it, and whether a non-digital safeguard exists that designs the risk out.
He said that classical LOPA credits a protection layer only if it is independent of the others. “A cyberattack breaks that assumption where the BPCS and the SIS share a network without segregation, a common-cause path ISA/IEC 61511-1 itself flags: one compromise can defeat two layers credited as independent, and even create the demand while disabling the SIF that should respond. As ISA‑TR84.00.09 notes, cyberattacks are not random and can cause hazards ‘in an orchestrated sequence that can result in consequences not recognized if not considered in the analysis.’”
Barreto Jijón wrote that TR84.00.09 sets the order. An initial SRS is produced after the hazard and risk analysis and the allocation to protection layers, and it is already informed by the initial cyber risk assessment. The detailed cyber risk assessment is then recorded in the CRS, and any contradictions are reconciled afterward.
The rule is that a cyber requirement must not undermine a safety requirement, and a safety requirement must not undermine a cyber requirement. If the CRS demands timely patches on the SIS platform and the SRS forbids unvalidated changes, neither requirement wins by default. Instead, the patch should be tested for compatibility and approved (ISA/IEC 62443-2-1 COMP 3.2), installed through MOC, and the affected SIFs should be re-verified before service return (ISA/IEC 61511-1 Clause 17). The CRS may be a separate document or part of the SRS, and its format is flexible. However, reconciliation is not optional.
On the operational side, Barreto Jijón said maintenance should run under one regime in the plant CMMS rather than an IT ticket queue. Patches, firewall rules and configuration changes should go through a single MOC register, using the plant MOC process that ISA/IEC 61511-1 already requires for the SIS. No intrusive cyber work should take place on a live system without a plant-floor work permit, giving organizations one permit gate, and they should also maintain one emergency playbook.
“In OT and critical infrastructure, cybersecurity becomes a safety function — when it preserves the ability of the process to remain in, or return to, a safe state. Safety engineers know how to protect that ability; security engineers know how an adversary will try to take it away. Neither can protect the plant alone,” Barreto Jijón concluded. “The asset owners who get this right will not be the ones with the thickest binders. They will be the ones whose two teams work from one lifecycle.”
