Automotive Cybersecurity · ISO/SAE 21434 · UNECE R155

Automotive Cybersecurity Engineering from Architecture to Assessment Readiness.

Agnile supports cybersecurity engineering for connected vehicles, embedded products, IoT systems, and software platforms — with deep specialisation in automotive cybersecurity across ISO/SAE 21434, UNECE R155/R156, TARA, CSMS, secure architecture, implementation support, and validation.

Schedule a 60-minute callContact Us
Engineer CredentialsISO/SAE 21434 aligned

What is automotive cybersecurity engineering?

Automotive cybersecurity engineering is the ISO/SAE 21434 discipline of identifying, treating and verifying cybersecurity risk in a vehicle’s electronic systems across the lifecycle, from concept to decommissioning. Agnile Technologies delivers it for OEMs and Tier-1 suppliers in Germany, Europe and India: item definition and TARA, cybersecurity goals and concepts, secure boot, HSM and SecOC implementation, verification and penetration testing, and the cybersecurity case that technical services read for UNECE R155 type approval and that supports AIS 189 readiness.

The work protects vehicle functions, ECUs, networks, software, diagnostics, update paths, and connected services. It includes ISO/SAE 21434 work products, TARA, threat scenarios, attack path analysis, cybersecurity goals, controls, cybersecurity case evidence, UNECE R155/R156 readiness, AIS 189 / AIS 190 readiness, vulnerability monitoring, and supplier interface evidence.

Reviewed by Shreyansh, Founder & CTO, Agnile Technologies •

Capability areas

Where Our Cybersecurity Engineering Shows Up

Cybersecurity Process & Governance

ISO/SAE 21434 process deployment, cybersecurity planning, distributed cybersecurity activities, cybersecurity interface agreements, CSMS support, and UNECE R155/R156 evidence alignment.

TARA & Risk Engineering

Asset identification, damage scenarios, threat scenarios, attack paths, impact assessment, attack feasibility, risk determination, and risk treatment planning.

Secure Architecture & Implementation

Secure boot, secure flashing, secure diagnostics, HSM integration, AUTOSAR Crypto Stack, SecOC, key management, OTA security, and cybersecurity controls.

Cybersecurity Validation

Security test planning, penetration testing, fuzz testing, vulnerability analysis, defensive coding review, and validation evidence for automotive ECUs and networks.

Need a standalone assessment rather than a programme? See our Automotive Penetration Testing services — ECU, in-vehicle network, telematics and backend testing with findings written for ISO/SAE 21434 and UNECE R155 evidence, delivered in India and Germany and Europe.

Process

How an Automotive Cybersecurity Engagement Runs — Six Steps

The same six steps follow the ISO/SAE 21434 lifecycle on every programme, whether you need the whole chain or one link of it. Durations are typical for one item; your development plan and the assessment date set the actual schedule.

  1. Scoping and gap analysis Weeks 1–3

    Agree the items in scope, the lifecycle phase and the assessment the evidence is for. Review existing processes and work products against ISO/SAE 21434 and UNECE R155, and agree data-exchange rules with your security team — including TISAX rules where your programme applies them — under a mutual NDA.

  2. Item definition and TARA 4–8 weeks per item

    Item definition and cybersecurity goals per Clause 9; assets, damage and threat scenarios, attack paths, attack feasibility and risk determination per Clause 15, with the UNECE R155 Annex 5 threats considered. Facilitated workshops typically run two to five days per system, and the TARA report carries traceability to goals and requirements.

  3. Cybersecurity concept and secure design Paced to your development plan

    Cybersecurity concept and requirements allocated to the architecture, then design and implementation support per Clause 10 — secure boot and secure flashing, HSM and AUTOSAR Crypto Stack integration, SecOC, secure diagnostics and OTA security — with Cybersecurity Interface Agreements (Clause 7) defining what each supplier delivers.

  4. Verification and validation 4–10 weeks per ECU for a penetration test

    Verification per Clause 10 — requirements-based testing, vulnerability analysis, fuzz and penetration testing — and validation of the cybersecurity goals at vehicle level per Clause 11, producing the testing evidence UNECE R155 paragraph 7.3.6 expects.

  5. Cybersecurity case and assessment readiness 2–3 weeks before the assessment

    The cybersecurity case — the structured argument, supported by work products, for the cybersecurity achieved (Clause 6). We pressure-test it the way a cybersecurity assessor or technical service will, close the gaps and prepare your team for the review. The approval decision stays with the authority.

  6. Post-development monitoring and vulnerability management Continuous from start of production

    Cybersecurity monitoring, event evaluation, vulnerability analysis and vulnerability management per Clause 8, incident response and updates per Clause 13, and software-update governance under UNECE R156 — so the evidence stays current after approval.

