Safety engineering vs security engineering

What is different

• Adversary model: safety engineering assumes no intelligent adversary — failures are random, systematic or human error; security engineering assumes an adversary who adapts to defences.
• Primary analysis method: safety uses hazard and risk analysis (e.g. HAZOP, FMEA, fault tree analysis); security uses threat modelling and attack surface analysis.
• Governing standards: safety draws on IEC 61508, ISO 26262, IEC 62304 and sector equivalents; security draws on IEC 62443, ISO/SAE 21434, ISO/IEC 27001 and, for products, the CRA's essential requirements.
• Failure mode: a safety failure typically degrades gracefully towards a defined safe state; a security failure can be silent, persistent and designed to avoid detection.
• Organisational home: safety functions often sit with systems or functional safety engineering, close to certification bodies; security functions often sit with IT, product security or software engineering.

What overlaps

Both disciplines exist to prevent unacceptable outcomes and both rely on the same underlying discipline: define the system boundary, identify what can go wrong, assign a requirement to control it, implement it, and produce verification evidence that a reviewer or assessor can follow without reconstruction. Increasingly the outcomes converge directly — a cybersecurity attack on a safety-related control function is a safety hazard with a security cause, and standards such as IEC 61508's newer editions and IEC 62443 explicitly acknowledge this.

Both disciplines also produce a case-based argument for a regulator or customer: a safety case and a security case share a similar structure — claim, argument, evidence — even where the underlying analysis differs.

Which applies to you

• Your product has no network connectivity and no software-controlled safety function: safety engineering practice alone may be sufficient, though this is increasingly rare.
• Your product is purely IT and carries no risk of physical harm: security engineering practice, aligned to ISO/IEC 27001 or sector security standards, is the primary discipline.
• Your product has both a safety function and a digital attack surface — most industrial, automotive, medical and defence products today: you need both disciplines working from a shared risk register, with an explicit interface where a security event can trigger a safety hazard.
• You are unsure whether a given failure mode is a safety issue, a security issue, or both: treat it as both until analysis proves otherwise — the cost of under-scoping is higher than the cost of one extra review.

Frequently asked questions