System safety · · 6 min read
Run separately, the two standards produce two item definitions, two review cadences and two sets of evidence that quietly contradict each other.
ISO 26262 and ISO/SAE 21434 are usually planned as parallel programmes with a liaison meeting between them. On paper this respects the fact that they are different disciplines with different failure models — random hardware faults and systematic error against deliberate, adaptive attack. In practice, parallel programmes tend to produce two item definitions for the same system, drifting apart release by release.
The risk assessment methods do not merge. ASIL determination and CAL determination use different inputs and different reasoning, and forcing them into one workshop format tends to weaken both. Cybersecurity goals and safety goals should be derived independently and then reconciled, not derived jointly from a blended severity scale that satisfies neither standard's intent.
Share the item definition and the change trigger. Keep the risk methods apart. Reconcile the goals, not the process.
One item and asset definition, agreed by both teams before either analysis starts. One change management process that triggers both a HARA re-assessment and a TARA re-assessment from the same change record, rather than two separate change boards discovering the same change independently. A joint review at the point where safety goals and cybersecurity goals are stated, specifically to catch a goal in one discipline that undermines an assumption in the other — for example, a security lockout that defeats a fail-operational requirement.
CRA SCOPE CHECKER
Enter your website. We read what you make and sell, then ask only the few questions the regulation turns on.
About 60 seconds. No account. PDF report on request.
CRA readiness
The reporting duties arrive well before the main obligations. They are the first point where a product organisation is measured on process, not intention.
System safety
Most programmes have traceability on paper. Fewer can follow a single hazard to the verification that closed it without a manual reconstruction.
Engineering practice
When safety and product security work in separate structures, the contradictions surface late — usually in a customer review.
CRA readiness
The template for a technical documentation pack is public. What is not public is which sections a reviewer actually reads twice.
CRA readiness
The first SBOM run is usually a success. The second one, three months later, is where the gap between having a tool and having a process becomes visible.
System safety
A hazard analysis that stops at a mitigation statement has done half the job. The other half is writing something a test engineer can act on.
CRA readiness
Most organisations can produce a vulnerability handling policy on request. Fewer can produce evidence that it was followed on the last three findings.
System safety
A safety case is usually written as an argument about a specific, frozen configuration. Continuous updates make that assumption false on day one.