Safety Instrumented Systems Security Guide: Protecting the Last Line of Defence

A safety instrumented system is designed to bring a process to a safe state when everything else has failed, so a cyber attack that disables or manipulates it removes the last automated barrier between an upset and a major accident. TRITON (also called TRISIS or HatMan) showed in 2017 that attackers will target safety controllers directly. This guide explains how SIS security differs from general OT security, what IEC 61511 and ISA-TR84.00.09 require, how to separate the SIS from the basic process control system (BPCS), and how to control the engineering workstations, key switches and maintenance overrides that decide whether a safety controller can be changed. It is for process safety engineers, control system engineers and OT security teams in refining, chemicals, oil and gas, power and other process industries. The broader OT architecture is covered in the OT Security Guide; this guide stays inside the safety layer.

Key takeaways

• Security is now part of functional safety. IEC 61511-1 clause 8.2.4 requires a security risk assessment of the SIS, and clause 11.2.12 requires the SIS design to be resilient against the security risks identified; a SIS without a cyber assessment does not meet the standard.
• Separation is the primary control. Put the SIS in its own safety zone, never share an engineering workstation or network with the BPCS, and let data leave only through controlled, preferably one way, conduits.
• The key switch and the engineering workstation decide who can change safety logic. TRITON's payload could only be delivered with the controller in program mode; keep controllers in run, control the keys and lock down the workstations that can program them.
• An unexpected trip is a security signal. TRITON was found because controllers failed safe; investigate unexplained SIS faults and trips as potential cyber events, not only as instrument failures.
• Bypasses and overrides are the quiet risk. Maintenance overrides, forced points and bypass switches defeat safety functions by design; log, approve and time limit them as strictly as logic changes.

What a SIS is and why its security is different

A SIS implements one or more safety instrumented functions (SIFs), each made of sensors, a logic solver and final elements (valves, breakers, pump trips) that act when a process variable crosses a trip point. Each SIF is assigned a safety integrity level (SIL 1 to 4) from the hazard and risk analysis. The SIS is meant to be independent of the BPCS, which runs normal control, so that a failure in one layer does not disable the other.

Two failure modes matter. A loss of protection (ATT&CK for ICS T0837) leaves hazards uncontrolled and is invisible until a demand occurs. A loss of safety (T0880) is where the safety function itself is defeated or manipulated. Spurious trips (T0816 Device Restart/Shutdown) are costly and also erode trust in the SIS, which tempts operators to bypass it.

What IEC 61511 and ISA-TR84.00.09 require

• IEC 61511-1:2016 (edition 2.0, Amendment 1 2017): the process sector functional safety standard. Its cyber requirements are short. Clause 8.2.4 requires a security risk assessment to identify the vulnerabilities of the SIS, covering the devices in scope, threats from both deliberate attack and human error, the consequences and likelihood of security events, every lifecycle phase from design to decommissioning, any additional risk reduction needed and the measures taken. Clause 11.2.12 requires the SIS design to provide resilience against the identified security risks. The IEC webstore lists a stability date of 2029 for the current edition.
• ISA-TR84.00.09, Cybersecurity Related to the Safety Lifecycle: the ISA technical report that shows how to do the 8.2.4 assessment in practice. Editions date from 2013 and 2017; the current edition is a substantial rewrite that adds Purdue based network topology, access management, secure configuration, SOC alert responsibilities, incident management and zero trust concepts, and maps safety lifecycle phases to ISA/IEC 62443-3-2 (risk assessment), 62443-3-3 (system requirements) and 62443-4-2 (component requirements). A further part is reported to be under development.
• IEC 62443: supplies the zone and conduit model, target security levels and supplier requirements that the safety lifecycle refers to. See the IEC 62443 Guide.
• UK HSE OG86: HSE's inspection guidance for IACS at COMAH sites. It states that following the guidance may satisfy the BS EN 61511 clause 8.2.4 requirement, treats any system that could defeat a SIS as part of the safety scope, and expects SIS in a dedicated safety zone.

Mapping the safety lifecycle to security activities

Separating the SIS from the BPCS

SIS integration with the control system ranges from fully separate to fully integrated on a shared platform. Integration brings operational benefits (single operator view, shared engineering tools) and adds shared failure modes. The table summarises the trade-offs.

