Safety-Critical HIL Compliance Under ISO 26262 and IEC 62443

HIL's place within ISO 26262 requirements across the development lifecycle

A hardware-in-the-loop bench puts a real ECU on the table and wraps it in a simulated world: virtual sensors, virtual loads, virtual road conditions, all running in closed loop while the ECU's production software runs exactly as it would in a vehicle. That setup now answers to two separate compliance regimes at once. ISO 26262 governs functional safety across the vehicle's development lifecycle, and IEC 62443 governs cybersecurity for the industrial control systems that increasingly make up the HIL bench itself. Neither standard was written with the other in mind, yet a modern HIL environment can't satisfy one without answering to the other too.

Manufacturers built 93,546,599 vehicles worldwide in 2023. A validation gap that slips through a HIL campaign doesn't happen once, it happens across every market where that platform ships, over and over, at scale. A modern vehicle carries anywhere from 70 to more than 150 ECUs, trading over two million messages per minute amongst themselves, running on software that has grown into the hundreds of millions of lines of code. A defect in one ECU doesn't stay put, either. A defect in one ECU propagates through the bus architecture and appears somewhere else, often somewhere the original engineer never touched.

Recall data show what happens when that containment fails. Software-related issues accounted for roughly 46% of recalled vehicles in the US in 2024, up sharply from about 14% the year before. In January 2026, Citroën, Opel, and Fiat recalled 215,230 vehicles after a software error blanked instrument cluster screens and knocked out ADAS functions. Around the same period, Waymo recalled its entire fleet of 3,067 vehicles after robotaxis failed to stop for school buses. HIL testing exists to catch failures like these before a vehicle reaches a customer. The fact that they keep happening anyway is the reason HIL stopped being a simple I/O bench check and became the strategic validation layer for ADAS, autonomous driving, EV powertrains, and the multi-ECU interactions that define a modern vehicle.

ISO 26262, "Road vehicles, functional safety," first published in 2011 and updated in its second edition in December 2018, now extends from passenger cars to nearly every category of road vehicle except mopeds. It descends from IEC 61508, the general-purpose functional safety standard for electrical and electronic systems, but retunes that framework for automotive use. Where IEC 61508 uses Safety Integrity Levels, ISO 26262 substitutes Automotive Safety Integrity Levels, ASIL A through D, plus a QM tier for risks that don't rise to safety-critical status. Risk gets classified along three axes specific to road use: severity of harm, exposure (how often the situation comes up), and controllability (whether the driver can do anything about it).

The standard follows a V-model: concept phase, system and software development, hardware development, then integration and verification. HIL sits at that last stage, but its shape gets decided much earlier. The Hazard Analysis and Risk Assessment, or HARA, happens at the concept phase and produces the safety goals and ASIL ratings that determine how hard a HIL campaign has to work later. ASIL D, the toughest rating on the scale, applies where a malfunction could cause life-threatening injury, and it governs braking systems, steering, and ADAS arbitration logic. A rig testing an ASIL D braking function has almost nothing in common with one testing an ASIL A infotainment feature, and treating the two the same causes a mistake that becomes visible later, usually during an audit, usually at the worst possible time.

Coverage requirements scale directly with ASIL rating. ASIL A calls for 80% branch coverage. Climb to ASIL C and MC/DC (modified condition/decision coverage) becomes recommended; at ASIL D it's highly recommended. That escalation sounds modest on paper, but the number of test cases needed to hit MC/DC coverage grows exponentially as system complexity increases. That's the real reason HIL automation stopped being optional for anything touching an ASIL D function. No team gets there by hand, not at this scale, not on any schedule that ships a car.

What IEC 62443 requires when HIL infrastructure carries network connectivity

IEC 62443 is the international benchmark for securing Industrial Automation and Control Systems, built jointly by IEC and ISA. It is organized into series covering general concepts, security management policies, system-level requirements, and component-level product requirements. Security Levels run from the lowest tier, indicating no security requirement, up to the highest tier, addressing the most capable threats. Maturity Levels sit on a separate axis entirely: they certify a vendor's development process, while Security Levels certify what a product or system can actually withstand. Confusing the two costs money, because a vendor can run a disciplined development process and still ship a product rated at a low security level.

