Why does a Safety Instrumented System (SIS) matter for security teams?

What a SIS is protecting in an OT environment

A Safety Instrumented System is not just another control asset. It sits on the path that should detect hazardous conditions and force equipment into a predefined safe state when normal control logic or operator action is no longer enough. For security teams, that makes the SIS part of the trust boundary around process safety, not a back-office engineering detail.

That distinction matters because compromise here changes the consequence profile of an incident. If the safety layer is unavailable, altered, or bypassed, ordinary operational faults can become safety events, and malicious activity can do more than disrupt production. It can remove the last automated barrier between a fault and physical harm.

In OT architectures, the SIS often has distinct engineering, monitoring, and maintenance paths from the basic process control system, and that separation is intentional. Security teams should treat any connectivity, remote access, or shared tooling that weakens that separation as a design decision with safety implications, not merely a convenience issue. The OT security model should reflect that the SIS is there to preserve safe operation when something else has already gone wrong. OT Security Guide

Why attackers and faults care about SIS integrity

The SIS matters because it is a high-value target for both accidental failure and deliberate interference. A fault, bad change, or malicious command that suppresses trip logic, delays a shutdown, corrupts inputs, or breaks sensor-to-controller trust can leave dangerous conditions undetected long enough for equipment damage or safety impact to occur.

Security teams should think in terms of consequence, not just confidentiality. The main exposure is integrity and availability of the safety function itself, especially where engineering workstations, firmware, remote maintenance channels, or shared credentials can reach the safety layer. Even when the production network remains available, a weakened SIS can convert a controlled shutdown into an uncontrolled event. NIST Cybersecurity Framework 2.0 helps frame that broader operational risk by linking governance, protection, detection, response, and recovery to systems that support critical outcomes.

That is also why change control is so important. Safety systems often fail under the same pattern seen in other high-consequence environments: legitimate maintenance, poorly governed exceptions, or undocumented configuration drift that creates an opening for misuse. The security question is not only whether the SIS is reachable, but whether any actor can alter its behavior without strong oversight, traceability, and separation of duties.

How security teams should protect the safety layer

Security work around an SIS should start with preserving its independence. The most important controls are tight change approval, restricted administrative paths, hard segmentation between safety and non-safety networks, and disciplined management of engineering access. If the same identities, laptops, or remote channels touch both control and safety paths, the organisation should assume the blast radius is larger than documented.

Verification should focus on what can actually change the safety outcome: controller logic, setpoints, logic solvers, safety sensors, firmware, engineering toolchains, and safety-related alarms or bypasses. Security teams do not need to own the safety engineering function, but they do need evidence that those elements are inventoried, monitored, and protected from untracked modification. For control implementation guidance, NIST SP 800-53 Rev 5 Security and Privacy Controls is useful for mapping access control, system integrity, audit, and configuration management expectations to the environment.

Where remote support or vendor access exists, the practitioner question is whether that access is time-bounded, visible, and revocable. Safety systems should not depend on standing trust or loosely governed shared accounts. If a security team cannot explain who can modify SIS components, how that access is approved, and how a bad change would be detected, the control is not mature enough for a high-consequence plant.

Practitioner Guidance

What to prioritise: Protect the SIS by treating any path that can modify safety logic, firmware, or engineering configuration as a high-risk maintenance pathway. That means reviewing who can reach it, how changes are authorised, and whether safety and non-safety administrative paths are truly separated.

What to verify: Confirm that the organisation can produce current SIS asset inventory, change records, privileged access assignments, and evidence of test or validation after modifications. If those records are weak or inconsistent, assume the safety function is less observable than the plant believes.

Common mistake: Assuming the SIS is secure because it is “special” or rarely touched. Rare change does not equal low risk, it often means weak familiarity, sparse testing, and higher odds that a single unauthorised or mistaken change will go unnoticed.

Practitioner takeaway: The real security objective is not to harden the SIS in isolation, it is to prevent unreviewed changes, unauthorised access, and trust erosion from undermining the system that exists to keep the plant safe when other controls fail.

Related resources from NHI Mgmt Group

• How should healthcare security teams prioritise application risks when patient safety depends on the system?
• Why does System Integrity Protection (SIP) matter for security teams?
• Why does a Host-Based Intrusion Prevention System (HIPS) matter for security teams?
• Why does the Kids Online Safety Act matter for security teams?