A Tier 1 supplier submits a proposal for a telematics control unit and the OEM’s response includes a request that wasn’t on the RFQ 3 years ago: a Threat Analysis and Risk Assessment, mapped attack paths with documented feasibility ratings, risk treatment decisions, and assurance evidence an independent auditor can trace from identified threat through to implemented mitigation. This isn’t a request happening at PPAP, after the component has already been designed and built. It’s happening at RFQ stage, before a single line of code exists, because the OEM’s own regulatory obligation may depend on demonstrating that suppliers touching cybersecurity-relevant components can produce appropriate evidence on demand.
ISO/SAE 21434 doesn’t carry legal force on its own. UN Regulation No. 155 is a binding type-approval regulation where a jurisdiction has implemented it, so the applicable legal timetable depends on that jurisdiction. In the EU, the regulation applied to new vehicle types from July 2022 and to newly produced vehicles from July 2024. ISO/SAE 21434 provides a widely used engineering framework that can support R155 evidence, but R155 does not make that standard the sole legal compliance route. The practical consequence for a supplier remains important: when an OEM sells into a jurisdiction applying R155, supplier cybersecurity evidence can become part of the OEM’s own compliance case, and documentation gaps can become an OEM risk.
This guide walks through exactly what a supplier has to prove under this framework, at both the organizational and product level, what the actual work products and evidence look like, where audits most commonly find suppliers unprepared, and what the ongoing, post-production obligations require long after the component has shipped.
TL;DR
| What has to be proven | Where it’s demonstrated |
| A functioning Cybersecurity Management System exists at the organizational level | Clause 5 and 6 work products: cybersecurity policy, organizational audit report, cybersecurity plan, assessment report, release recommendation |
| A rigorous Threat Analysis and Risk Assessment was performed for the specific product | Clause 15’s 8 TARA work products, from asset identification through documented risk treatment decisions |
| Cybersecurity responsibilities across the supply chain are explicitly defined | The Cybersecurity Interface Agreement, the single Clause 7 work product, consistently flagged as a weak point in audits |
| Evidence scales with how critical the component actually is | Cybersecurity Assurance Levels can be used as an optional, informative way to communicate assurance rigor when an organization or customer chooses that approach |
| Risk-derived hardware controls exist where the product’s cybersecurity requirements justify them | Clause 10 requires risk-based product-development cybersecurity engineering, not universal tamper detection or hardware-based key storage |
| Risk treatment was actually implemented, not just decided on paper | The single most common point of audit failure, distinct from the quality of the TARA itself |
| Vulnerability management and incident response continue after production | Ongoing Clause 8 activities continue after vehicle launch; supplier reporting cadence is set by applicable customer or contractual requirements |
None of these individually determines whether an audit succeeds. What determines it is whether the evidence connects into a single, traceable story an outside assessor can follow from an identified threat all the way through to a verified, currently-maintained mitigation, rather than a scattered collection of documents that technically exist but don’t logically connect to each other.
The Regulatory Relationship: Standard Versus Law
Understanding what a supplier actually has to prove starts with untangling a distinction that gets blurred constantly in casual industry conversation: ISO/SAE 21434 and UN R155 are not the same thing, and conflating them leads suppliers to misjudge both their legal exposure and what auditors will actually ask for.
UN R155 Is the Law; ISO/SAE 21434 Is a Supporting Framework
UN R155 operates on 2 layers that a supplier needs to understand distinctly in jurisdictions that implement it. There’s company-level CSMS certification, confirming the organization has a functioning cybersecurity management system, and product-level type approval, confirming a specific vehicle type meets the regulation’s requirements. Where R155 applies, both elements matter for vehicle type approval. WP.29 does not name ISO/SAE 21434 as legally mandatory text within R155 itself. In practice, many OEMs and approval authorities use ISO/SAE 21434 as a recognized engineering framework for generating supporting evidence, but other defensible methods may be accepted if they satisfy the applicable regulatory and customer requirements.
Why This Distinction Matters for a Supplier’s Actual Risk Exposure
A supplier that only sells into markets outside UNECE’s regulatory reach might reasonably assume none of this applies to them. That assumption breaks down the moment their OEM customer sells into a regulated market, because the component’s cybersecurity evidence flows upward into that OEM’s own regulatory submission regardless of where the supplier itself is headquartered or where its other customers operate. This is why cybersecurity requirements now appear at RFQ stage rather than waiting for production part approval: OEMs need assurance before committing to a supplier that the evidence trail required for their own type approval will actually exist when it’s needed.
ISO/SAE 21434 Published August 2021 and Applied Immediately
The standard, published jointly by ISO and SAE International, applies to series-production electrical and electronic systems whose development or modification began after its publication date. It does not impose a universal rule requiring programmes already under development in August 2021 to retrofit all prior work or formally close under SAE J3061. Legacy programmes may still face customer, contractual, certification, or regulatory transition expectations, but those requirements should be traced to the applicable programme or jurisdiction rather than described as a mandate created by ISO/SAE 21434 itself.
Proof Point 1: A Functioning Cybersecurity Management System
The first and most foundational thing a supplier has to prove is organizational, not project-specific: that a real, operating CSMS exists, covering structure, policies, and processes across the entire company, not just a single programme built specifically to satisfy one demanding customer’s requirements and abandoned once that particular contract closes out.
What the CSMS Actually Has to Demonstrate
Clause 5 establishes the organizational-level cybersecurity requirements, and Clause 6 covers how a specific project applies that organizational framework in practice. Together, these clauses require an organization to define a documented cybersecurity policy, establish clear roles and responsibilities for cybersecurity decisions, demonstrate that cybersecurity culture and awareness exist beyond a single compliance document sitting unread in a shared drive, and show that the organization has actually audited itself against these requirements rather than simply asserting compliance.
The core organizational-level work products an assessor expects to see:
- Cybersecurity policy, the foundational document establishing the organization’s overall approach and commitment to cybersecurity engineering
- Organizational audit report, evidence that the organization has assessed its own CSMS against the standard’s requirements, not merely written a policy and left it untested
- Cybersecurity plan, the project-level document translating organizational policy into specific activities, milestones, and responsibilities for a given product
- Assessment report, documenting the results of cybersecurity assessment activities conducted during the project
- Release recommendation, the formal decision point confirming whether a product is ready for release from a cybersecurity standpoint, distinct from functional or quality release criteria
Why This Gets Assessed Separately From Any Specific Product
An organization can build one excellent, thoroughly documented TARA for a single flagship product and still fail a CSMS-level audit if that rigor doesn’t reflect a repeatable, organization-wide process. Auditors evaluating CSMS maturity are specifically looking for evidence that cybersecurity engineering happens consistently across projects, not as an exceptional effort mobilized only when a specific customer demands it, since a one-off demonstration of capability doesn’t answer the question type-approval authorities actually care about: can this organization be trusted to maintain this discipline across every future product it delivers.
Proof Point 2: A Rigorous, Traceable TARA
Where the CSMS proves organizational capability, the Threat Analysis and Risk Assessment proves that capability was actually applied to the specific product in question, and this is where the majority of a supplier’s day-to-day compliance effort concentrates across the entire development lifecycle, from early concept through final validation.
The 8 TARA Work Products, Not a Single Deliverable
Clause 15 defines 8 distinct TARA work products, numbered WP-15-01 through WP-15-08, corresponding to 8 analytical steps that many secondary sources incorrectly collapse into a single “TARA document.” Understanding these as 8 separate, connected work products, rather than one monolithic deliverable, matters because an auditor reviewing a TARA is checking that each step logically follows from the one before it.
| Step | What it establishes |
| Asset identification | What within the item or component actually needs protecting |
| Damage scenario identification | What harm could result if an asset’s cybersecurity properties are compromised |
| Threat scenario identification | What specific attack scenarios could realistically cause each damage scenario |
| Impact rating | How severe the consequences of each damage scenario actually are |
| Attack path analysis | The specific technical routes an attacker could follow to realize a threat scenario |
| Attack feasibility rating | How easy or difficult each attack path is to actually execute, given current attacker capability |
| Risk value determination | The combined risk level resulting from impact and attack feasibility together |
| Risk treatment decision | Whether the risk is avoided, reduced, shared, or retained, with documented rationale |
Why the Risk Treatment Decision Is Where Audits Actually Focus
A risk treatment decision of “reduce” isn’t sufficient on its own. An auditor needs to see the specific mitigation that was implemented, evidence that it was actually built into the delivered product rather than only planned, and confirmation that the mitigation still holds given the current, evolving threat landscape rather than the landscape as it existed when the TARA was first written. This is the step where a technically strong TARA and a technically strong delivered product most commonly diverge, and it’s the specific gap that experienced assessors report finding most often during supplier audits.
Cybersecurity Assurance Levels Offer Optional Guidance on Assurance Rigor
Cybersecurity Assurance Levels appear in informative Annex E as an optional way to communicate assurance rigor. A CAL can be associated with cybersecurity goals, but ISO/SAE 21434 does not require every asset to receive one, and the level cannot be determined directly from a TARA risk value. CAL is only indirectly related to risk and should follow the chosen organizational, customer, or assessment approach.
What CAL can communicate when an organization chooses it:
- Assurance expectations can be expressed at different levels when a project or customer uses CAL, but the standard does not prescribe one universal activity set for each level
- Testing depth may be defined by customer requirements, organizational methods, certification schemes, or the product’s cybersecurity requirements rather than by CAL alone
- Evidence formality can vary with the assurance approach being used, but ISO/SAE 21434 does not state that a particular CAL automatically mandates a fixed evidence format
- Verification independence may be required by a customer, assessment scheme, organizational policy, or another applicable rule, and should not be attributed automatically to increasing CAL values
When CAL is used, the organization should document what the level means and which assurance activities it drives. Specific requirements for fuzzing, penetration testing, evidence formality, or independent verification should be traced to the customer, certification provider, organizational method, or other governing scheme that actually imposes them.
Proof Point 3: The Cybersecurity Interface Agreement
Beyond proving organizational capability and product-specific risk assessment, a supplier has to prove that cybersecurity responsibilities across the supply chain are explicitly, formally defined, not simply assumed to be understood between the parties involved based on informal conversation, a long-standing commercial relationship, or shared industry convention.
What the Interface Agreement Actually Covers
The Cybersecurity Interface Agreement, formally the single work product associated with Clause 7, is the mechanism that documents cybersecurity requirements, responsibilities, deliverables, and underlying assumptions across an organizational boundary, typically between an OEM and a Tier 1 supplier, or between a Tier 1 and its own Tier 2 sub-suppliers. It clarifies exactly how cybersecurity will be achieved across that boundary, including which party owns vulnerability management responsibility after the product ships and which party owns incident response if something goes wrong in the field.
Why This Specific Work Product Is Repeatedly Flagged as a Weak Point
Despite being a single, formally defined work product, the Interface Agreement is consistently cited across supplier audits as one of the more fragile elements in an otherwise well-constructed cybersecurity case. The reason tends to be structural rather than technical: a Tier 1 supplier sits on both sides of this relationship simultaneously, acting as a supplier receiving requirements from the OEM above them while also acting as a customer issuing requirements to their own Tier 2 and Tier 3 sub-suppliers below. When responsibilities aren’t explicitly and consistently documented across every one of these handoffs, gaps emerge exactly where accountability is hardest to reconstruct after the fact, typically discovered only when an incident occurs and multiple parties each assume the other was responsible for a specific control.
The Tier Structure This Obligation Flows Through
Tier 1 suppliers handle components in direct contact with the OEM: driver-assistance system modules, airbag control units, steering wheel modules, and similarly complex integrated systems. Tier 2 and Tier 3 suppliers, further removed from direct OEM contact, still carry the same underlying obligation whenever their component touches a cybersecurity-relevant function, because the requirement flows through every tier that contributes to vehicle E/E system cybersecurity, not just the tier with a direct commercial relationship to the vehicle manufacturer.
The 7 Work Products Often Prioritized for Audit Preparation
ISO/SAE 21434’s Annex A identifies work products across applicable clauses, and the required set depends on those clauses and justified tailoring. The 7 items below are a practical preparation shortlist covering important evidence areas, but ISO/SAE 21434 does not declare this subset uniquely mandatory above other applicable work products.
A practical 7-item preparation shortlist:
- Cybersecurity policy (WP-05-01), establishing the organizational foundation everything downstream depends on
- Organizational audit report (WP-05-05), demonstrating the organization has actually assessed its own CSMS rather than simply documenting one on paper
- Cybersecurity plan (WP-06-01), translating organizational policy into project-specific, actionable activities
- Assessment report (WP-06-03), the documented output of project-level cybersecurity assessment activity
- Release recommendation (WP-06-04), the formal cybersecurity-specific release gate distinct from functional quality sign-off
- TARA (WP-09-02), the consolidated risk assessment output tying the 8 Clause 15 work products into the project’s overall cybersecurity case
- Validation report (WP-11-01), confirming the implemented product actually meets its defined cybersecurity goals under test
These 7 work products can provide a useful starting point for organizing an audit evidence pack, but they are a practitioner prioritization rather than a normative shortcut. Suppliers should still identify every work product required by the clauses, tailoring decisions, customer requirements, and audit scheme that apply to the actual programme before judging the evidence set complete.
Hardware-Level Proof: What Clause 10 Actually Requires
Clause 10 addresses cybersecurity engineering during product development, including requirements, design, implementation, integration, and verification activities derived from identified risks. It does not universally mandate particular hardware technologies. Controls such as tamper detection, hardware security modules, secure elements, secure boot, or protected key storage may be appropriate when the TARA and resulting cybersecurity requirements justify them, but the selected control should follow the product’s risk treatment and design context.
Examples of risk-derived hardware controls under Clause 10:
- Tamper detection may be selected when the risk assessment and cybersecurity requirements identify unauthorized physical access or manipulation as a threat that needs a hardware-level response
- Hardware-backed cryptographic key storage may be selected when the required protection of keys, credentials, or security functions justifies an HSM, secure element, or comparable implementation
ISO/SAE 21434 requires the product-development process to implement and verify cybersecurity requirements without prescribing a universal technology stack. SAE J3101 can provide additional guidance for hardware-anchored security when that guidance is relevant to the chosen architecture, customer expectations, or assurance approach, but suppliers do not automatically need to demonstrate compliance with both standards simply because Clause 10 applies.
Where Suppliers Most Commonly Fail Audits
Understanding the formal work product structure only tells part of the story. The practical, recurring failure patterns experienced assessors report reveal where the real gap between paper compliance and genuinely audit-ready compliance tends to sit, year after year, across very different suppliers, product categories, and programme sizes.
The implementation gap is the single most common failure point. It’s rarely the TARA analysis itself that fails scrutiny. It’s demonstrating that a documented risk treatment decision was actually built into the delivered software or hardware, and that this implementation was verified through testing rather than simply asserted in a document that was never checked against the shipped product.
Static traceability matrices can’t keep pace with evolving requirements. When OEM and supplier teams work at different levels of analytical detail, which happens routinely across complex, multi-tier supply chains, their respective outputs don’t line up cleanly, and a traceability matrix built once and left unmaintained quickly diverges from the product’s actual current state, which is precisely why live, continuously updated traceability has become the practical baseline expectation in regulated programmes rather than a nice-to-have enhancement.
Evidence goes stale faster than most teams expect. Vehicles remain on the road for 10 years or longer, while the threat landscape a TARA assessed at launch continues to evolve throughout that entire period. When a new CVE appears in an installed component, the organization has to assess whether it changes an original risk decision, since an attack path that was rated infeasible at launch can become genuinely exploitable years later as attacker tooling and techniques mature.
Post-production monitoring depends on telemetry designed in from the start. Retrofitting the ability to monitor a fielded component’s cybersecurity status after the fact is rarely practical, which means the decision about what post-production visibility a component needs has to happen during design, not after a vulnerability has already been discovered in the field with no mechanism in place to assess its real-world exposure.
Commercial off-the-shelf and open-source components create documentation gaps. These components frequently weren’t originally developed under ISO/SAE 21434’s framework at all, and the standard includes special provisions specifically addressing how a supplier proves adequate cybersecurity assurance for a component it didn’t build from scratch, typically requiring supplementary analysis and testing to fill the gap left by the component’s original development process.
What Happens After Production: The Obligations That Don’t End at Launch
A supplier’s proof obligations under ISO/SAE 21434 don’t conclude when a product ships. Two specific post-production activities distinguish automotive cybersecurity from more conventional product security practices, and both require ongoing, demonstrable effort rather than a one-time compliance exercise that gets closed out at launch and never revisited again.
Vulnerability Management as a Continuing, Not One-Time, Activity
Clause 8 establishes continual cybersecurity activities that run throughout a product’s lifecycle, including monitoring and assessment of newly disclosed vulnerabilities in relevant components, whether developed in-house or sourced from a third party. The standard does not set a universal quarterly supplier-reporting cadence. Reporting frequency should follow the OEM contract, Cybersecurity Interface Agreement, customer process, or other applicable requirement, while the underlying monitoring and reassessment continue for as long as the lifecycle obligation applies.
Incident Response Within a Reasonable Timeframe
Alongside ongoing vulnerability monitoring, suppliers have to prove they can detect and respond to actual cybersecurity incidents within a reasonable period, a requirement that presumes the organization has a functioning incident response process in place before an incident occurs, rather than improvising one reactively after the fact. This obligation connects directly back to the Cybersecurity Interface Agreement, since incident response across a multi-tier supply chain only works if every party’s specific responsibility was defined clearly in advance.
End-of-Life Considerations Still Carry Cybersecurity Weight
Organizations must inform customers, and in some cases end users, about the end of cybersecurity support for a given component according to a defined plan, since continued use of an unsupported component after support ends carries the same category of risk as running an obsolete, no-longer-patched operating system. Decommissioning itself typically sits outside an organization’s direct control, but the cybersecurity assets embedded in a component still require protection even after a vehicle is scrapped, since electronic control units are sometimes removed and resold following an accident, carrying whatever cybersecurity assets and vulnerabilities they held at the point of removal.
How This Connects to Other Automotive Standards Suppliers Already Know
ISO/SAE 21434 doesn’t operate in isolation from the rest of an automotive supplier’s compliance obligations, and understanding these connections helps explain why cybersecurity evidence increasingly gets requested alongside, rather than separately from, requirements suppliers are already accustomed to satisfying through their existing quality, safety, and information security programmes.
The Relationship With Functional Safety Under ISO 26262
ISO 26262 addresses functional safety, protecting people from harm caused by malfunctioning electrical and electronic systems, while ISO/SAE 21434 addresses intentional, malicious cybersecurity threats to those same systems. The 2 standards are complementary rather than competing, and in practice they frequently need to be applied together, since a cybersecurity threat identified through a TARA can create a genuine safety consequence that falls squarely within ISO 26262’s scope. A compromised braking control module, for example, is simultaneously a cybersecurity finding and a functional safety hazard, and a supplier’s evidence needs to demonstrate that both analytical frameworks were applied consistently to the same underlying component rather than treated as entirely separate compliance exercises running in parallel with no coordination between them.
The Emerging Connection to the Cyber Resilience Act
The EU Cyber Resilience Act excludes products with digital elements that fall under Regulation (EU) 2019/2144, which covers the relevant motor-vehicle type-approval regime. That exclusion should be checked before assuming a vehicle component has separate CRA obligations. Some supplier products or software can still fall within CRA scope when they are independently placed on the market and are not covered by that automotive exclusion or another sector-specific regime. In those cases, existing ISO/SAE 21434 risk and vulnerability evidence may still be useful, but a separate CRA scope and requirements analysis is necessary.
Why VDA ISA and TISAX Increasingly Appear Alongside Cybersecurity Requirements
Many OEMs formalize their cybersecurity expectations through the VDA Information Security Assessment questionnaire or through direct annex requirements embedded in a statement of work, often the same mechanism already used to assess broader information security maturity through TISAX. A supplier already navigating these established automotive industry assessment frameworks will find substantial overlap with what ISO/SAE 21434 compliance requires, which means organizations treating cybersecurity engineering evidence and broader information security assessment as one coordinated effort, rather than 2 disconnected compliance programmes, generally find the combined burden considerably lighter than pursuing each in isolation.
Organizational V-CSMS Audits and Provider-Specific Product Assessments
ISO/SAE 21434 does not define 2 standardized certification routes. Suppliers may encounter organizational schemes, such as ENX Vehicle Cyber Security, that assess company cybersecurity management capability, and provider-specific product assessments for individual items. The scope, test methods, evidence expectations, and outputs for product services vary by certification provider and customer requirement rather than following one universal ISO/SAE 21434 product-certificate path.
| Route | What it assesses | Assessment method | Output |
| Provider-specific product assessment or certification | The cybersecurity of one specific item, product, or component | Methods vary by provider and customer scope; testing may include technical evaluation, penetration testing, fuzzing, or other agreed activities | A provider-specific report, recommendation, or certificate with scope defined by that provider |
| Organizational V-CSMS audit scheme | The company’s cybersecurity management system and engineering processes | External audit against the chosen scheme’s organizational criteria and evidence requirements | Third-party confirmation of organizational V-CSMS capability within the selected scheme’s scope |
Independent organizational schemes such as ENX’s Vehicle Cyber Security audit can provide OEMs with third-party evidence of supplier V-CSMS capability against published criteria. Product-level assessments differ: providers may issue reports, recommendations, or certificates according to their own scope and methods. Any penetration testing, fuzzing, CAL use, or independence requirement should therefore be traced to the specific assessment scheme, provider, OEM contract, or customer specification rather than presented as a universal ISO/SAE 21434 certification rule.
FAQs
Is ISO/SAE 21434 certification legally required for automotive suppliers? ISO/SAE 21434 itself is a voluntary technical standard, not a direct legal requirement. UN Regulation No. 155 is legally applied according to the jurisdiction implementing it and governs vehicle cybersecurity type approval where adopted. ISO/SAE 21434 is widely used by OEMs and approval authorities as an engineering framework that can support R155 evidence, but it is not the only legally accepted route stated by R155. Suppliers should follow the applicable jurisdiction, OEM contract, and assessment scheme when determining what evidence is required.
What’s the difference between a CSMS and a TARA?
A Cybersecurity Management System operates at the organizational level, covering policies, roles, and processes across the entire company and every product it develops. A Threat Analysis and Risk Assessment operates at the product level, applying that organizational framework to identify and address specific risks for a particular item or component. A supplier needs both: a credible CSMS proves the organization is capable of doing cybersecurity engineering consistently, while a specific TARA proves that capability was actually applied to the product an OEM is evaluating.
How is a Cybersecurity Assurance Level actually assigned to a component? CAL is an optional assurance-classification approach described in informative Annex E. It can be associated with cybersecurity goals to communicate expected assurance rigor, but ISO/SAE 21434 does not require a CAL for every asset or component, and CAL cannot be calculated directly from the TARA risk value. When an organization, OEM, or assessment scheme uses CAL, it should define how the chosen level maps to assurance activities and evidence expectations under that specific method.
Do open-source and commercial off-the-shelf components need to meet the same requirements as custom-developed ones?
They need to meet an equivalent level of cybersecurity assurance, but the path to demonstrating that assurance differs. Since these components typically weren’t originally developed under ISO/SAE 21434’s framework, the standard includes specific provisions for supplementary analysis, testing, and documentation that fills the evidence gap left by the component’s original development process, rather than assuming the component is automatically non-compliant or automatically exempt from scrutiny.
How long does a typical supplier need to prepare before a CSMS audit? Preparation time depends on the existing V-CSMS maturity, product and organizational scope, supplier complexity, evidence gaps, and the audit scheme being used. A supplier with established processes may need several months to organize evidence and close targeted gaps, while an organization building core policies, roles, assessments, interfaces, and records from a limited starting point may need substantially longer. Audit planning should therefore begin with a gap assessment against the specific scheme rather than a universal 90-day readiness benchmark.
What happens if a vulnerability is discovered in a component years after it shipped? The supplier’s obligation doesn’t end at shipment. Clause 8’s continual cybersecurity activities require ongoing vulnerability monitoring throughout the product’s operational lifecycle, and when a new vulnerability is identified, the organization has to reassess whether it changes an original risk decision made in the TARA, since an attack path considered infeasible at the time of original assessment can become genuinely exploitable as attacker capability evolves. Supplier reporting cadence should follow the applicable OEM, contract, or interface agreement rather than a universal quarterly requirement.
Can a Tier 2 or Tier 3 supplier be held responsible for cybersecurity gaps even without a direct relationship to the OEM?
Yes, in practice if not always in direct contractual terms. The obligation flows through every tier that touches a cybersecurity-relevant component, and Cybersecurity Interface Agreements are specifically designed to document responsibility across each handoff in the chain, whether that’s OEM to Tier 1, or Tier 1 to Tier 2. A gap at any point in this chain becomes visible during an OEM’s own type-approval process, and the OEM has strong commercial incentive to push cybersecurity requirements down through its entire supply base rather than absorbing gaps discovered late in the process.