Functional safety matters because safety functions such as shutdowns, interlocks, and emergency stops may be relied on when cyber incidents affect equipment or process behaviour. Security teams need to protect those functions from unauthorised change, denial, or bypass, and understand how cyber faults could prevent a safe state.
Why functional safety changes the security team’s job
Functional safety matters because the security outcome is not just “protect the system,” but “preserve a safe state when the system is disturbed.” In industrial environments, cyber incidents can interfere with shutdowns, interlocks, emergency stops, and other safety functions, so a security failure can become a physical safety failure. That shifts the security team’s focus from confidentiality alone to safe operation under fault conditions.
The practical implication is that security controls must protect the logic and pathways that safety depends on. If an attacker, or even a misconfiguration, can change, delay, or bypass a safety action, the organisation may lose the ability to contain process upset. That is why safety functions deserve explicit protection, review, and monitoring rather than being treated as purely engineering concerns.
Where cyber risk crosses into unsafe operation
Cyber and safety controls often interact through shared equipment, shared networks, or shared engineering workstations. A security issue that alters controller logic, suppresses alarms, or disrupts communications can prevent a safe response at the exact moment it is needed. In OT environments, that means the security team has to think about control integrity, availability, and fail-safe behaviour together.
Security teams should pay close attention to paths that can deny or degrade safety action, such as unauthorized configuration changes, command injection into control interfaces, or denial of view conditions that hide an unsafe process state. OT Security Guide is a useful reference point for the wider industrial control context, including segmentation, industrial protocols, and safety and security convergence.
Functional safety also changes the meaning of resilience. A control system can appear “up” while the safety layer has been weakened, misconfigured, or made unreachable. From a security perspective, that is a latent condition, not a clean recovery.
What security teams need to protect in safety functions
The most important assets are not only the controllers and servers, but the trust relationships around them: engineering access, configuration tools, safety logic, alarms, interlocks, and emergency shutdown paths. If those are exposed to broad admin access, shared credentials, or weak change control, the organisation creates an easy route from cyber compromise to unsafe process behaviour.
For security teams, the right question is whether a cyber event could block the plant from moving to a safe state. That includes direct sabotage, accidental change, stale logic, or a restore process that overwrites valid safety settings with older, unsafe ones. It also includes the human factor, where operational staff may rely on safety functions without knowing those functions were altered outside the normal maintenance cycle.
Safety dependence should be reflected in asset inventory, access review, segmentation, backup strategy, and restoration testing. A safety function that cannot be independently verified after change is a control assumption, not a control.
Risk and Threat Considerations
Functional safety introduces a high-consequence failure mode because an attacker, operator error, or corrupted configuration can remove the system’s ability to fail safely. The risk is not limited to downtime, it includes loss of containment, equipment damage, and harm to people when protective actions do not occur as designed.
Failure mechanism: Cyber interference can modify safety logic, block alarm delivery, disrupt interlocks, or delay emergency shutdown commands, leaving the process in an unsafe operating state.
Impact: The organisation may not be able to reach or verify a safe state during an incident, which increases the chance of physical harm, uncontrolled process behaviour, and longer recovery.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-7 — Boundary Protection | Segmentation limits paths that could disrupt safety-related systems. |
| CM-3 — Configuration Change Control | Safety logic and control changes need controlled approval and traceability. | |
| IA-2 — Identification and Authentication (Organizational Users) | Privileged engineering access can alter safety-relevant controls. | |
| Recommendation — Isolate safety-relevant assets and restrict control-path exposure. Require formal approval and review for safety-impacting changes. Enforce strong authentication for engineers who can change safety functions. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Secure baselines reduce misconfiguration that can weaken safety behaviour. |
| CIS-5 — Account Management | Access governance matters where accounts can modify safety controls. | |
| Recommendation — Harden control systems and preserve approved safety configurations. Restrict and review accounts that can change safety-related systems. | ||
| NIST CSF 2.0 | PR.AA-05 — Least Privilege Access Granted and Managed | Least privilege reduces the chance of unauthorized safety override. |
| Recommendation — Limit who can alter, bypass, or disable safety functions. | ||
Practitioner Guidance
What to prioritise: Identify the specific functions that move the plant to a safe state, then classify the access paths, engineering tools, and change workflows that could affect them. Those elements deserve tighter review than ordinary operational controls because they carry safety consequence, not just operational inconvenience.
What to verify: Confirm that safety-relevant logic, setpoints, and override paths are independently protected, and that restore procedures do not reintroduce unsafe configurations. Security teams should also verify that monitoring can still see safety-relevant events when the normal control network degrades.
Decision rule: If a cyber event can prevent shutdown, interlock, or emergency action, treat it as a safety-impacting security issue and escalate before normal incident triage is complete. If the event only affects reporting or non-critical telemetry, the response can usually stay within standard security operations.
Practitioner takeaway: The key judgement is that functional safety is a security dependency with physical consequences, so the team must defend the safe-state path as aggressively as any privileged access path.