The standard keeps moving, too. ANSI/ISA-62443-2-1-2024, published in January 2025, revised the Security Program Elements around a maturity model. ISA-TR62443-2-2-2025, published in December 2025, added guidance on IACS security protection schemes. The broader 2024 wave of updates lined up IEC 62443 with ISO/IEC 27001, NIST SP 800-82, and the EU's NIS2 Directive, so a compliance posture built for one of those frameworks increasingly carries weight in the others.

An industrial security standard reaches into a test bench because a HIL bench is, in the plain sense IEC 62443 means, an industrial control system. It runs a real-time operating system, talks over CAN, Ethernet, and LIN, often connects to cloud orchestration or remote access tools, and sits wired into CI/CD pipelines that span multiple facilities. That's an IACS by any reasonable definition, network connectivity and all. The two standards ask different questions of the same rig. ISO 26262 asks whether the system fails safely when a random hardware fault or software error occurs. IEC 62443 asks whether the system stays secure when someone tries to break in on purpose. A HIL environment has to answer both, at the same time, on the same physical hardware.

The intersection of ISO 26262 and IEC 62443 obligations inside a HIL test environment

ISO/SAE 21434, the cybersecurity engineering standard for road vehicles, sits alongside ISO 26262's safety lifecycle and gets used in practice alongside IEC 62443's security disciplines. Autonomous driving programs increasingly treat ISO 26262, ISO 21448 (SOTIF), and ISO/SAE 21434 as a converging set of obligations rather than three tracks a team can manage independently. That convergence is where the practical overlap with IEC 62443 actually lives.

Some demands reinforce each other cleanly. ISO 26262 demands rigorous documentation linking safety requirements to verification evidence; IEC 62443 calls for comparable rigor in documenting security-related activity. A HIL platform serving both needs one traceability architecture, not two logging systems bolted together after the fact. Tool qualification runs into the same overlap: ISO 26262 Part 8's tool qualification framework applies to every tool in the safety chain, while IEC 62443 layers on security requirements for those same tools. Qualifying a tool for ASIL use says nothing about whether it's locked down against unauthorized access. Change management is the third shared demand. Both standards call for changes to hardware, software, or configuration to be assessed for their effect on prior evidence, and a firmware update pushed to the HIL simulator can quietly invalidate a safety case and a security case in the same afternoon.

Then there are the places where the two standards pull against each other, and this is where most teams get it wrong. ISO 26262 fault injection means deliberately corrupting signals, forcing bus errors, and simulating component failures on purpose. IEC 62443 security hardening exists to stop exactly that kind of unauthorized signal manipulation. Left on default settings, a security policy will block the very fault injection a safety campaign requires. The fix is to build the HIL environment so intentional fault injection is controllable and authenticated: a deliberate exception carved into the security posture, established deliberately ahead of time rather than improvised by engineers under deadline pressure at 11pm. Network connectivity creates a similar tension. Remote access, CI/CD integration, and cloud-based scenario libraries all make a HIL bench more useful, but IEC 62443's network segmentation approach can call for strict network isolation. Getting both at once takes deliberate architecture, not whatever ships by default. Documentation scope diverges as well: a safety case addresses system behavior under failure conditions, while a security case addresses system behavior under intentional attack. Producing both from one HIL campaign means the test design has to capture both dimensions from the start, not stitch them together in a report afterward.

Running an ISO 26262 campaign and following it with a separate IEC 62443 review, as two sequential projects, does not add up to dual compliance. It adds up to two incomplete pictures, each blind to what the other one caught. The test infrastructure, the test design, and the evidence collection all have to get built for both frameworks from day one, or the gap becomes visible in an audit nobody budgeted time for.

Fault injection as the technique that must satisfy both standards at once

ISO 26262 recommends fault injection by name, as a reliable way to check that safety mechanisms actually work and that safety requirements are correctly implemented, not just documented. In a HIL environment, automated fault injection touches sensors, actuators, communication interfaces, and internal ECU components, with bus-side fault types such as signal corruption, timing anomalies, and communication loss carrying particular weight.