• Safety zone: place the SIS logic solvers, safety engineering workstation and safety network in their own IEC 62443 zone, lower in the architecture and less exposed than the BPCS, as HSE OG86 describes.
• Conduits: treat every communication path, including portable media, as a conduit with an owner and a rule set. Hardwired discrete I/O is not a network conduit but remains in scope for risk.
• Read only by design: where applications only need SIS data, use unidirectional gateways or firewalls that permit only read function codes, so no write path exists from the BPCS or historian.
• BPCS that can defeat the SIS: if a BPCS zone can disable or bypass a SIF (for example by writing bypass flags), treat that BPCS zone as safety critical too, or remove the capability with hardwired enables.
• No dual homing: no safety engineering workstation or server connects to both the safety network and another network.

Engineering workstations, key switches and change control

Most SIS logic changes are made from a vendor engineering tool on a Windows workstation, and many safety controllers have a physical key switch or software setting with run, program and remote modes. Together these decide who can change safety logic.

• Key switch discipline: keep controllers in run except during a scheduled, approved programming window. Store keys under control (named custodian, sign out log), audit key position on every shift or through controller diagnostics, and treat any change of mode outside a window as an incident (ATT&CK for ICS T0858 Change Operating Mode).
• Dedicated safety engineering workstation: one or a few workstations, used only for the SIS, in the safety zone, with application allowlisting, no email or web browsing, removable media blocked except through a scanning process, and local accounts removed or vaulted.
• Named access: engineering tool and controller access by named accounts with MFA where the platform supports it; no shared "engineer" password. Access granted per change, not standing.
• Logic integrity: keep an offline, approved copy of every SIS application program with its checksum or version identifier, compare the running program against it on a schedule and after any trip, and investigate any unexplained difference (ATT&CK for ICS T0843 Program Download, T0889 Modify Program).
• Management of change: every logic, setpoint or firmware change goes through IEC 61511 management of change with a security impact question, independent review and post change validation testing.
• Vendor and integrator access: on site supervision or brokered, recorded remote sessions approved per job; never permanent remote access into the safety zone. See the OT Remote Access Guide.

Bypasses, overrides and forced points

Maintenance bypasses and overrides exist so instruments can be tested without tripping the plant, but each one disables a safety function. A cyber attacker, or an operator under pressure, can use the same mechanisms (ATT&CK for ICS T0838 Modify Alarm Settings describes a related pattern).

• Approval and time limit: every bypass needs a permit, a named approver, compensating measures and an expiry, recorded in a bypass log.
• Visibility: show active bypasses on the operator display and in the shift handover; alarm on bypasses older than their permit.
• Hardware enables: where possible require a physical bypass enable switch as well as a software command, so a remote write alone cannot bypass a SIF.
• Reconcile: compare the bypass log with controller state daily; an active bypass without a permit is a safety and security incident.

Where identity fits

Safety systems hold few accounts, but they are the most privileged identities on site: the account that can download logic to a logic solver can remove protection from a unit. Inventory every human and non-human identity that can reach the safety zone (engineering tool accounts, vendor service accounts, OPC or historian service accounts, local administrator accounts on the workstation), give each an owner, remove defaults and shared logins, and review access at every management of change. See the OT and ICS Identity and Access Guide.

Detection and measurement

• What to log: controller mode and key switch changes, program downloads and uploads, logic checksum or version changes, diagnostic faults, trips and their causes, bypass activations, engineering workstation logins and USB events, and all traffic crossing the safety zone boundary.
• Correlate trips with activity: after any unexplained trip or controller fault, review engineering workstation and safety network activity for the preceding period. Mandiant's TRITON analysis recommends exactly this correlation.
• Passive monitoring: OT protocol aware monitoring on the safety network (span or tap, never inline on the SIS) to flag new talkers, write commands and vendor engineering protocol traffic outside approved windows.

Implementation: a phased approach

