Automotive Cybersecurity: A Practical Guide to ISO 21434 Implementation

Every component integrated into your vehicle today is critical. They add smart features, connect you to the external world, enable communication and keep your car up and running.

However, it is important to note that none of these components operate in isolation. They function as part of a broader connectivity stack that links external ecosystems to in-vehicle networks. And securing this ecosystem goes far beyond hardening individual interfaces or devices.

This is where ISO 21434 comes into play. It states that automotive programmes must treat every vehicle component as a security-relevant asset, one that requires continuous monitoring, robust authentication, and lifecycle cybersecurity management. But, only with what must be achieved in place, it’s often difficult to map how those outcomes should be achieved in real architectures, interfaces, and trust boundaries.

This article brings those requirements into practical context with insights from our in-house expert. It connects ISO 21434’s intent to concrete design and implementation choices across the connectivity stack. supplier coordination and validation processes.

So, let’s answer the questions without further ado!

How Threat Modelling Works in an Automotive Connectivity Stack?

The connectivity stack is the primary attack surface in a vehicle, and securing it forms the baseline for the overall vehicle security posture.

Basically, an automotive connectivity stack is a collection of components through which a vehicle communicates with the outside world. For their threat modelling, automotive programs initially run a distinct Threat Analysis and Risk Assessment (TARA) for each component of the stack. This is because running a single assessment across the full stack as one block can produce analysis too broad to act on.

In the assessment, ISO 21434 treats each item as separate with its own asset profile, threat scenarios, and cybersecurity goals. The recommended approach for threat enumeration is STRIDE applied per interface element.

What is STRIDE?

STRIDE is an automotive threat modelling framework, which stands for six categories of classified threats.

For each interface, analysts work through each STRIDE category to ensure no threat type is missed. The output is then fed into the risk register, from which cybersecurity goals are derived, controls are specified, and supplier responsibilities are allocated.

To understand this better, let’s dive deeper into each item assessed in a logical sequence.

1. TCU (Telematics Control Unit)

The Telematics Control Unit is among the most exposed components in vehicles. Placed at the boundary between internal networks and the external environment.

It manages cellular communication, GPS, remote diagnostics, and OTA updates. In a TCU focused TARA, the key assets are the telematics data stream, the vehicle identity credentials, the cellular communication session, and the OBD-II bridge that links the telematics domain to the CAN bus.

What are the key assets, threats, and mitigations in a TCU assessment?



Applying STRIDE to the TCU’s interfaces highlights several high-impact threats, including remote code execution through the cellular stack, interception or manipulation of the vehicle to cloud channel, denial of service (DoS) attacks, and misuse of the OBD-II bridge to inject CAN messages. On the firmware side, both unsigned firmware injection and rollback to vulnerable versions remain credible attack paths.

Mitigations to these threats align with ISO 21434 Clause 10. Mutual TLS 1.3 with:

• HSM-protected client certificates secure the cloud channel and prevent impersonation.
• Segmentation between the telematics and powertrain domains limits the blast radius of any TCU compromise.
• Cryptographic verification of firmware, combined with strict anti-rollback rules, closes off the firmware attack vectors.
• Detection on the TCU’s network interfaces ties this component’s runtime behaviour to the postproduction monitoring obligations established in Clause 13.

While the TCU defines the vehicle’s external communication boundary, its operation depends on a secure cellular identity anchored deeper. That identity is established and maintained by the SIM or eSIM.

2. SIM / eSIM

The SIM or eSIM anchors a connected vehicle’s cellular identity and enables every wireless interaction with external networks. As this component authenticates the vehicle and maintains its connectivity, it becomes a high-value attack surface with threats spanning development-phase controls and post-production monitoring under ISO 21434.

What are the threats assessed and controls suggested in a SIM or eSIM assessment?

A SIM/eSIM TARA centres on four primary assets:

• the eSIM profile,
• the eUICC that stores it,
• the modem firmware handling cellular communication, and
• the vehicle’s connectivity identity, including the IMSI and network credentials.

An attacker who compromises any of these can impersonate the vehicle on the network, intercept its communications, or abuse its connectivity at the carrier level.

Threat	How it happens	Control
Profile theft / cloning	Malware extracts the eSIM profile, or the provisioning server is compromised.	Secure storage, TLS-protected provisioning, eUICC isolation
SIM swap	The attacker social engineers the mobile operator to reassign the vehicle’s ICCID.	Anomaly detection on connection patterns, profile lock
Baseband exploitation	Malformed radio signals or downgrade attacks target modem firmware.	Patch compliance, disable 2G fallback, AT command isolation
IMSI catcher	A rogue base station intercepts the vehicle’s network identity.	5G SUCI, 5G AKA authentication, radio anomaly detection
Fraudulent data use	Stolen ICCID reused to abuse the vehicle’s data plan	Billing anomaly detection, SIM lock

