Security of Safety-Critical Software: How Security and Safety Are Related

For many years in safety-critical industries, safety and security were treated as largely independent concerns. Safety engineers focused on preventing unintentional failures—hardware faults, software defects, human errors. Security teams, when present, focused on protecting systems from intentional misuse or attack.

That separation no longer works.

In modern aerospace, automotive, rail, medical, and industrial systems, connectivity has fundamentally changed the risk landscape. Safety-critical systems are no longer isolated. They communicate over networks, receive updates, interface with external devices, and increasingly operate in connected ecosystems. As soon as connectivity enters the architecture, security becomes inseparable from safety.

From my experience, the most dangerous misconception today is believing that a system can be functionally safe yet insecure. In reality, insecurity can directly compromise safety.

Safety vs. Security: The Traditional View

Traditionally, safety engineering asks:

• What happens if this component fails?

• What hazards arise from unintended behavior?

• How can we prevent or mitigate those hazards?

Security engineering asks:

• What if someone intentionally manipulates this system?

• What if data is altered, spoofed, or intercepted?

• How do we prevent unauthorized access?

Safety deals with accidental faults.

Security deals with intentional threats.

But in connected safety-critical systems, intentional threats can trigger safety hazards.

How Security Breaches Become Safety Hazards

Consider a flight control computer, an automotive braking system, or a medical infusion pump. If an attacker gains access and alters configuration parameters, delays critical messages, injects malicious commands, or disables monitoring tasks, the resulting behavior may be indistinguishable from a system failure.

In that moment, a security breach becomes a safety event.

I’ve seen architecture discussions where a communication interface was considered “outside the safety boundary” because it was not part of core control logic. But if that interface can inject corrupted data into a safety function, it is absolutely part of the safety case.

Security weaknesses can invalidate safety assumptions.

The Expanding Threat Surface

In older safety-critical systems, isolation was often physical. Air gaps were real. External interfaces were minimal.

Today, systems include:

• Ethernet backbones

• Wireless connectivity

• Remote diagnostics

• Over-the-air updates

• Cloud-linked monitoring

Each interface introduces a potential attack vector. Every new vector is a potential path to unsafe behavior.

Safety analysis without threat modeling is incomplete in modern systems.

Standards Reflecting the Convergence

This convergence is increasingly recognized in industry standards.

In aerospace, DO-326A and related airworthiness security documents complement DO-178C. In automotive, ISO 21434 (cybersecurity) now exists alongside ISO 26262 (functional safety). In industrial systems, IEC 62443 addresses cybersecurity in parallel with IEC 61508.

These frameworks acknowledge that safety and security are intertwined.

From a practical standpoint, security requirements must be considered during safety architecture development—not layered on afterward.

Safety Assumptions Must Be Protected

Every safety argument rests on assumptions:

• Data integrity is preserved.

• Timing constraints are maintained.

• Control commands are authentic.

• System state cannot be arbitrarily altered.

Security ensures those assumptions remain valid.

For example, if your safety design assumes that control messages cannot be forged, but your communication protocol lacks authentication, your safety analysis is incomplete.

In this way, security becomes a precondition for safety.

The Cultural Gap Between Safety and Security Teams

One challenge I’ve observed is cultural. Safety engineers and security engineers often think differently.

Safety engineering emphasizes determinism, fault tolerance, and hazard mitigation. Security engineering emphasizes threat modeling, adversarial thinking, and defense-in-depth.

When these disciplines operate independently, gaps emerge. Safety may assume trusted inputs. Security may implement protections without understanding real-time constraints.

In safety-critical systems, collaboration is not optional. Security controls must respect real-time and deterministic requirements. Safety mechanisms must assume adversarial conditions.

Secure-by-Design and Safe-by-Design

The safest architectures I’ve seen adopt both principles simultaneously:

• Safe-by-design: Hazard analysis drives redundancy, monitoring, and fault handling.

• Secure-by-design: Threat analysis drives authentication, encryption, isolation, and access control.

These should not be separate design phases. They should inform each other from the beginning.

For example, partitioning mechanisms used for safety isolation can also strengthen security boundaries. Conversely, authentication mechanisms can prevent safety-critical command injection.

When aligned, safety and security controls reinforce each other.

Balancing Performance and Protection

Security mechanisms—encryption, authentication, monitoring—consume processing time and memory. In tightly constrained real-time systems, this introduces architectural trade-offs.

Poorly designed security layers can introduce latency or jitter that affect control loops. On the other hand, omitting security for performance reasons creates unacceptable risk.

The solution is not to sacrifice one for the other, but to design holistically. Security controls must be evaluated within timing analysis, WCET calculations, and system integration testing.

Lifecycle Considerations

Security also introduces a lifecycle dimension that safety historically handled differently. Threat landscapes evolve. Vulnerabilities are discovered over time.

Safety-critical systems must now consider:

• Secure update mechanisms

• Patch management strategies

• Long-term cryptographic viability

• Incident response planning

Security is dynamic. Safety certification is often static. Bridging that gap requires careful configuration management and impact analysis.

Closing Thoughts

Security and safety are no longer parallel tracks—they are interdependent foundations of trustworthy systems.

A system that is safe but insecure can be made unsafe. A system that is secure but poorly designed for safety can still fail catastrophically. True assurance in modern safety-critical systems requires both.

From my experience in regulated environments, the strongest programs treat security as part of the safety case—not as an afterthought. They recognize that protecting system integrity, authenticity, and availability is essential to protecting human life.

In today’s connected world, safety without security is incomplete. And security without safety awareness is insufficient.