Skip to content

Automotive Cybersecurity — ISO/SAE 21434, UN-R 155, ECU and In-Vehicle Network Testing

Threat-model-led automotive cybersecurity engagement — TARA execution, ECU and in-vehicle network testing, CSMS readiness for UN-R 155 type approval

By Tatiana K.

The 2024 effective date of UN-R 155 in many regulatory regimes moved automotive cybersecurity from a recommended engineering practice into a vehicle type-approval prerequisite. The standard implementation path — ISO/SAE 21434 — defines cybersecurity engineering across the full vehicle lifecycle. The work is structural, multi-year, and shaped by the OEM-Tier-1 cybersecurity-interface boundary.

Melina supports OEMs and Tier-1 suppliers across CSMS readiness, TARA execution, in-vehicle network and ECU testing, and cybersecurity-case documentation.

What this service covers

CSMS readiness and gap assessment

UN-R 155 requires a documented Cybersecurity Management System addressing concept, development, production, operations, and decommissioning. ISO/SAE 21434 is the de-facto implementation standard.

Engagement scope:

  • CSMS process design assessment against ISO/SAE 21434 clause structure
  • Gap remediation alongside the OEM or Tier-1 engineering team
  • Cybersecurity-interface agreement design between OEM and Tier-1 suppliers
  • Pre-audit gap remediation before formal type-approval audit

TARA execution

TARA (Threat Analysis & Risk Assessment) is the central risk-analysis artifact in ISO/SAE 21434. We execute TARA on items ranging from individual ECU classes to vehicle E/E architectures, working alongside the engineering team.

A common engagement frame: OEM concept-phase TARA and supplier item-definition-phase TARA need reconciliation at the cybersecurity-interface boundary. We run that as a structured workshop output, with documented decisions traceable back into both organizations.

ECU and in-vehicle network testing

Hands-on testing on physical hardware:

  • CAN bus and CAN-FD message analysis, replay, and injection
  • DoIP (Diagnostics over IP) and UDS authentication, programming session, security access analysis
  • OBD-II attack-surface assessment, including connected dongle exposure
  • ECU firmware extraction, reverse engineering, vulnerability research
  • Gateway behavior between in-vehicle network zones (central gateway, zonal architecture)
  • Telematics Control Unit (TCU) end-to-end — cellular path, OTA channel, back-end API
  • Infotainment head unit (IVI) attack surface — BLE, Wi-Fi, USB, side-loaded apps, Android Automotive components

Cybersecurity case documentation

The cybersecurity case is the per-project evidence package demonstrating cybersecurity goals were met. We support cybersecurity-case preparation as a deliverable, including traceability between TARA risk treatments, design decisions, verification artifacts, and validation outcomes.

Continuous cybersecurity activities

ISO/SAE 21434 mandates continuous cybersecurity activities — monitoring, incident response, vulnerability management — across the post-SOP (Start of Production) lifecycle. We support continuous cybersecurity activity design and operate alongside the OEM or supplier’s PSIRT function under Retainer framing.

Methodology

Each automotive engagement follows our six-stage methodology: Discovery, Scoping, Threat Modeling (where TARA replaces the generic threat-modeling step), Testing, Reporting, and 60-day Re-check. For automotive engagements, the re-check phase typically aligns with the OEM’s next milestone gate rather than a fixed 60-day cadence.

What this service does not include

  • Issuance of the formal type-approval cybersecurity assessment for UN-R 155 — performed by accredited Technical Services designated by the type-approval authority
  • ISO/SAE 21434 certification audit — issued by accredited certification body
  • Functional-safety engineering proper (ISO 26262) — we support cybersecurity work that interfaces with functional safety, but functional-safety engineering is a separate discipline with separate engagement-team expertise

Compliance and standards we work within

  • ISO/SAE 21434:2021 (cybersecurity engineering of road vehicles)
  • UN-R 155 (vehicle type-approval cybersecurity) and UN-R 156 (SUMS)
  • ISO/PAS 5112 (CSMS audit guidance)
  • ISO 21177 (ITS station security services)
  • ISO 26262 alignment for safety-relevant cybersecurity work
  • China-market: GB/T 44464 (passenger vehicle cybersecurity), MLPS for connected services, automotive Important Data under DSL

Engagement model

ScopeEngagement model
Single ECU class testingScoped Assessment
TARA execution for single itemScoped Assessment
CSMS readiness end-to-endCustom Engagement
Multi-program continuous engagementRetainer

“TARA quality is the single most leveraged artifact in an automotive cybersecurity program. A well-executed TARA propagates correctly into the cybersecurity case and the verification activities; a TARA with the recurring anti-patterns inherits the drift downstream, where it surfaces at type-approval audit. We publish the Seven Anti-Patterns catalog and Four-Question Review Protocol as the internal-review tool that catches most of these patterns before external assessment.” — Tatiana K., CEO, Melina Security

What buyers ask us first

Three questions surface in nearly every initial discovery call with an OEM or Tier-1 supplier:

“How do we reconcile our TARA with our supplier (or OEM) TARA at the cybersecurity-interface boundary?” Through a structured reconciliation workshop with both teams’ cybersecurity engineering representatives. The workshop output is a documented cybersecurity-interface agreement that defines responsibility allocation, evidence exchange, and escalation paths. Most reconciliation friction surfaces as anti-pattern 3.5 (OEM-Tier-1 impact-rating discrepancy) in our TARA Quality catalog.

“Can pre-launch TARA work proceed before final architecture freeze?” Yes — and usually should. Sequential “freeze architecture, then TARA” produces TARA work that lags design decisions and forces retroactive evidence reconstruction. Parallel TARA work integrates risk analysis into the engineering rhythm, which produces cleaner work product and a much shorter pre-audit remediation cycle.

“How does Chinese-market type approval coordinate with UN-R 155 readiness?” GB/T 44464 and related GB-series standards share structural patterns with ISO/SAE 21434, so most technical analysis is reusable across both regulatory tracks. The two regulatory submissions are distinct, but the underlying engineering work — TARA, ECU testing, cybersecurity-case evidence — is largely shared. We typically scope dual-market readiness as parallel tracks against one cohesive technical work product.

Frequently asked questions

Can you sign off as the third-party assessor for UN-R 155 type approval?

No. UN-R 155 type-approval assessment is performed by accredited Technical Services designated by the type-approval authority. We provide assessment and engineering support that becomes input to the OEM’s submission, not the type-approval decision itself.

Do you work in Chinese-market automotive cybersecurity?

Yes. Chinese-market vehicles operate under GB/T 44464 and related GB-series standards that share structural patterns with ISO/SAE 21434 but include China-specific elements (MLPS classification for connected services, automotive Important Data classification under DSL). Our China-market work supports OEMs and suppliers operating in or selling into mainland China.

How does ECU testing relate to TARA?

TARA outputs drive the ECU testing scope — the threat scenarios identified during TARA define what gets tested, at what depth. ECU testing without TARA-driven scope often becomes a generic vulnerability hunt that misses the threat-model-relevant findings.

Can you work with our existing TARA before completing your own?

Yes. A common engagement frame is TARA review and gap remediation rather than fresh TARA execution. We review the existing TARA against ISO/SAE 21434 requirements, identify where it under-covers or over-covers the actual threat landscape, and provide guidance to bring it to the engagement-ready quality bar.

What’s the typical engagement length for CSMS readiness?

For a Tier-1 supplier with established quality processes and one product line: 6-10 weeks for gap assessment and 3-6 months for full remediation alongside the supplier’s engineering team. For an OEM building CSMS from a low maturity baseline, multi-quarter and structured as retainer rather than fixed assessment.