3. Bootloader

The bootloader is the first software that runs when an ECU powers on. It loads and verifies the application before handing over control.

The bootloader executes before any application-level security is active; a compromised bootloader undermines everything built above it.

What are the threats assessed and controls suggested in a bootloader assessment?

The core risk in the bootloader is often found to surface when no authentication mechanism exists, which may allow the attacker to load any software.

Threat	How it happens	Control
unauthorised firmware flashing	Debug port access or insecure recovery mode exploited	Secure boot, authenticated debug interfaces
Signing key compromise	OEM build pipeline or CI/CD system breached to produce malicious firmware	HSM key storage, key rotation policy
Downgrade attack	Older vulnerable firmware version flashed to reintroduce known weaknesses	Hardware rollback counters, rollback checks at boot
Fault injection	Hardware glitching used to bypass secure boot signature verification	Anti-tamper protections, secure boot ROM
Flash tampering	Direct SPI write attacks on flash storage	Flash encryption, memory protection units

How do ISO 21434, SAE J3101, and NIST 800-193 align on firmware security?

Generally, three standards act behind the security of the bootloader, each contributing to a distinct layer to secure the bootloader

• The ISO 21434 Clause 10 requires that firmware integrity be protected and that cryptographic keys reside in secure hardware.
• The SAE J3101 provides the hardware architecture to fulfil these expectations. It establishes a hardware-rooted chain of trust that begins in immutable OTP memory and verifies each boot stage before allowing execution.
• Moreover, NIST SP 800193 extends this foundation by adding firmware resilience requirements: detection of tampering, protection of critical components, and a defined recovery path when integrity is lost.

4. EV Charger Communications

EV charging introduces a communication interface that many TARA processes underestimate.

Before energy transfer begins, the vehicle and the charging point exchange identity, capabilities, and session parameters, making the interface a live attack surface, not just an electrical connection.

Why does this fall under the ISO 21434 scope? What are the threats assessed and controls suggested in an EV charger assessment?

As ISO 21434 covers every E/E communication boundary in a road vehicle, the charging communication stack falls fully within its scope. Any TARA that ignores this interface leaves a gap in the system-level threat picture.

When the vehicle presents its contract certificate, the charger presents its credentials, and mutual authentication must be established before data flows. A compromised or spoofed charging session can expose vehicle identity, enable fraudulent billing, or introduce malicious data through the communication channel.

Threat	How it happens	Control
Contract certificate theft	Certificate extracted from the vehicle ECU’s accessible memory	Store in hardware security element, not software.
Man-in-the-middle	Weak TLS configuration or inadequate certificate validation on the session	Mutual TLS authentication (both sides verify each other)
Message manipulation	Tampered EVSE messages alter charging parameters mid-session.	Message integrity checks, signed message exchanges
Fake charging station	A rogue charger presents a fraudulent certificate to impersonate legitimate infrastructure.	Pinned V2G trust roots
Energy theft	Backend tariff data manipulated to undercharge or misbill	Backend anomaly detection

5. Mobile applications

Before we even dive deeper into the threat modelling of mobile applications, the question often asked is:

Why does it fall under the scope for ISO 21434, and what does a TARA look like?

Well. ISO 21434 explicitly scopes in any software component that interacts with vehicle systems.

A companion mobile app that manages remote access, charging, or trip data communicates with the TCU through cloud APIs and can issue commands that influence vehicle behaviour.

In the TARA of mobile apps, the key assets include the following:

• Remote access tokens that authorise commands
• The user’s account and personal data
• The application to cloud API, and
• The push notification channel.

The major threats in these assets stem from insecure token storage, which allows an attacker to issue legitimate vehicle commands; API misuse through stolen credentials; malicious deep link invocation by third-party apps; and spoofed push notifications that mislead the driver about vehicle status.

Controls addressing these risks align with ISO 21434 Clause 10 for software interfaces. It demands the tokens to be short-lived and rotated on use, and certificate pinning should protect transport layer communication from interception. Rate limiting on command APIs restricts the impact of stolen credentials.

While OWASP MASVS is not part of ISO 21434, it provides the practical implementation guidance needed to translate Clause 10 requirements into concrete mobile engineering practices.

By now, you have seen how securing individual components across the connectivity stack is only part of the equation. Next comes in the supplier obligations.