Fault injection in complex systems stays largely a manual, expert-driven exercise, which causes testers to limit themselves to the smallest set of test cases they can get away with in most HIL programs. Testers routinely limit themselves to the smallest set of test cases they can get away with, because covering the full fault space properly takes more time than most programs can afford. That's a structural constraint of how large the fault space gets once a system reaches modern complexity, not a knock on any particular team, and no amount of good intentions shrinks it.

IEC 62443 changes what that same fault injection means. Message tampering and message injection, the standard fault types ISO 26262 already asks engineers to test, are also the precise attack vectors IEC 62443 requires systems to resist. Design the test with both frameworks in mind from the outset, report the results against both, and running the test once generates evidence for a functional safety verification and a security assessment at the same time. Running it with only safety in mind leaves the security value sitting on the table, for no good reason.

Tool qualification obligations and what certified HIL platforms demonstrate

ISO 26262 sets out a tool qualification framework: every tool used in safety-critical development gets evaluated for its potential to introduce an error or fail to catch one. How rigorous that evaluation needs to be scales with how much the tool's output gets trusted as safety evidence and how much independent checking exists around it.

A HIL compliance campaign touches a wide spread of tool categories: requirements management (IBM DOORS, Polarion, Jama Connect), model-based development (MATLAB/Simulink with Embedded Coder), static analysis (Polyspace, PC-lint, LDRA for MISRA C/C++ compliance), unit testing and structural coverage (VectorCAST, Tessy, Cantata), system simulation and HIL platforms (dSPACE, Vector, ETAS), FMEA and FTA analysis (APIS IQ, Isograph FaultTree+), and configuration management (Git, SVN).

Reading formal certifications for what they actually cover affects audit outcomes and legal exposure, not just what goes on a sales sheet. dSPACE holds TÜV Süd certification for three tools, VEOS, Real-Time Testing test automation software, and its Platform API Package, covering use in safety-related development projects across all ASIL levels including ASIL D. Real-Time Testing is Python-based and supports both HIL testing and virtual validation through VEOS, dSPACE's PC-based offline simulation platform. At CES 2025, dSPACE showed SIMPHERA enabling SIL-to-HIL transitions without rewriting test cases, which matters because rewriting test cases across simulation stages is a manual burden that eats budget on long programs. VectorCAST's coverage measurement carries TÜV certification across all ASIL levels, with an Industry Mode that automatically selects the correct coverage criteria for the level in question. PC-lint Plus holds exida certification for ISO 26262:2018 from ASIL A through D. ETAS LABCAR and Simulink Test round out the platforms commonly used for HIL and SIL validation work.

Certification confirms a tool's development process and the reliability of its output as safety evidence, but it says nothing about whether that same tool sits configured correctly for a specific safety case. A TÜV or exida certification for ISO 26262 ASIL D confirms the tool's development process and the reliability of its output as safety evidence. It says nothing about whether that same tool sits configured securely under IEC 62443. Those are two separate questions, and treating a safety certification as a security guarantee is exactly the mistake a penetration test finds afterward rather than one careful architecture review would have caught first. Engineers have to verify both, independently, because passing one never implies passing the other.

The structure evidence generated in HIL must have to satisfy both standards' audit requirements

A safety case and a security case ask different questions of the same test run, so the evidence architecture behind a HIL campaign has to answer both from a single source of truth, not two disconnected trails. ISO 26262 traceability links a safety requirement to a test case to a result, showing an auditor that every safety goal actually got verified. IEC 62443 traceability links a security requirement, or a threat scenario, to a test and its outcome, showing that the system got checked against the attack vectors it's expected to resist. When one fault injection test, say a tampered CAN message, produces evidence relevant to both a safety mechanism and a security control, that evidence needs tagging and storage so both audit trails can pull it independently, without the underlying test ever running twice.

That's a data architecture problem as much as a testing problem. A traceability matrix built only around ASIL requirements has no natural home for a security finding, and a security log built only around SL ratings has no natural link back to a safety goal. Building both in from the start, rather than bolting one onto the other after a campaign wraps, closes an audit in weeks instead of dragging on for months while engineers reconstruct links between systems that were never designed to talk to each other. Given how much recall activity now traces back to software, and how deeply safety and security have become tangled in vehicles that stay permanently connected, that upfront architecture stops being a nice-to-have. It's the only way a HIL bench earns the evidentiary weight both standards actually demand.