ISO/SAE 21434 in Action: Automotive Threat Analysis, Cybersecurity Requirements, and Lifecycle Evidence

A connected vehicle is a moving network of electronic control units, sensors, gateways, telematics services, diagnostic tools, mobile applications, and cloud infrastructure. Protecting just the cloud service is not enough if attackers can exploit a vehicle update mechanism, impersonate a diagnostic tester, or alter traffic across an in-vehicle interface.

ISO/SAE 21434 establishes an automotive cybersecurity engineering framework that covers cybersecurity risk management across the lifecycle of road-vehicle electrical and electronic (E/E) systems, their components, and interfaces. The published first edition is ISO/SAE 21434:2021. A second edition has been initiated but is not yet the published replacement. There is no official universal maturity-scale ranking of organizations from Level 1 through Level 5 in ISO/SAE 21434.

Cybersecurity is not identical to functional safety

ISO 26262 concentrates on hazards arising from malfunctioning E/E behavior and related functional safety engineering. ISO/SAE 21434 concentrates on cybersecurity threats and risks from malicious or unauthorized actions. Some consequences can overlap: a malicious command may cause a safety-relevant outcome, while an unintentional defect may originate from a different mechanism.

For example, a telematics ECU may be designed to tolerate accidental network faults, but an attacker could attempt to inject unauthorized control messages. The safety team and cybersecurity team must coordinate their analyses without pretending that a Hazard Analysis and Risk Assessment (HARA) is the same as a Threat Analysis and Risk Assessment (TARA).

Understand the automotive cybersecurity lifecycle

New threats and vulnerabilitiesOrganizational governanceConcept and item definitionTARA and cybersecurity goalsSystem and component requirementsDesign, implementation, and integrationVerification and validationProduction and post-developmentMonitoring, maintenance, and end-of-life

The management framework includes organizational cybersecurity management, project-dependent cybersecurity management, distributed cybersecurity activities with suppliers, continual cybersecurity activities, cybersecurity concept, product development, production, operations, maintenance, and decommissioning. Each project needs well-defined work products, responsibilities, decisions, and traceability.

A running example: Secure over-the-air firmware updates

Northstar Mobility supplies a telematics unit with over-the-air (OTA) firmware updates. The unit communicates with a cloud backend, receives update metadata, downloads software, verifies it, and installs it. The engineering team must preserve update authenticity, protect rollback policy, restrict administrative privileges, and maintain reliable recovery after failed updates.

These are teaching examples. A real item definition documents boundaries, interfaces, operational environment, assumptions, dependencies, and supported variants.

Step 1: Establish automotive cybersecurity responsibilities

Define the cybersecurity manager or responsible function, project cybersecurity plan, responsibilities among OEM, Tier-1 supplier, component manufacturer, and cloud provider, and criteria for reviews and approvals. Supplier-to-customer agreements must clarify work products, security activities, information exchange, vulnerability disclosure, and responsibilities. A generic commercial contract does not automatically provide a sufficient cybersecurity interface arrangement.

Set up engineering traceability through the approved requirements and lifecycle tool. Record unique IDs for assumptions, assets, threat scenarios, TARA outputs, cybersecurity goals, requirements, design decisions, verification methods, and defects.

Step 2: Perform a TARA

A TARA is more than running STRIDE against a diagram. It involves structured asset identification, damage scenario assessment, threat scenario identification, attack path analysis, impact determination, attack feasibility evaluation, and cybersecurity risk determination and treatment according to the applicable methodology.

A compact example:

Important distinction: avoid relabeling the attack-feasibility analysis as a generic statistical probability without justifying the methodology. ISO/SAE 21434’s risk reasoning has automotive-specific structure. If you use STRIDE, attack trees, or scoring spreadsheets, use them as analysis aids and validate their suitability against the standard’s required work products.

Step 3: Convert risks into traceable requirements

For the update scenario, engineering requirements could be:

• CYB-GOAL-01: The device shall prevent installation of unauthorized firmware.
• CYB-REQ-01: The boot/update chain shall verify firmware authenticity and integrity using approved cryptographic mechanisms and trusted keys.
• CYB-REQ-02: Release-signing authority shall be protected from ordinary development credentials.
• CYB-REQ-03: The device shall handle invalid or interrupted updates without entering an unsafe operating state.
• CYB-REQ-04: Events relevant to update validation failure shall be recorded and available through an approved diagnostic/monitoring process.

These are illustrative engineering requirements, not copied normative clauses. Each should have a verification method and a link to risks and architecture. Security goals and claims should be specific enough to support meaningful evidence.

Step 4: Design security into the architecture

