One foundation for safety and security: build the ECU once.

1. Three standards, one product

Walk into most Tier-1 programmes and you will find three teams who believe they are running three projects. The safety team owns ISO 26262. The security team owns ISO/SAE 21434. The process team owns Automotive SPICE. Each has its own plan, its own folder structure, its own reviewer, and frequently its own copy of the requirements. We have lost count of the kick-offs where these three groups were introduced to each other for the first time – on the same ECU, several sprints in.

This is a category error. There are not three projects. There is one electronic control unit, designed once, coded once, integrated once and shipped once. ISO 26262 is a lens that looks at that one product and asks “how does it fail, and is the residual risk tolerable?” ISO/SAE 21434 is a lens that looks at the same product and asks “who attacks it, and is the residual risk tolerable?” Automotive SPICE is not a third lens at all – it is the discipline that produces the artefacts both lenses point at. Safety and security are analyses; ASPICE is the substance being analysed.

Get that relationship wrong and everything downstream is built on sand. You can write a beautiful Hazard Analysis and Risk Assessment, but if it references an item definition and an architecture that the software team never actually maintained, it is a document about an ECU that does not exist. The argument of this article is blunt and, in our experience, non-negotiable: you cannot do credible functional safety or credible cybersecurity without solid ASPICE work products underneath them. Not “it helps”. Mandatory.

2. ASPICE work products are the substrate

Strip away the maturity-level theatre and Automotive SPICE is, at heart, a specification of work products and the consistency relationships between them. Those work products are precisely the things safety and security need to do their job.

• SYS.2 / SWE.1 – requirements. System and software requirements, structured, atomic, verifiable, with status. This is the corpus onto which a safety goal or a cybersecurity goal is decomposed. No clean requirements baseline, no defensible derivation of safety or security requirements.
• SYS.3 / SWE.2 – architecture. The system and software architectural design – components, interfaces, dynamic behaviour, resource budgets. A HARA needs to know the item boundary; a TARA needs to know the attack surface. Both read it off the architecture.
• SWE.3 – detailed design. Unit-level design that makes freedom-from-interference and security partitioning claims actually checkable rather than aspirational.
• SWE.4–SWE.6 – verification & integration. Software unit verification, software integration and integration test, and software qualification test. This is where “the safety mechanism reacts within FTTI” and “SecurityAccess rejects an invalid key” stop being claims and become evidence.
• MAN.3, SUP.8, SUP.9, SUP.10 – the connective tissue. Project management, configuration management, problem resolution management and change request management, plus the bidirectional traceability that the engineering processes demand. This is the part teams skip and the part that decides whether your evidence survives an assessment.

Notice that none of the items above is a safety artefact or a security artefact. They are process artefacts. Yet a Functional Safety Concept (FSC), a Technical Safety Concept (TSC) and an FMEDA are all derived from and traced to these work products – and so are the cybersecurity goals, the cybersecurity requirements, and the verification that closes them. The ASPICE work products are the shared ground. Everything else stands on them.

3. The mandatory dependency, concretely

It is easy to nod along with “ASPICE is the foundation” and still build silos. So let us make the dependency physical.

A HARA (ISO 26262-3) cannot start without two inputs: an item definition and at least a coarse architecture. You enumerate operational situations and hazardous events, you classify Severity, Exposure and Controllability, you assign an ASIL, and you formulate safety goals, each with a safe state and, where relevant, a Fault Tolerant Time Interval (FTTI). Every one of those steps assumes you know what the item is and what is inside its boundary. That knowledge lives in the ASPICE item definition and SYS.3 architecture. If the architecture on paper is not the architecture in the repository, your S/E/C ratings are guesses dressed as analysis.

A TARA (ISO/SAE 21434, Clause 15) is even more obviously parasitic on architecture. The very first step is to identify assets and their cybersecurity properties – you cannot identify an asset you have not modelled. Then you derive threat scenarios, rate impact across the safety, financial, operational and privacy categories, assess attack feasibility, determine risk, and decide treatment that becomes cybersecurity goals and requirements. Damage scenarios are defined against assets; attack paths are traced through interfaces and trust boundaries. Assets, interfaces, trust boundaries – all of these are read directly off the SYS.3/SWE.2 architecture and the interface descriptions.

The conclusion is uncomfortable but unavoidable: garbage in, decoration out. If the architecture is not real, complete and traceable, both the HARA and the TARA are theatre. We routinely see TARAs whose asset list does not match the component list in the architecture, and HARAs whose item boundary excludes an interface the software clearly uses. In roughly 60–70% of the first-pass assessments we run, the single largest root cause of weak safety and weak security work products is the same defect – a requirements and architecture baseline that was never solid in the first place. Fix the substrate and both analyses improve at once. That is not a coincidence; it is the whole point.

4. Where safety and security share artefacts – and where they legitimately diverge

Because both disciplines analyse the same substrate, they share far more than most organisations exploit. The shared artefacts are not a nice-to-have; treating them as shared is what makes the evidence reconcile.

• Item / asset definition. The thing safety calls the “item” and security calls the set of “assets” are two views of one boundary. Maintain one boundary, two annotations.
• Architecture (SYS.3 / SWE.2). One architectural model carries safety attributes (ASIL allocation, freedom from interference) and security attributes (trust boundaries, crypto placement, HSM usage) as properties on the same elements.
• Verification & integration (SWE.4–SWE.6). Safety mechanisms and security controls are both verified through the same test infrastructure and integration stages. A fault-injection campaign and a penetration-test campaign run against the same integrated build.
• Configuration & change management (SUP.8 / SUP.10). One configuration baseline, one change process. A change record carries both a safety-impact and a security-impact disposition.
• Problem resolution (SUP.9). One defect database where every finding can be tagged safety-relevant, security-relevant, both, or neither.

