In the past, automotive safety meant crash tests and airbags. In recent years, connected vehicles, OTA, and V2X have turned cars into connected terminals on wheels – cybersecurity has gone from optional to mandatory.
ISO/SAE 21434:2021 Road vehicles – Cybersecurity engineering – published in August 2021 – by 2026 has become a basic threshold for Tier‑1 supply‑chain access in mainstream global OEMs.
First, a long‑standing confusion in the industry: ISO/SAE does not operate a certification system – it does not issue standard‑format certificates. Third‑party bodies may conduct management‑system audits against this standard – issuing network security management system certificates.
OEM supply‑chain access falls into two scenarios:
·Some tenders (SOR) require a third‑party system certificate.
·Others only require audit reports plus engineering evidence.
For many Tier‑1s, an audit report is sufficient.
ISO/SAE 21434 is a process standard – not a product standard. It covers how cybersecurity activities are organised, recorded, and demonstrated across the full lifecycle – from concept to decommissioning. There is no such thing as testing a single ECU and issuing a certificate.
2. Establish the Cybersecurity Organisation
You must designate a Cybersecurity Manager and a cybersecurity engineering team. The standard does not mandate physical separation from the Safety Manager – small companies may have the same person wearing both hats. Audits focus on clear responsibilities, adequate resources, and no conflicts of interest.
The team needs at least one person who understands both threat modelling and in‑vehicle architecture. Cybersecurity engineers are a scarce resource – this is a major practical bottleneck for small and medium Tier‑1s.
The cybersecurity team and the functional safety team must establish cross‑review mechanisms. A vulnerability can lead to functional‑safety hazards – a remotely compromised braking system – the ISO 21434 cybersecurity incident and the ISO 26262 functional safety failure are two sides of the same coin. Audits check for two‑way impact analysis – the industry calls this Coexistence analysis – TARA and HARA must be cross‑reviewed.
3. Gap Analysis
Bring in a third party – check your existing development processes, quality systems, and technical documentation – line‑by‑line against ISO 21434. Output: a Gap Analysis Report – itemised as compliant, partially compliant, or non‑compliant.
Gap analysis is not a formality. Third parties actually review documents – does the concept phase have Item Definition? Are TARA Risk Assessment records present? Does the development phase have a Cybersecurity Specification? Does operations have a vulnerability‑response plan? Missing items are all flagged.
After the report, produce a remediation plan – fill documents, build processes, hire people, buy tools, conduct training – each item with a timeline and responsible person. Gap analysis + remediation: fast – 3 months – slow – over six months.
4. TARA – Threat Analysis and Risk Assessment
TARA is the core of ISO 21434 – and the item most scrutinised during audits.
4.1 Item Definition: define the functional boundaries and external interfaces of the system under analysis. Item boundaries do not have to be ECU‑level – in domain‑controller scenarios, it can be a system or subsystem spanning multiple ECUs.
Red line: an Item cannot cross supplier boundaries – systems spanning multiple Tier‑1s/Tier‑2s must be split into separate Items – a high‑frequency audit rejection point.
4.2 Identify threat scenarios. Attack‑tree analysis is the industry mainstream – STRIDE focuses on threat identification – the two methods are at different levels – they cannot be treated as equivalent alternatives.
4.3 Damage rating: follows the CAL (Cybersecurity Assurance Level) framework – CAL 1–4 runs through the entire standard – TARA depth and verification rigour are both tied to CAL levels. Higher CAL products have much stricter audit requirements.
4.4 Severity rating: assess each threat scenario's combined severity across Safety, Financial, Operational, and Privacy consequences – output a single Severity level (four levels). It's not four separate independent scores – many auditors will challenge TARA reports that treat them separately.
4.5 Attack‑path analysis and attack‑feasibility rating: assess technical difficulty, required resources, and attack window for each path. High‑risk paths output corresponding Cybersecurity Goals.
4.6 TARA trap: granularity control. Too coarse = useless – too fine = one ECU takes 2–3 months. The goal is to identify high‑risk attack paths – not exhaust all theoretical possibilities.
5. Product Development and Verification
Cybersecurity Goals from the concept phase become the Cybersecurity Concept and Cybersecurity Specification in the development phase.
Write security requirements clearly:
·TLS version locked to 1.3.
·Certificate revocation check intervals.
·Firmware signature verification.
·Secure boot trust‑anchor storage location.
For each security requirement – list the verification method and pass criteria.
Verification matters more than paper design. Static code analysis, penetration testing, fuzzing, and vulnerability scanning – all four must be done. Adversarial testing verifies that the system can correctly detect and respond to illegal input or tampered data – different from functional safety's negative testing – don't mix the terminology.
·Production and decommissioning
Production phase: manage manufacturing‑process cybersecurity – firmware tamper protection, secure key management, production‑line diagnostic‑port access control – items rarely found in traditional quality systems – ISO 21434 provides the framework. Production‑line key injection is a sensitive step – private‑key leaks compromise the whole‑vehicle security system – independent third‑party audits of key‑injection equipment are common OEM additions – the standard itself does not mandate them.
Decommissioning phase: suppliers don't need to go to scrapyards to perform physical erasure. Provide secure data‑erasure mechanisms at the design stage – ensuring that keys, certificates, and personal data in ECUs can be securely wiped at end‑of‑life.
6. Operations, Monitoring, and Incident Response
The biggest addition in ISO 21434 compared to traditional functional safety standards is the operations phase. Once vehicles are on the road, cybersecurity risks are not static – new vulnerabilities, evolving attack methods, OTA‑introduced code – risks continuously change.
You must establish:
·Vulnerability‑disclosure policies.
·Security patch management processes.
·Incident Response Plan.
For security incidents – who is responsible for classification? Who fixes it? How quickly does response start? All must be in the plan.
The standard requires ongoing security management throughout the product's operational lifecycle – no fixed number of years. Five, eight, or ten years – all are commercial contract terms between OEM and supplier.
7. Third‑Party Process Audit
After the previous steps are complete – bring in a third party for a formal process audit. Auditors check process outputs chapter by chapter against ISO 21434 – concept‑phase documents, TARA records, Cybersecurity Specification, verification test reports, incident‑response plan – full stack.
Audit conclusions – industry practice typically uses three categories: Compliant, Conditionally Compliant, Non‑Compliant – different certification bodies may use slightly different terms. Conditionally compliant: main framework is in place – some clauses need supplementary materials – a remediation period is given. Non‑compliant: core processes are missing – start over.
Well‑prepared: 3–5 working days for on‑site and document review. Supplementary remediation: 1–2 months. After all pass – system certificate or audit report is issued.
For ISO 21434 certification, contact BlueAsia at 13534225140 (King) or email king.guo@cblueasia.com.
Related News