Evidence

What Each Work Product Proves — and Who Reads It

Every engagement produces work products, not slideware. The table maps each one to the ISO/SAE 21434 clause it satisfies, the UNECE R155 paragraph it supports, and the reader it is written for. The same structure serves AIS 189 review in India. See the ISO/SAE 21434 work products checklist for the full list.

Work productISO/SAE 21434UNECE R155Who reads it
Cybersecurity planClause 6Para 7.2 — the CSMS processes the project appliesYour project cybersecurity manager; the OEM under the Interface Agreement; the cybersecurity assessor
Cybersecurity Interface AgreementClause 7Para 7.3.2 — supplier-related risksOEM and supplier cybersecurity leads; purchasing
Item definition and TARA reportClauses 9 and 15Para 7.3.3 — risk assessment, considering Annex 5 Part AThe OEM cybersecurity team; the technical service
Cybersecurity goals, claims and conceptClause 9Para 7.3.4 — mitigations, with Annex 5 Parts B and CSystem architects; suppliers via the Interface Agreement; the technical service
Cybersecurity specifications and integration evidenceClause 10Para 7.3.4 — the mitigations as implementedDevelopment and integration teams; the cybersecurity assessor
Verification reports, including penetration and fuzz testingClause 10Para 7.3.6 — appropriate and sufficient testingThe technical service — for example TÜV SÜD, TÜV Rheinland or UTAC; your release board
Validation reportClause 11Para 7.3.6 — effectiveness of the security measuresThe technical service; the OEM's vehicle release
Cybersecurity case and cybersecurity assessment reportClause 6Vehicle-type evidence for approval (para 7.3)The cybersecurity assessor; the technical service reporting to an approval authority such as KBA or RDW
Vulnerability management records and incident response planClauses 8 and 13Para 7.2 — CSMS monitoring, detection and response processesYour product security incident response team; the CSMS assessment

R155 paragraph references are to the vehicle-type requirements (7.3) and the CSMS requirements (7.2). Annex 5 lists threat examples the risk assessment must consider, with mitigations in Parts B and C — it is not a list of mandatory tests.

Germany and Europe

Automotive Cybersecurity in Germany and Europe: KBA, TISAX, NIS2 and the 2027 L-Category Extension

UNECE R155 has applied to every new car, van, truck and bus registered in the EU since 7 July 2024, and German programmes add contractual and enterprise obligations on top. Agnile writes the engineering evidence once, in the structure each reader expects.

  • KBA's technical services read ISO/SAE 21434 evidence. In Germany the Kraftfahrt-Bundesamt (KBA) grants R155 and R156 approvals on the basis of assessments by the technical services it has designated for cybersecurity — TÜV SÜD (designated June 2021), TÜV Rheinland and GTÜ's Ateel among them. The Netherlands' approval authority is RDW, and in France UTAC acts as a technical service. R155 is outcome-based and does not name ISO/SAE 21434, but technical services expect the engineering behind the evidence to follow it, so we write every work product in its clause structure.
  • TISAX-governed data exchange. German OEMs and many Tier-1s apply TISAX rules before sharing sensitive development data. Where your programme applies TISAX rules, we agree the exchange with your security team — mechanism, handling boundaries, who sees which artefact — before any architecture, TARA or firmware data moves. Our own operations run under ISO/IEC 27001:2022 (Certificate No. 25110402).
  • NIS2UmsuCG is a separate, enterprise obligation. Germany's NIS2 implementation act has been in force since 6 December 2025. Its duties sit with the company — its own networks, production systems and supply chain — and medium-sized and larger motor-vehicle and parts manufacturers typically fall in scope as important entities. A CSMS and an ISO/SAE 21434 process can share governance, incident handling and supplier management with an NIS2 programme, but neither substitutes for the other.
  • R155 reaches two- and three-wheelers in 2027. Delegated Regulation (EU) 2025/1455 extends R155 to L-category vehicles in the EU: new types from 11 December 2027, existing types from 11 June 2029. Two- and three-wheeler OEMs and their suppliers face the CSMS, TARA and verification expectations passenger-car programmes met from 2022.