They do, however, legitimately diverge – and pretending otherwise is its own failure mode. The differences are in the nature of the threat model, not the substrate:

• Random/systematic failure vs intelligent adversary. Safety reasons about faults that happen with a probability; security reasons about an attacker who deliberately seeks the worst case. You cannot assign an exposure probability to a motivated attacker.
• FTTI vs attack feasibility. Safety bounds time – the Fault Tolerant Time Interval. Security bounds effort – attack-feasibility ratings (for example attack-potential, CVSS-based or attack-vector-based methods, per ISO/SAE 21434 Annex G). Different axes, computed differently.
• Safe state vs secure state. A safe state may be “limp home” or “controlled shutdown”; a secure state may be “reject the message, log, and continue”. Occasionally these conflict – the safest reaction opens an availability attack, or the most secure reaction degrades a safety function – and resolving that conflict is precisely the co-analysis that silos make impossible.

5. The cost of silos

Build the three in isolation and the costs are predictable, because we have paid them on rescue engagements more than once.

Duplicate and contradictory requirements. The safety team writes a requirement on message integrity for fault detection; the security team writes a near-identical one for authenticity; neither knows the other exists. Six months later a change touches one and not the other, and now your own requirements baseline disagrees with itself. We have seen single ECUs carry 15–25% redundant requirements purely from parallel, uncoordinated authoring.

Two traceability trees that never reconcile. Safety traces goals→FSC→TSC→requirements→tests. Security traces goals→requirements→controls→tests. If both trees hang off separate copies of the architecture, they cannot be reconciled at all – and the bidirectional-traceability and consistency checks an assessor runs find exactly that.

Silent cross-discipline breakage. This is the expensive one. A security mitigation adds a message-authentication step in the communication stack; nobody re-checks the safety timing, and the added latency now eats into the FTTI budget. Or a safety change reallocates a function to a different core and silently moves it across a trust boundary the TARA assumed was intact. With separate change processes, neither team is even notified.

Findings on consistency. Assessors and auditors do not only check whether each artefact exists; they check whether the artefacts agree. Inconsistency between the safety view, the security view and the engineering work products is among the most common and most damaging findings, because it cannot be closed by writing one more document – it requires re-establishing the shared baseline you should have had from the start. In our experience, consistency-class findings dominate the rework effort on siloed programmes far more than any single missing analysis.

6. The integrated lifecycle – one V-model, three lenses

The alternative is not heroic. It is simply to build the ECU as one unitary whole and let each discipline be a lens onto shared artefacts.

There is one V-model. Requirements elicitation produces one requirements set in which each requirement may be tagged safety-relevant, security-relevant, both or neither. Architecture is one model whose elements carry ASIL allocations and trust-boundary annotations side by side. Verification is one campaign in which fault injection (proving safety mechanisms) and penetration testing (proving security controls) run against the same integrated builds and feed one problem-resolution database.

On top of that single backbone, you run co-analysis. ISO/SAE 21434 explicitly anticipates the safety/security interplay, and ISO 26262 expects you to consider it. The canonical case is a security attack that causes a safety hazard – spoofed sensor data driving an actuator into an unsafe state, or a denial-of-service that starves a safety function of its inputs. You can only see that interaction if the threat scenario from the TARA and the hazardous event from the HARA are looking at the same architecture element. In a co-analysis we walk each attack path to ask “does this terminate in a hazardous event?” and each hazardous event to ask “can an adversary trigger this on purpose?” That conversation is structurally impossible across two disconnected toolchains.

And there is shared change control. A single change request, raised once under SUP.10, carries a mandatory safety-impact and security-impact disposition before it can be approved. When the architecture moves, the safety analysis, the security analysis and the process evidence are flagged for re-assessment in the same transaction – not discovered to be stale six weeks later in an audit.

7. How we set this up

Our practice is built on the conviction in section 1: one product, one backbone, three lenses. We do not run a safety project, a security project and a process project; we run one engineering programme in which the ASPICE work products are the single source of truth, and the ISO 26262 and ISO/SAE 21434 activities are disciplined views on top of them.

Concretely, that means one requirements and architecture baseline under proper configuration and change management, with safety and security attributes carried as first-class properties on the shared elements rather than maintained in parallel documents. It means traceability that closes the loop from goal to verification for both disciplines through the same work products, so an assessor can follow one thread instead of trying to reconcile two. And it means a change process where a single modification updates safety, security and process evidence together, so the three never drift apart.

We bring this together across our software engineering work – where the ASPICE backbone is actually built and maintained – our functional safety practice for the ISO 26262 lens, and our cybersecurity practice for the ISO/SAE 21434 lens, including hands-on ECU penetration testing that verifies security controls against the same integrated builds the safety campaign uses. Where teams need to internalise this way of working rather than outsource it, our training and consulting exists to make the “one foundation” model the default rather than the exception. The recurring lesson from every rescue we have run is the same: the organisations that treat ASPICE as the substrate spend their effort engineering the product, and the ones that treat it as a separate box to tick spend their effort reconciling evidence that should never have diverged.

---

Want a 30-min walkthrough on your project?

No NDA needed. Tell us the standard, the item or asset, the assessor, and your deadline. Within 48 hours you’ll get a one-page diagnostic mapped to the points above — yours to keep, whether or not you hire us.

Book a walkthrough →

---

Author: Adrian Valea, Founder & Managing Director, SafetyTrust Software Technology GmbH. ASPICE Provisional Assessor (intacs / VDA), Functional Safety Engineer (TÜV Rheinland), Automotive Cybersecurity (TÜV NORD). Published 2026-06-05.