In automotive, safety used to mean crash tests and airbags – now cybersecurity is added. ISO 21434 governs cybersecurity engineering – ASPICE governs development process capability. The two standards address different dimensions – but they often appear together in supply‑chain audits. Understanding their relationship avoids building two disconnected processes – reducing redundant work.
1.1 ISO 21434 – definition
ISO/SAE 21434:2021 Road vehicles – Cybersecurity engineering specifies cybersecurity engineering requirements for automotive E/E systems across the full lifecycle – from TARA (Threat Analysis and Risk Assessment), cybersecurity goals, concept design, integration/verification, to operations and monitoring. It is the mainstream engineering standard supporting UN R155 compliance.
Note: R155 does not mandate ISO 21434 specifically – but the industry widely uses 21434 to produce audit evidence.
1.2 ASPICE – definition
ASPICE (Automotive SPICE) is a software process capability assessment model for the automotive industry. It focuses on process maturity – not safety specifically. It covers requirements management, architecture design, coding, testing – assessing capability levels P0–P3 across the V‑model.
ASPICE is primarily an OEM‑supplier commercial threshold – not a regulatory mandate.
1.3 One governs what – the other governs how well
ISO 21434 defines which cybersecurity activities must be performed, while ASPICE assesses the quality of how those activities are performed. ISO 21434 requires TARA – ASPICE SEC extension checks whether TARA is executed properly and traceably. They are complementary – they cannot substitute for each other.
2. ASPICE 4.0 – Cybersecurity Extension
2.1 SEC process group
ASPICE 4.0 adds a cybersecurity extension – with four processes: SEC.1 to SEC.4. SEC.1 covers cybersecurity requirements acquisition – via TARA – defining security goals. SEC.2 covers security implementation – encryption, isolation, etc. SEC.3 covers risk‑treatment verification – penetration testing, vulnerability scanning. SEC.4 covers risk‑treatment validation – verifying security goals at the vehicle level.
2.2 Mapping to ISO 21434
SEC.1 maps to product development – cybersecurity requirements definition. SEC.2 maps to security concept design. SEC.3 maps to cybersecurity verification. SEC.4 maps to cybersecurity validation. ASPICE SEC evidence supports 21434 compliance – and 21434's TARA outputs feed SEC.1.
2.3 Process integration
ASPICE 4.0 requires cybersecurity activities to be embedded in project management, configuration management, and problem management – not as standalone add‑ons. This aligns with ISO 21434 – security must be integrated into the development mainstream – don't build a separate silo.
3. Key Differences
3.1 Drivers
ISO 21434 is regulatory‑driven – UN R155 requires CSMS – companies use 21434 to produce engineering evidence. ASPICE is commercial‑driven – OEMs use ASPICE as a supplier‑selection condition.
3.2 Assessment approach
ISO 21434 uses gap and compliance checks – with no official "pass/fail" certification. ASPICE uses process capability scoring – P0–P3.
3.3 Scope
ISO 21434 covers cybersecurity only – from concept to decommissioning. ASPICE covers all development processes – requirements, design, testing, supplier management – cybersecurity is only one part. ASPICE 4.0 also adds hardware engineering (HWE) and optional machine‑learning engineering (MLE).
4. Practical Integration
4.1 TARA as the bridge
TARA is ISO 21434's core work (Clause 9) – and the input to ASPICE SEC.1. A complete TARA produces asset lists, threat scenarios, risk registers, and treatment plans – satisfying both 21434 and ASPICE SEC. A solid TARA provides unified evidence for both standards.
4.2 Unified traceability
ASPICE 4.0 requires bidirectional traceability – from system requirements to test results. ISO 21434 requires traceability from security goals to verification evidence. Use tools (DOORS, Polarion) to build a unified traceability framework – manage security and functional requirements together – one set for both audits.
4.3 Supplier management
ISO 21434 Clause 7 covers supplier cybersecurity requirements, while ASPICE ACQ.4 covers supplier monitoring. A single supplier assessment questionnaire can cover both – including cybersecurity capability in supplier qualification.
5. Implementation Recommendations
5.1 Start with a gap analysis
For first‑time adoption – conduct a gap analysis – identify process gaps – prioritise remediation. TARA and bidirectional traceability are high priority.
5.2 One process – two sets of evidence
Don't build two disconnected processes. Embed 21434 security activities into the ASPICE V‑model – one work product produces evidence for both. The same security requirement review record supports both ASPICE and 21434.
5.3 Integrated toolchain
Link requirements, configuration, and test management tools. ASPICE relies on full traceability – 21434 needs complete security evidence. Isolated tools create manual data transfer – inefficient and error‑prone.
5.4 Personnel qualifications
ASPICE assessors have international registration – ISO 21434 has no unified auditor certification. Internal security staff should be familiar with both standards – producing evidence that satisfies both.
6. Common Misconceptions
6.1 ASPICE = no need for ISO 21434
Strong ASPICE SEC performance does not equal ISO 21434 compliance. ASPICE assesses process capability – 21434 checks cybersecurity content. Example: TARA process may be well‑defined – but if risk‑judgement logic is flawed – 21434 review still fails.
6.2 ISO 21434 is an IT security standard
No – it's specifically for automotive E/E systems – different from traditional IT security (ISO 27001). Applying generic IT security approaches to 21434 – OEMs are unlikely to accept the deliverables. Automotive real‑time and long‑lifecycle requirements are not covered by IT standards.
7. Additional Implementation Points
7.1 Assessment frequency
ASPICE is typically re‑assessed every 1–2 years – different process groups can be selected each round. ISO 21434 is tied to vehicle certification – CSMS reviews typically every 3 years. Stagger the schedules to avoid resource peaks.
7.2 Toolchain selection
For requirements management, DOORS or Polarion are common choices. For TARA, dedicated threat‑analysis tools are available. For test management, Vector toolchain or Jira plugins are used. Traceability between tools is ideal – if not directly connected, establish regular sync mechanisms. Poor tool choice creates massive additional documentation workload.
7.3 Common trap
Many companies run two separate workstreams: security team independently does TARA and security requirements – development team follows ASPICE separately – with little interaction. During audits, both teams are asked for evidence – duplicate work is enormous. Correct approach: security activities natively embedded in development – one output serves both reviews.
For ISO 21434 and ASPICE, contact BlueAsia at 13534225140 (King) or email king.guo@cblueasia.com.
相关新闻