Use a trust boundary between the release-signing environment, update distribution service, and receiving ECU. Possible design measures include asymmetric signatures, protected trust anchors, secure boot, version/rollback controls, separate roles, minimized diagnostic exposure, authenticated service access, and recovery partitions when appropriate. Examine the security of provisioning, key rotation, revocation, emergency updates, and supply-chain processes.

Valid and approvedInvalidDeveloper changeApproved release processProtected signing serviceSigned update manifest and imageDistribution / CDNECU verificationControlled installationReject, log, recover

A cryptographic mechanism can only provide its intended protection if trust-anchor provisioning and key lifecycle management are correct. Network TLS alone does not prove that a firmware image was authorized by the product manufacturer.

Hands-on lab: Detect unauthorized file modification

Create firmware_integrity_lab.py. This safe local exercise uses a synthetic firmware file and a hash. It illustrates integrity checking, not secure automotive firmware authorization.

from hashlib import sha256
from pathlib import Path

image = Path("demo_firmware.bin")
image.write_bytes(b"DEMO-FIRMWARE-V1")
expected_digest = sha256(image.read_bytes()).hexdigest()

<em># In the exercise, an untrusted change occurs after the reference digest is recorded.</em>
image.write_bytes(b"DEMO-FIRMWARE-V1-MODIFIED")
observed_digest = sha256(image.read_bytes()).hexdigest()

print("expected:", expected_digest)
print("observed:", observed_digest)
print("integrity check:", "PASS" if expected_digest == observed_digest else "FAIL")
assert expected_digest != observed_digest
Code language: PHP (php)

Run python3 firmware_integrity_lab.py or py -3 firmware_integrity_lab.py. The integrity check should report FAIL after alteration.

Critical security lesson: an attacker who controls both the image and an unprotected reference checksum can update both. A bare hash does not prove authenticity. A production OTA security architecture needs an authenticated trust chain, properly protected signing keys, authorization policies, and robust rollback/recovery controls reviewed against project requirements.

Step 5: Verify, validate, and make a security argument

Verification checks whether defined requirements and design properties were implemented correctly. Validation evaluates whether the integrated item achieves its cybersecurity goals in its intended operational environment. Evidence may include secure-code reviews, component tests, fuzzing where appropriate, interface tests, penetration tests by authorized specialists, signing-key process assessments, release pipeline review, and security regression tests.

Traceability might look like this:

A cybersecurity case or documented argument links claims about protection to evidence and justified assumptions. A folder containing hundreds of test reports without traceable claims is difficult to assess.

Step 6: Continue after production

Production is not the end of automotive cybersecurity. Monitor disclosed vulnerabilities, analyze field incidents, obtain supplier security notices, reassess risks when threats change, update products through controlled processes, and plan decommissioning, credential disposal, and supported lifetimes.

ISO/SAE 21434 supports automotive cybersecurity engineering and can inform a cybersecurity management system; it is not identical to UNECE R155 type-approval obligations or to ISO 26262 safety compliance. Requirements depend on product, responsibilities, jurisdiction, and applicable customer contracts.

Watch for these process failures

• TARA completed once and never revisited after architecture changes.
• Cybersecurity requirements not linked to tests or source artifacts.
• Supplier responsibilities assumed rather than agreed and reviewed.
• Firmware hashing mistaken for cryptographic authorization.
• Safety and cybersecurity work separated so completely that shared consequences are missed.
• Post-production vulnerability monitoring omitted from the lifecycle.

Engineer’s knowledge check

Q: What distinguishes TARA from HARA? A: TARA evaluates automotive cybersecurity threats and risks; HARA concerns functional safety hazards and risk classification.

Q: Does passing a source-code scan prove the vehicle-level cybersecurity goal? A: No. It is one piece of evidence within system-level engineering and validation.

Q: Is the new ISO/SAE 21434 edition already the published replacement? A: No. Confirm the ISO publication status and applicable project baseline before changing formal compliance claims.

Official references

• Published ISO/SAE 21434:2021: https://www.iso.org/standard/70918.html
• ISO/SAE 21434 edition under development: https://www.iso.org/standard/95437.html
• ISO integrated automotive cybersecurity/information security publications: https://www.iso.org/publication/PUB200434.html

Rajesh Kumar

I’m Rajesh Kumar, a DevOps, SRE, DevSecOps, Cloud, and Platform Engineering expert passionate about sharing practical knowledge, real-world experiences, and industry best practices. I have worked at Cotocus and regularly write about technology, travel, investing, health, product reviews, and digital marketing through my various platforms.

I publish technical articles at DevOps School, travel stories at Holiday Landmark, stock market insights at Stocks Mantra, health and fitness guidance at My Medic Plus, product reviews at TrueReviewNow, and SEO and digital marketing strategies at Wizbrand.