Supplier Obligations under ISO 21434

ISO 21434 makes clear that cybersecurity is not the OEM’s burden alone.

Suppliers must create and maintain a defined set of work products at both the organizational and project level, and these artifacts must remain traceable, auditable, and ready for review during a Vehicle Cybersecurity (VCS) assessment.

What Work Products does ISO 21434 Require from Suppliers?

At the organizational level, suppliers must demonstrate a functioning Cybersecurity Management System (CSMS).

The CSMS governs how cybersecurity is applied across all projects, supported by documented policies, defined competence management processes, and a structured method for tracking cybersecurity incidents and vulnerabilities. It is the foundation that ensures each project inherits consistent, verifiable cybersecurity governance rather than isolated, ad hoc practices.

Once these responsibilities are defined, the next question is how those responsibilities are formally coordinated and enforced. This is where the role of Cybersecurity Interface Agreement comes into picture.

What is a Cybersecurity Interface Agreement (CIA)?

When an OEM sources a component from a Tier1 supplier, both parties carry cybersecurity responsibilities, but those responsibilities differ.

The Cybersecurity Interface Agreement defines the exact boundary between them and prevents assumptions about who owns what.

In practice, the division follows a consistent pattern. The supplier delivers the ECU: developing its software, implementing the TARA derived controls, and validating cybersecurity behaviour at the component level. The OEM assumes system responsibility, integrating all ECUs, ensuring that vehicle level cybersecurity goals are achieved, and demonstrating CSMS compliance for UNECE R155 during type approval.

A CIA typically covers four areas:

While defined responsibilities establish who must implement cybersecurity controls, but compliance is fulfilled only after proving those controls work as intended. That proof is delivered through structured validation and testing activities.

Validation, Testing and Post-Production Requirement for Automotive Cybersecurity

The Clause 11 of ISO 21434 governs cybersecurity validation which requires verification of controls implemented during development. This ensures that the developed solution works as intended against the threats identified in the TARA. Furthermore, the depth of validation required is determined by the Cybersecurity Assurance Level (CAL) assigned during risk determination.

What Validation Activities and Test Evidence does ISO 21434 Require?

At CAL 2 and above, fuzz testing of communication interfaces is mandatory. Penetration testing of external interfaces is expected wherever remote attack paths have been identified. Static code analysis and vulnerability scanning complete the standard validation programme.

On the evidence side, a VCS auditor expects four things.

1. Bidirectional traceability: A documented link between each cybersecurity requirement and the test case that verifies it. Every requirement needs a corresponding test, and every test must map back to a requirement.
2. Test execution evidence: All signal logs, screenshots, or reports showing the system behaved as the cybersecurity specification required.
3. Test results and verdicts: Documented pass or fail report and outcomes and analysis of any failures.
4. Negative testing: Verification to find the control actively rejects invalid conditions, not just that it accepts valid ones.

Note: From our experience, the gaps most identified ahead of a VCS audit are missing or unclear traceability between requirements and test cases, insufficient logs to prove the expected security behaviour, an unclear scope definition, and the absence of negative

However, once validation is confirmed the cybersecurity risk does not end.

When the vehicle leaves production ISO 21434 requires it should be continuously monitored and response capabilities should manage threats that emerge during the vehicle’s operational life. This leads us to our next question.

What does post-production cybersecurity monitoring require under ISO 21434?

Clause 13 of ISO 21434 makes clear that cybersecurity responsibilities extend throughout a vehicle’s operational life.

Once vehicles enter service, the responsible organization must continuously monitor component level vulnerabilities, maintain incident response capability, and deploy patches whenever the associated risk demands it.

The clause also mandates a documented method to differentiate ordinary vulnerabilities from security incidents, as each triggers distinct response obligations.

How do we support ISO 21434 Compliance for Automotive Cybersecurity?

We at Embitel, supports the full cybersecurity lifecycle for active vehicle programs. It offers capabilities aligned to ISO 21434 and UNECE R155 that includes:

1. Engagements typically beginning with TARA. This engagement spans Clauses8, 9, and 15 of ISO 21434 and establishes the foundation for all downstream engineering decisions.
2. Next, the TARA findings are translated into concrete architectures.
3. Further, the controls development implements these designs across hardware, software, in vehicle networks, and all external interfaces, including V2X, cellular, and cloud connectivity.
4. Validation closes the loop. where in our team performs cybersecurity verification at system level in HIL and bench environments, maintaining full traceability from TARA threat to control to test result.

Learn more about our automotive cybersecurity solutions.