Testing for a German or European programme is covered on automotive penetration testing in Germany and Europe; the process side — CSMS, TARA method, Interface Agreements — on ISO/SAE 21434 consulting. For supplier duties under Germany’s NIS2 law, read NIS2 for automotive suppliers, and for how R155, R156, ISO/SAE 21434, the CRA, NIS2 and TISAX fit together, the automotive cybersecurity regulations map.

Primary sources: Regulation (EU) 2019/2144, Delegated Regulation (EU) 2025/1455. Agnile is an independent engineering provider: we produce the evidence; the approval authority decides. We do not provide legal advice.

India · Cybersecurity readiness

AIS 189 / AIS 190 Readiness

Support for Indian automotive cybersecurity and software-update evidence, including CSMS, SUMS, TARA, vulnerability monitoring, cybersecurity case preparation, software-update traceability, and evidence preparation for AIS 189 and AIS 190 review by ARAI / iCAT.

Final review, correction, approval, and submission remain with the customer engineering team and the relevant approval authority. See the AIS 189 / AIS 190 guide for status, scope, and roadmap detail.

Related compliance workflows

How Automotive Cybersecurity Engineering Maps to Regulations

The engineering work above produces the evidence chain that supports ISO/SAE 21434, UNECE R155 / R156, and AIS 189 / 190 readiness. Each compliance page shows what teams need to produce, where they typically struggle, and how Agnile helps.

Common scopes

Common Engagement Scopes

  • ISO/SAE 21434 work-product support
  • TARA facilitation and review
  • CSMS process support
  • Cybersecurity interface agreement support
  • Secure boot / secure flashing / diagnostics hardening
  • HSM and Crypto Stack integration
  • Cybersecurity validation and penetration testing support
  • UNECE R155/R156 evidence preparation support

Engagement models

How We Engage on Cybersecurity Programmes

Three engagement shapes cover where most cybersecurity programmes need support — CSMS process and evidence preparation, focused TARA on a vehicle programme, or independent methodology and evidence review. We scope the actual work based on the system, maturity, and assessment expectations.

  • ENG-01·12–14 weeks

    Gap-to-CSMS Programme

    ISO/SAE 21434 CSMS process support and evidence preparation across relevant lifecycle activities. We perform gap analysis against current processes, support CSMS structure and rollout, run a reference TARA on a representative vehicle programme, and prepare evidence for customer or third-party assessment. Outcome: a CSMS evidence package structured for assessment readiness.

    Engagement flow

    Gap Analysis
    3w
    Process Design
    3w
    Reference TARA
    5w
    Audit Prep
    3w

    Deliverables

    • CSMS process suite
    • Reference TARA report
    • Evidence pack structured for audit review
  • ENG-02·4–8 weeks per system

    TARA on Demand

    Engineering team augmentation for a specific TARA cycle on one or more vehicle systems. We facilitate workshops, draft Damage and Threat Scenarios, run Attack Feasibility Rating per Annex G, and deliver the complete TARA Report with bidirectional traceability — ready for programme or auditor review.

    Engagement flow

    Item Definition
    Asset & Damage
    Threat & Attack
    Risk Treatment

    Deliverables

    • Full TARA Report
    • Attack Path library
    • Cybersecurity Goals draft
  • ENG-03·2 weeks

    Cybersecurity Concept Review

    Independent review of an existing CSMS, TARA, or work product set. We pressure-test methodology, traceability, and evidence readiness — useful before a customer, assessor, or third-party review. Outcome: a written assessment with prioritised gaps and a remediation list.

    Engagement flow

    Document Review
    1w
    Workshop & Q&A
    0.5w
    Assessment Write-up
    0.5w

    Deliverables

    • Independent assessment
    • Prioritised gap list
    • Remediation plan

