Where Functional Safety Meets OT Cybersecurity

How Do Functional Safety and OT Cybersecurity Intersect?

Functional safety addresses the risk created by hazardous failures and seeks confidence that defined safety functions will perform when required. OT cybersecurity addresses intentional and unintentional threats to confidentiality, integrity and — critically for TVCS — availability. SIL and IEC 62443 Security Levels are not interchangeable; they arise from different risk assessments and measure different capabilities.

They intersect wherever a cyber event can become a cause of a safety-relevant failure. Examples include unauthorised logic changes, denial of service, manipulated fire-location data, loss of operator visibility, corrupted time synchronisation, blocked remote diagnostics or an engineering workstation that introduces malware. These conditions should be considered explicitly in both the hazard review and the cybersecurity risk assessment.

How Should a TVCS Be Segmented into Zones and Conduits?

IEC 62443-3-2 provides a useful system-design method: define the system under consideration, partition it into zones and conduits, assess risk and establish target security levels. For TVCS, practical zones may include safety control, supervisory SCADA, engineering and maintenance, field-device networks, station interfaces, and external services such as enterprise support or a Security Operations Centre.

• Preserve Local Safety Action: Emergency sequences should not depend on enterprise identity, internet services or a remote data platform. Loss of an external service may remove visibility, but it should not remove the locally validated safety function.
• Control Every Conduit: Permit only required sources, destinations, protocols, and directions. Use firewalls or industrial security appliances at trust boundaries, and design monitoring so that a Security Operations Centre (SOC) connection does not become an inbound control path.
• Remove Hidden Common Dependencies: Redundant controllers and networks can still fail together through shared switches, credentials, time sources, engineering tools or configuration repositories. Architecture reviews should test independence against cyber as well as hardware faults.

What Does a Hardened TVCS PLC and SCADA Baseline Require?

Start with a hardened, documented baseline. Disable unused ports and services; restrict programming paths; apply least privilege; protect safety signatures and configuration files; separate operator, maintenance and engineering roles; and retain recoverable offline backups of PLC, HMI, network and security-device configurations.

Remote access should use an approved jump path with strong authentication, time-bound authorisation and session logging. It should never create a direct route from enterprise or vendor networks to a safety controller. At the same time, authentication failure must not prevent authorised local emergency operation; a controlled local or break-glass method should be defined, tested and audited.

Availability engineering matters at protocol level. Apply access-control lists, rate limits and network storm controls without introducing excessive latency. Use supported firmware and components but treat patches as controlled engineering changes. Assess safety impact, test in a representative environment, plan rollback, and revalidate affected functions before return to service.

How Do You Align IEC 61508 and IEC 62443 Across a TVCS Lifecycle?

The most effective approach aligns the two lifecycles at decision points. During design, exchange hazards, threat scenarios, safety constraints, and zone boundaries. During implementation, trace security requirements alongside safety requirements and record where a control supports, or could impair, a safety function. During verification, combine evidence where practical but preserve discipline-specific acceptance criteria.

Change management is the continuing bridge. A firewall rule, operating-system patch, remote-access change, controller firmware update or new SOC collector can alter timing, communications and recovery behaviour. Each change should trigger proportionate cybersecurity and functional-safety impact assessment, followed by regression testing of the affected end-to-end scenarios.

Design for Recovery, Monitoring and Integrated Testing

• Design for Recovery, not only Prevention: Maintain golden configurations, protected backups, spare strategy and restore procedures. Prove that a controller, HMI, or firewall can be recovered within the operationally acceptable time.
• Monitor without Destabilising: Prefer passive discovery for fragile or legacy networks and tightly control active vulnerability testing. Baseline expected traffic and alarm on meaningful changes rather than collecting data with no response process.
• Test Cyber-Induced Failure Modes: Include loss of an external connection, invalid commands, blocked protocols, credential failure, network congestion, loss of time synchronisation and unauthorised engineering attempts in integrated FAT/SAT or a representative test environment.

Why Brownfield TVCS Projects Require an Installed-Base Survey First

Experience from a live utility-tunnel SCADA upgrade reinforced the importance of evaluating the installed base before introducing perimeter firewalls, SOC connectivity, or vulnerability testing. This sequence exposed legacy constraints early and allowed security controls to be matched to the capabilities and operating limits of the existing system. The same principle applies to brownfield TVCS projects: survey the installed base first, define zones, conduits and dependencies, then introduce controls through a staged migration supported by representative testing and a proven rollback plan.

Key Design Requirements for Secure and Safe TVCS

• Keep SIL and Security Level assessments distinct but reconcile their assumptions and interfaces.
• Segment TVCS into purposeful zones and tightly controlled conduits while preserving local emergency action.
• Treat remote access, patching, monitoring and backup recovery as engineered lifecycle functions.
• Validate credible cyber-induced failures alongside hardware, software and communications failures.
• Future-ready TVCS will combine secure-by-design architecture, passive operational visibility, and auditable change without compromising deterministic safety performance.

Standards and Further Reading

1. IEC, Overview of functional safety and the IEC 61508 lifecycle — iec.ch/functional-safety
2. ISA, ISA/IEC 62443 Cybersecurity Series Designated as IEC Horizontal Standards — isa.org
3. ISA/IEC 62443 Series Overview — isa.org/standards-and-publications/isa-standards/isa-iec-62443-series-of-standards
4. Dragos, ISA/IEC 62443 Series of Cybersecurity Standards — dragos.com/blog/isa-iec-62443-standards