1. Inventory and baseline: list every SIS, logic solver, firmware version, engineering workstation, network connection and account. Capture program checksums and key switch positions.
2. Assess: run the clause 8.2.4 security risk assessment with process safety, control and security engineers together, using ISA-TR84.00.09 and IEC 62443-3-2. Assess each zone without crediting existing countermeasures, as HSE OG86 advises.
3. Quick wins: return controllers to run, put keys under custody, remove dual homed workstations, disable unused accounts and remote access into the safety zone.
4. Re-architect conduits: introduce the safety zone firewall or unidirectional gateway. Run new rules in alert only mode through a full operating cycle and a proof test, confirm with operations that no needed data flow is lost, then enforce. Keep the previous configuration saved so the change can be reversed within the change window.
5. Harden workstations: deploy allowlisting in audit mode first, review blocked items with the vendor, then enforce. Pilot on one workstation before others.
6. Embed in the lifecycle: add security questions to management of change, proof test procedures (check logic baseline and mode) and the bypass permit process, and include SIS scenarios in OT incident response exercises. See the OT Incident Response Guide.

Rollback and safety first: no security change may be applied to a SIS without the same validation as a safety change. If a security control interferes with a safety function, revert it immediately under management of change and redesign; never leave a SIF degraded to keep a security control in place.

Small versus large sites: a single plant with one SIS can rely on physical separation, hardwired status, key custody and a manual logic comparison. A multi site operator should standardise the safety zone design, centralise baselines and monitoring, and run assessments to one method across sites.

Framework mapping

Common failure patterns

• Controllers left in program mode: convenient for engineers, and the condition TRITON needed. Treat any non run state outside a window as an incident.
• Shared engineering workstation: one Windows host programs both BPCS and SIS, or is dual homed to the plant network, creating a common cause failure across protection layers.
• "Air gapped" on paper only: a historian link, OPC connection or vendor modem added years ago is not in the drawings. Verify with traffic capture, not documentation.
• 8.2.4 assessment done once: the assessment is filed at project close and never revisited after modifications, new conduits or vendor remote access changes.
• Trips closed as instrument faults: unexplained trips and diagnostic failures are reset without checking logic integrity or engineering activity.
• Uncontrolled bypasses: long standing bypasses without permits leave SIFs disabled, and nobody can tell a malicious bypass from a forgotten one.

Lessons from incidents

In 2017 attackers reached the safety engineering workstation at a refinery and deployed TRITON against Schneider Electric Triconex safety controllers, communicating over the TriStation protocol. According to the US Department of Justice, the malware caused faults that led the refinery's safety systems to start two automatic emergency shutdowns, and in March 2022 the department unsealed charges against an employee of a Russian Ministry of Defence affiliated research institute (TsNIIKhM). Schneider Electric found no vulnerability in its product had been exploited, and noted the payload could only be delivered with the controller in program mode. The defensive lessons are the controls in this guide: keep controllers in run and control the keys, never dual home a safety engineering workstation, separate safety networks from control and business networks, use one way data paths, allowlist applications on anything that can reach the SIS, and treat an unexplained safe shutdown as a possible attack. No NHI Mgmt Group breach page covers TRITON at the time of writing.

Practitioner checklist

• Complete and maintain an IEC 61511-1 clause 8.2.4 security risk assessment for every SIS.
• Place each SIS in a dedicated safety zone with documented conduits and no BPCS write path.
• Use a dedicated, allowlisted safety engineering workstation that is never dual homed.
• Keep controllers in run mode; put keys under custody and audit mode on every shift.
• Baseline every SIS program and compare after changes, proof tests and unexplained trips.
• Add a security impact question to SIS management of change.
• Run bypasses under permits with expiry, visibility and daily reconciliation.
• Remove permanent vendor remote access into the safety zone.
• Monitor the safety network passively and correlate trips with engineering activity.
• Include SIS compromise scenarios in OT incident response exercises.

Standards and references

• IEC: IEC 61511-1:2016 Functional safety, Safety instrumented systems for the process industry sector, Part 1
• ISA: ISA/IEC 62443 Series of Standards
• UK HSE: OG86 Cyber Security for Industrial Automation and Control Systems
• NIST: SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security
• Mandiant: Attackers Deploy New ICS Attack Framework TRITON
• US Department of Justice: Four Russian Government Employees Charged in Two Historical Hacking Campaigns Targeting Critical Infrastructure
• Optiv: ISA TR84 and How It Relates to OT Security
• MITRE ATT&CK: Loss of Safety

Related NHI Mgmt Group resources: OT Security Guide · IEC 62443 Guide · OT and ICS Identity and Access Guide · Top 10 OT Security Risks · Oil and Gas Cybersecurity Guide