Safety-Security Co-Engineering

Safety engineering asks what can fail and how likely it is; security engineering asks who might attack and how. Co-engineering brings the two analyses together: the hazard analysis is checked for hazards that an attacker could trigger deliberately, and the threat analysis is checked for security controls that could interfere with a safety function, for example an authentication step that delays an emergency stop or a firewall that blocks a vital message.

In practice this means joint reviews at defined lifecycle milestones, a shared system model including zones and conduits, and coordinated change management so that a security patch triggers the right level of safety re-assessment and a safety change is reviewed for its security impact. TS 50701 and IEC 63452 provide the mapping between the two lifecycles, and Security-Related Application Conditions carry the security assumptions into the safety case's operating conditions.

The central rule of rail cybersecurity is that security must not degrade safety. A control that would be standard in IT, such as active scanning, agent software or automatic blocking, can invalidate a safety case or stop trains, so it cannot be applied to certified systems without a joint assessment. Co-engineering is how operators and suppliers decide what is acceptable.

The reverse also holds: a safety-certified system that is trivially attackable is not safe in practice, because the safety analysis assumed random failures rather than a hostile actor. Regulators and independent safety assessors increasingly ask for evidence that cybersecurity has been considered in the safety case, making co-engineering a formal expectation rather than a best practice.