Safety and security are one engineering chain, not two departments

A connected industrial product typically carries two analyses: a hazard analysis owned by system safety, and a threat model owned by product security. They describe the same architecture, the same interfaces and often the same failure consequences, in incompatible formats.

Where the split becomes expensive

• A security control that degrades a fail-safe path, discovered after integration.
• A safety mitigation that assumes a network property the threat model treats as untrusted.
• Two risk registers with different severity scales, so priority conflicts cannot be resolved.
• Duplicate verification effort against the same interface, with different acceptance criteria.

A shared spine

The practical fix is not to merge the disciplines or their methods. It is to give both a shared spine: one system model and interface definition, one severity scale for consequences, one architecture decision record set, and one verification plan that both analyses draw from. Hazard analysis and threat modelling keep their own techniques and their own reviewers, but they argue about the same picture.

Different methods, one system model, one severity scale, one verification plan.

What changes in practice

Reviews get shorter because the two teams are not reconciling vocabulary. Mitigations get cheaper because conflicts appear at design time. Under CRA, the technical documentation improves noticeably, because the security argument can reference the same architecture rationale the safety argument already relies on. The evidence stops being two stacks that a reader has to reconcile.