ISO 26262 × ISO/SAE 21434 × CRA
Most advice on this subject says safety and security should work together. That is true, and it is not the problem. The problem is that they want different things, and somebody has to decide when they disagree.
Safety wants predictability, availability and inspectability. Security wants least privilege, opacity and locked-down interfaces. Both are right. In most organisations the conflict is settled late, informally, by whoever escalates hardest — and the decision is never written down anywhere an auditor can find it.
At design time
Where the two pull against each other
The diagnostic access a safety engineer needs is an attack surface. Secure boot adds latency that eats into a fault-tolerant time interval. Cryptography in a signal path adds jitter to something that was specified as deterministic. A watchdog that resets on anomaly is availability to one discipline and a denial-of-service vector to the other.
None of these is a misunderstanding between departments, and no amount of process alignment resolves them. They are engineering trade-offs with real costs on both sides, and they are cheap to settle at architecture time and ruinous to settle after integration. Our job is to surface them while they are still cheap, put a number on each side, and make sure the decision and its rationale end up somewhere durable.
Joint analysis
You cannot average over an attacker
ASIL comes from severity, exposure and controllability, and assumes faults that behave statistically. Attack feasibility assumes an intelligent adversary who picks the worst case and adapts to whatever you put in the way. The two numbers do not live on the same scale, and a shared risk register that treats them as if they did looks like good integration while quietly hiding the items that most need a human decision.
What works is running the analyses together on the same item, with both disciplines in the room, while keeping the two scales distinct. Established methods such as SAHARA combine the automotive HARA with STRIDE for exactly this purpose. We facilitate the session, keep both sides honest about what their numbers actually mean, and produce a result that a safety assessor and a cybersecurity auditor can each recognise as their own.
Joint HARA and TARA
Moderated sessions on one item definition, producing a hazard picture and a threat picture that reference each other instead of contradicting each other six months later.
An owner for the interface
Who decides when a security control degrades a safety property. Named, with an escalation path, before the first conflict rather than during it.
Two cases, one argument
A safety case and a cybersecurity case that share assumptions rather than restating them differently — because the contradiction between them is what a reviewer finds first.
The part nobody plans for
Safety freezes at SOP. Security never does.
A safety case is closed at start of production. The argument is fixed, signed, and the people who built it move on to the next programme. Security does not close: R155 expects monitoring for the life of the vehicle, R156 makes updates routine, and the Cyber Resilience Act now adds reporting duties on top.
Open source is what turns this from a theoretical tension into a scheduled event. A safety-relevant function sits on a stack containing components you did not write and do not control, each carrying a vulnerability stream that arrives on its own timetable. In year six a CVE lands in a library underneath a safety function, published by someone who has never seen your item definition.
Then the clocks collide. The CRA gives you twenty-four hours for an early warning on an actively exploited vulnerability and seventy-two hours for the notification. A safety impact analysis does not run on a twenty-four-hour clock. Neither does a confirmation review. So someone has to judge, under a regulatory deadline, whether a patch is safe — against an argument written years earlier by people who have left.
And there is a precondition almost nobody has in place: you cannot assess the safety impact of a vulnerability if you cannot say what was in the build. That makes SBOM practice a safety concern rather than a licence-compliance chore — and it is the reason we treat open-source compliance as part of this work rather than a separate discipline.
The work here is designing the decision path before the clock starts: what triggers a safety impact analysis, who is authorised to judge it, what evidence has to have been kept from the original programme for that judgement to be possible at all, and which parts of the safety case were written to survive a change and which were not. It is unglamorous, it is cheap to do in advance, and it is the difference between a disclosure being a bad week and a disclosure being a recall.
Either side on its own: Functional Safety → · Automotive Cybersecurity →