Practicalities

Engagement Practicalities

The questions procurement, legal and programme managers ask before the scoping call, answered up front.

Delivery modelRemote-first from Bengaluru, with on-site workshops and reviews at your facility in Germany, elsewhere in Europe or in India; European visits planned four to six weeks ahead
Working windowIndia is 4.5 hours ahead of CET and 3.5 hours ahead of CEST, so every European morning is a shared working window
Data handlingOperations under Agnile's ISO/IEC 27001:2022 information-security management system (Certificate No. 25110402); where your programme applies TISAX rules, we agree the exchange with your security team before any data moves
ToolingYour templates and tools
ContractingAgnile Technologies Private Limited; mutual NDA before scoping; governing law and currency agreed per contract
LanguageDeliverables, workshops and reviews in English
Typical durationsGap analysis 2–4 weeks; TARA 4–8 weeks per item; gap-to-CSMS programme 12–14 weeks; organisation-wide process deployment 3–6 months; independent review about 2 weeks
Cost driversItems and ECUs in scope, maturity of existing work products, lifecycle phase, number of supplier interfaces, whether penetration testing is included, on-site days and the assessment date — fixed price after scoping
DeliverablesISO/SAE 21434 work products in your template — plan, TARA, goals and concept, verification and validation reports, cybersecurity case — mapped to UNECE R155 and AIS 189

Why Agnile

What We Do Differently

  • 01

    Engineer-held credentials with deep automotive cybersecurity domain expertise.

  • 02

    ISO 9001:2015 and ISO/IEC 27001:2022 certified.

  • 03

    Production-programme experience across ECUs, ADAS systems, and connected vehicle platforms.

  • 04

    One team for process deployment, product security work, and validation — not three vendors stitched together.

  • 05

    Curated automotive-specific threat database built from public standards, automotive threat catalogues, vulnerability sources, and engineering review patterns.

Standards, in practice

Standards we work to — and what each looks like in delivery

The standards every cybersecurity engagement touches, with the specific work products we deliver against each.

  • ISO/SAE 21434

    Cybersecurity Engineering for road vehicles

    We facilitate TARA workshops, draft Damage and Threat Scenarios, run Attack Feasibility Rating per Annex G, and produce the TARA Report with bidirectional traceability to Cybersecurity Goals and downstream Cybersecurity Requirements.

  • UNECE R155

    Cybersecurity Management System Evidence for Assessment Readiness

    We support CSMS process deployment against UNECE R155 expectations, prepare evidence packages for vehicle cybersecurity assessment, and provide written support during customer, assessor, or third-party review.

  • UNECE R156

    Software Update Management System (SUMS)

    We design SUMS processes covering RXSWIN management, OTA / SOTA / FOTA security, signature verification, and rollback governance — and integrate them with your existing release-management toolchain.

  • AIS 189 / AIS 190

    India-specific automotive cybersecurity norms

    We support engineering teams entering the Indian homologation regime — including AIS-189 (cybersecurity) and AIS-190 (SUMS) compliance, with engagement support for ARAI and iCAT review.

  • AUTOSAR SecOC

    Secure Onboard Communication

    We configure SecOC for selected PDUs across CAN, CAN-FD, FlexRay, and Automotive Ethernet — sizing freshness values, MAC algorithm selection (CMAC/AES-128 typical), and integration with the AUTOSAR Crypto Stack and underlying HSM.

  • EVITA

    Hardware Security Module profiles (Light / Medium / Full)

    We integrate HSM firmware on production silicon — secure boot, secure flashing, key provisioning, and asymmetric crypto for V2X / over-the-air channels — with EVITA-profile selection driven by your threat model.

