Why ISO 26262 and ISO 21434 are no longer "Best Practices"

Sunday, February 1, 2026, at 16:51.

Functional Safety Managers and Chief Product Security Officers (CPSOs) are often the "named" parties in technical documentation for automotive electronics, and their primary anxiety revolves around delineating where their professional engineering judgment ends, and legal liability begins.  To this end, they employ a combination of legal directives, normative standards, best practices and company policies to reduce their legal exposure.

To date, ISO 26262 (Functional Safety) and ISO/SAE 21434 (Cybersecurity) have been deemed "Best Practices" by automotive safety and security professionals, since these standards are (a) widely recognized in industry; and (b) lexical shortcuts that will largely satisfy regulators as accepted common norms.

However, both ISO standards are quickly morphing into "Legal Benchmarks" as more, and more, compliant products crowd out products that employ a different, equivalent, or non-existent approach to safety and security.  This shift is even more pronounced in the European Union (EU), where ISO 21434 is subsumed by the EU's adoption of the UNECE Regulation No. 155 (UN R155).  For the United States, the concept of "State of the Art" (SOTA) is central to meeting the technical and procedural bar required by the law to reduce unreasonable safety and security risks.  Again, both standards are so often referenced as the obvious means for a product to meet and exceed the SOTA, that the standards are now shedding their Best Practice label in favor of an implied Legal Benchmark appellation, likely to show up your next Daubert motion hearing...

In the 2026 automotive landscape, the SOTA is no longer a nebulous concept used in product liability defense. With the maturation of ISO 26262 and ISO 21434, SOTA has been codified through repeated practice and wide embrace.  For the engineer, this means that a deviation from these standards isn't just a technical choice; it is a potential admission of negligence, or more.

Three pitfalls that engineers should be aware of when a Best Practice becomes a Legal Benchmark:

1. The Personal Liability Shift
Under traditional tort law, the company's corporate veil generally protects individual engineers from monetary damages, and most legal proceedings remain a civil matter. Failure to adequately follow the standards more often results in adverse civil judgments when Legal Benchmarks are missed, but also may additionally prompt an inquiry by a regulatory agency as to why the Legal Benchmark was not met.

However, as automotive electronics and software-defined vehicles (SDVs) become more complex, regulatory bodies are looking closer at the written formal safety case for each product that manufacturers launch into the stream of commerce.  The Legal Benchmark expectation causes the agency to look harder.  If a Functional Safety Manager signs off on an ASIL D system knowing that the HARA (Hazard Analysis and Risk Assessment) was incomplete or that FFI (Freedom from Interference work product) was not properly validated, the findings move from the realm of "honest error" into "reckless disregard", which may result in personal criminal charges being handed down by an enterprising prosecutor.

2. The HARA and TARA as Discovery Documents
In the event of a cybersecurity-related collision, both the HARA and the TARA (Threat Analysis and Risk Assessment) documents produced under ISO 26262 and ISO 21434 will be the first document requested in the mandatory discovery process.  They are no longer just "nice to have" pieces of evidence, but effectively become required documentation under the Legal Benchmark expectation.
* The Trap: Many engineering teams treat the HARA or TARA as a living document to improve the system.  While this is an approach true to the standards, this leeway ceases as soon as the first saleable vehicle unit is produced.
* The Legal Reality: To a plaintiff’s attorney, an unaddressed "High" risk in a HARA or TARA is a "smoking gun."

3. Bridging the "Safety-Security Gap"
The most significant legal exposure exists where safety and security seem to conflict. For example, a cybersecurity lockout (ISO 21434) that inadvertently disables a safety-critical braking function (ISO 26262) can go undetected in many organizations that operate in engineering domain silos.  If your Safety Manager and your Cybersecurity Lead are working in silos, your firm is creating a "Liability Gap" that is nearly impossible to defend in front of a jury.

Guibert.law Insight on ISO 26262 and ISO/SAE 21434 Legal Benchmarks: Courts are increasingly looking for "Integrated Lifecycle Management"

1. The Guibert.law Approach

* Protect the Driving Public: we emphasize that the best way to defend from all types of liability is to perform the safety and security work, under the standards, such that the performance of the products is never called in to question, because the safety and security work actually did remove all unreasonable risks.  This means that the safety and security cases must be robustly technically and procedurally sufficient in the real world.  Additionally, this may be achieved in combination with other safety standards such as ISO 21448 (SOTIF or Safety Of The Intended Function), for example.  An Integrated Lifecycle Management system can document all the necessary steps, and serve as discoverable documentation that will help you demonstrate to the authorities that the safety and security cases are not haphazardly created, but track a Legal Benchmark.
* Protect your Engineering Team: we enable your risk management team and your engineering team to mitigate the possibility of mistakes and legal gaps in the work that your engineering team produces under these ISO standards.  Creating an environment, via an Integrated Lifecycle Management system, where your engineering team is legally protected in the normal course of its business activities, will generate the maximum personal and institutional confidence in their work.  For example, resolving apparent conflicts between apparently competing Legal Benchmarks can create some organizational chaos, or procedural complexity. We can help resolve these apparent conflicts, so that the safety and security case authors and their design-responsible staff are not confronted with impossible choices or are not neglectful of either Legal Benchmark.
* Protect your Company: we foster repeatable results through the proper Quality Management System (QMS) implementation in the safety and security engineering domains, including their interfaces to other functions.  QMS is required under our topical Legal Benchmarks, and is often embodied by an Integrated Lifecycle Management system, amongst other measures.  Repeatable positive results across your product line protect your company:

          (a) from allegations of profit-motivated inconsistency, in your safety and security cases; and

          (b) by helping ease the diagnosis of inevitable problems with your QMS, if deficiencies in product safety or security performance are detected.

As with all Quality Management Systems, continuous improvement as measured against final product performance in the field, points to increasing product technical sufficiency, thereby protecting your company.  A more explicit example of repeatable results that protect your company: we can help you implement Legal Privilege during the early, exploratory stages of risk assessment, ensuring that your path to mitigation is protected from premature disclosure.

2. Examples of How We Protect Your Engineering Team
We don't just "check boxes." We provide real services that help your engineers satisfy Legal Benchmarks, within the context of your Integrated Lifecycle Management system:
* DIA (Development Interface Agreement) Review: Ensuring that suppliers are properly bound to provide the correct and sufficient work products, so that your engineers may perform their duty of due diligence under the law and that suppliers are contractually on notice of their concurrent liability before a single development dollar is spent.  If your engineers do know have the necessary design information from the suppliers, they cannot hope to create an adequate safety and security case.
* Safe Harbor Counseling: Structuring your QMS such that the FSMS (Functional Safety Management System) and CSMS (Cybersecurity Management System) fulfill both the duty of due diligence to meet SOTA, and the letter of UN R155 requirements for Type Approval.  We help you know what is necessary ahead of time, so your engineers stay out of the deposition hall and stay in the lab.
* Expert Witness Preparation: Training your lead engineers on how to testify regarding "Residual Risk" without compromising the company.

* Confirmation Measures Audit and Assessment Legal Review: Conducting the confirmation measures audit and assessment under the standards by our certified personnel that possess technical working knowledge of automotive electronics and engineering law experience.  This activity makes sure that your product does not go into production until it is legally sufficient: we use expert issue-spotting, using a regulator's or plaintiff's expert witness lens.  A good assessment or audit helps your engineers get it right!