This is the first of a six-part guest blog series titled "The Death of Static Safety". We kick things off with the following blog post outlining why safety certification assumptions don't hold up in reality. Let's dive in!
Static safety is no longer enough. This is not because functional safety is flawed, but because the systems being certified no longer behave the way static safety assumes they do.
ISO 26262 certification is built on assumptions. That is not a weakness; it is how safety arguments work. A system is shown to be acceptably safe as long as specific conditions remain true. Operating domains are respected. Configurations remain intact. Software behavior stays within validated bounds. In ISO 26262, these bounds are breached by faults; in ISO 21448 (SOTIF), they are breached by the inherent limitations of the system’s performance in a complex world. Hazards remain contained within the analyzed envelope.
At the Start of Production (SOP), those assumptions are reviewed, justified, and approved. After SOP, they often become invisible.
Once a vehicle enters operation, nothing meaningful stays frozen. Software changes. Data distributions shift. Fleets encounter environments that were not fully represented during development. Sensors degrade. Machine-learned components evolve. Even when no individual change appears safety-critical, the cumulative effect drifts away from the conditions under which the system was certified.
The safety case does not collapse entirely, but it quietly becomes stale.
This is the uncomfortable reality of post-SOP operation. The system continues to change while the safety argument does not. While ISO 26262 manages systematic faults, it and the current application of SOTIF often lack the runtime mechanisms to detect when real-world Triggering Events push the system beyond its validated performance envelope. There is no built-in requirement to demonstrate, months or years later, that certified constraints are still being respected in the field.
On paper, the system remains certified. In practice, the link between certification and real-world behavior weakens over time.
Static safety worked when systems were largely deterministic, updated infrequently, and deployed into stable operating environments. Autonomy shifts the challenge from Functional Safety (mitigating faults) to SOTIF (mitigating functional insufficiency). The former manages bugs; the latter manages the unknown. Vehicles are now software-defined, continuously updated, and exposed to long-tail operational variability that no validation campaign can fully exhaust.
In this context, safety cannot be a one-time proof. A safety argument that cannot be checked at runtime becomes an assumption that the industry has no mechanism to verify.
This is not a failure of ISO 26262. The standard was never designed to manage operational drift. However, treating certification alone as sufficient after deployment is no longer credible, technically, legally, or regulatorily.
The answer is not to replace certification or invent a parallel safety framework. The original safety case remains the correct foundation. What is missing is a way to ensure that its assumptions do not silently decay once the system is in the field.
Operational Assurance (OA) exists for this reason.
An Operational Assurance System (OAS) does not create a new safety case. It extends the existing one into operational time. It provides evidence that the constraints derived during development are still holding, that the system remains within its certified safety envelope, and that deviations are detected and handled rather than ignored.
Without that evidence, safety remains static while the system is dynamic. With it, safety becomes an operational property rather than a historical claim.
The industry is already being pushed in this direction. Regulators are asking what happens after deployment. OEMs are committing to longer operational lifetimes and broader operating domains. Liability is shifting away from design intent and toward observed behavior in the field.
Static safety is not dying because it was wrong. It is dying because the world does not stop changing at SOP.
A visualization of the compounding risks of static safety failure, from engineering rework
to brand reputation and enterprise-level liability.
LHP Operational Assurance Systems (OAS) was spun out of LHP Engineering Solutions to address a growing gap in safety-critical, software-defined systems: certification at launch no longer guarantees safe operation over time. As complex platforms began receiving continuous software updates and evolving functionality, LHP OAS recognized that traditional "certify-once" models could not prevent runtime drift between validated safety intent and real-world behavior. Drawing on decades of leadership in functional safety, cybersecurity, and systems engineering, LHP OAS was formed to focus exclusively on extending certified intent into live environments and developed a platform, Operational Assurance Sentinel, that embodies this concept. LHP's Operational Assurance Sentinel platform delivers deterministic runtime enforcement, operational assurance scoring, and tamper-evident evidence chains that transform safety from a static milestone into a continuously verifiable discipline, enabling organizations to deploy advanced autonomous and intelligent systems with measurable, provable confidence.
Michael Entner-Gómez : Feb 20, 2026 8:32:00 AM
Blog Series: The Death of Static Safety This is the second part of a six-part guest blog series titled "The Death of Static Safety". Today, we dive...
Michael Entner-Gómez : Feb 25, 2026 1:48:29 PM
Blog Series: The Death of Static Safety This is the third part of a six-part guest blog series titled "The Death of Static Safety". Today, we dive...
-AS_328768418-01.1.png)
Christian Glass : Nov 11, 2025 9:48:25 AM
How the LHP OA Sentinel Platform Embeds Operational Trust The automotive industry keeps confusing precision with control. Every major OEM has built...
Christian Glass : Sep 30, 2025 4:54:13 PM
Operational Assurance: The Discipline for the Age of Systems of Systems From Isolation to Interconnection In the past, managing complex environments...
Christian Glass : Oct 28, 2025 11:00:00 AM
Most energy companies know how to measure output, uptime, and efficiency. They can tell you the cost per kilowatt-hour, the margin per barrel, or the...
Michael Entner-Gómez