How we engage — the TARA workflow

From Item Definition to Cybersecurity Assessment Readiness

Six stages, each with named ISO/SAE 21434 clauses and explicit evidence outputs. Scroll to see how assets, damage scenarios, threats, attack paths, risks, and treatment decisions remain traceable through the workflow.

  1. 01

    Item Definition

    Clause 9.3

    We facilitate the Item Definition workshop — capturing the cybersecurity-relevant boundary, operational environment, and assumptions. Outcome: a written Item Definition that downstream TARA, Cybersecurity Goals, and Concept all trace back to.

    → Item Definition (WP-09-01)

  2. 02

    Asset Identification

    Clause 15.3

    Assets derived from the architecture — ECUs, networks, software components, data flows. Each asset gets cybersecurity properties (Confidentiality, Integrity, Availability) and damage-potential estimates per Annex F.

    → Asset Register

  3. 03

    Damage Scenarios

    Clause 15.4

    Loss of cybersecurity properties translated into damage scenarios with SFOP impact ratings — Safety, Financial, Operational, Privacy. Aligned to Annex F rating tables; defensible at audit.

    → Damage Scenario Catalogue

  4. 04

    Threat Scenarios

    Clause 15.5

    STRIDE-classified threats matched to assets. Drawn from a curated automotive threat corpus (EMB3D, AutoISAC ATM, ASRG XSAM, NVD, GHSA) — with citation provenance back to the source disclosure.

    → Threat Scenario Catalogue

  5. 05

    Attack Path Analysis

    Clause 15.6–7

    Attack paths from external interfaces to assets. Attack feasibility rated per Annex G — elapsed time, expertise, knowledge, opportunity, equipment. Output: editable attack trees with quantified feasibility.

    → Attack Path Library

  6. 06

    Risk Treatment

    Clause 15.8–9

    Risk Determination per Annex H. Treatment decisions logged — accept, avoid, transfer, mitigate — with mitigation controls mapped to Cybersecurity Goals and downstream Cybersecurity Requirements.

    → TARA Report + Treatment Log

Case study

What This Looks Like in Practice

Anonymised by request. References available on qualified enquiry.

Anonymised engagement summary. Customer identity and programme details withheld under NDA. Metrics reflect internally documented delivery outcomes.

European powertrain programme · UNECE R155

ISO/SAE 21434 gap-to-CSMS in 14 weeks.

Context

A European engineering team was preparing for UNECE R155 type approval on a powertrain ECU programme. Their existing cybersecurity process was a mix of Word documents, Excel TARAs, and ad hoc threat modelling — defensible internally, but not survivable at audit. They had 14 weeks before the vehicle programme's Cybersecurity Interface Agreement (CIA) review.

Approach

Agnile ran a 3-week gap analysis against ISO/SAE 21434 Clauses 5–15, deployed a CSMS process suite tailored to their existing toolchain (DOORS for requirements, Polarion for testing), executed a reference TARA on the powertrain ECU under Annex F SFOP rating, and produced the evidence package across 18 work products, structured for audit review.

What we delivered

  • ISO/SAE 21434 process suite — Clauses 5, 6, 8, 9, 15
  • Reference TARA report — 24 ECUs, 47 assets, 183 threats
  • Cybersecurity Goals + CAL ratings for the item
  • CSMS readiness assessment for the CIA review
  • Cybersecurity Case structure (WP-06-04) populated

What the customer got

  • Passed CIA review on first submission
  • Process suite reused across 4 follow-on programmes
  • Engineering team upskilled — no further external dependency

ASIL D · 24 ECUs · 18 WPs · CIA passed

FAQ

Automotive Cybersecurity Engineering — Questions

Explore next

Plan the programme around your market

Germany and Europe delivery, the ISO/SAE 21434 guides behind the work products, and penetration testing.

Germany & Europe

Germany and Europe

ISO/SAE 21434

Penetration Testing

Request a Discussion

A 60-minute call: scope your gap analysis, score your existing TARA, or pressure-test your CSMS evidence package before an audit. We respond to qualified enquiries within one business day.