Safety Instrumented Systems (SIS) Security: Protecting the Last Line of Defense

01Key takeaways

1. 01

   A safety instrumented system (SIS) brings a process to a safe state when a dangerous condition occurs.

2. 02

   It is the last line of defense, so its integrity and availability are safety-critical, not just operational.

3. 03

   The Triton/TRISIS attack specifically targeted a safety system, proving the threat is real.

4. 04

   An SIS should be isolated from the basic process control system and from broader networks.

5. 05

   Safety state can be monitored one way, and SIS changes must be under strict, controlled access.

02What an SIS is and why it is special

A safety instrumented system is an independent system of sensors, logic solvers and final elements that monitors a process for dangerous conditions and acts to make it safe, for example by shutting down equipment or relieving pressure. Each protective function it performs is a safety instrumented function, designed to a defined level of reliability.

What makes the SIS special is that it is the defense of last resort. The basic process control system runs the process; the SIS exists to catch the situations where running the process has gone wrong. Its job is to work precisely when everything else has failed.

The SIS is not there to run the plant. It is there to prevent a catastrophe when the plant runs out of control.

03The Triton wake-up call

For years, safety systems were considered too obscure and isolated to be a cyber target. The Triton malware, also called TRISIS, ended that assumption. It was designed to manipulate a safety instrumented system directly, an attack aimed squarely at the last line of defense.

The significance was profound. Targeting an SIS implies a willingness to cause physical harm, not just disruption, and it proved that capable adversaries will reach for safety systems specifically. After Triton, the isolation and security of the SIS could no longer be treated as optional or assumed.

04Why SIS must be isolated from the BPCS

A core safety principle is independence: the safety system should be separate from the basic process control system, so that a failure or compromise of the control system cannot also defeat the safety function. This independence is a security property as much as a safety one.

• If the SIS shares networks and systems with process control, a compromise of one threatens the other.
• Integration for convenience, such as shared engineering tools, can create a path to the safety system.
• The more reachable the SIS, the more an attacker who gets into the control environment can attempt against it.
• Independence preserves the assumption that the SIS will still act even if the control system is compromised.

Keeping the SIS strongly separated, ideally with no routine network path from less-trusted systems, protects the one function you most need to remain trustworthy.

05One-way monitoring of safety state

Operators and engineers legitimately need to see the state of the safety system: its status, its diagnostics, whether it has acted. But observing the SIS should never come at the cost of a path into it.

Monitoring data can leave the SIS one way, so its state is visible without anything being able to reach back to change it. An AIRGAPNET controlled connectivity pattern supports this principle: let safety status flow outward for visibility, while ensuring the safety system itself has no standing inbound path that an attacker could use, preserving the independence the SIS depends on.

06Strict change control

Changes to a safety system, to its logic, its settings, its configuration, are inherently high-consequence. They must be tightly controlled, both for safety assurance and for security, since the ability to change the SIS is exactly what an attacker like Triton sought.

• Allow SIS changes only through controlled, approved, and audited procedures.
• Keep the engineering path to the SIS disconnected by default, opened only for sanctioned work.
• Separate SIS engineering tools and credentials from those of the control system.
• Maintain rigorous records of every change to the safety function.

07The IEC 61511 context

Functional safety standards such as IEC 61511 govern the design and management of safety instrumented systems, and they increasingly recognize cybersecurity as part of safety. A security compromise of an SIS is a safety problem, because it can defeat the protective function the standard exists to ensure.

This convergence of safety and security is the modern reality for SIS. Protecting the safety system is not separate from functional safety; it is part of ensuring the safety function will perform when called upon, which is the entire point of the system.

08Closing thought

The safety instrumented system is the system you hope never has to act and absolutely need to work when it does. Triton proved that this last line of defense is a target, and that its security is inseparable from its safety purpose.

Keep the SIS independent and isolated, let its state be seen without being reachable, and control every change with rigor. Of all the systems in a plant, the one that prevents catastrophe is the one whose isolation is least negotiable.

FAQFrequently asked questions

SRCSources of record