ASPICE for Cybersecurity: The most important information in 5 minutes

Cybersecurity in cars? At first, it sounds like hackers taking control of brakes or radios suddenly displaying dubious pop-ups.

But in reality, the issue is much more sobering—and at the same time even more important: designing secure processes. This is exactly where ASPICE for Cybersecurity comes into play.

Many talk about it, but few implement it consistently. In this article, we go into detail: we look at the core processes, how they feel in practice, where the biggest pitfalls lie, and how you can combine ASPICE & ISO/SAE 21434 in a smart way.

ASPICE explained briefly – a look at the “why”

First, a quick refresher: ASPICE is essentially a framework that assesses the maturity of your software processes – from level 0 (incomplete) to level 5 (innovating). Developed by the VDA, it is based on ISO/IEC 330xx standards. Companies such as OEMs and suppliers use ASPICE to measure and improve quality, safety, and process efficiency.

This means that ASPICE evaluates processes, not the end product.

Example: If your team develops software, ASPICE does not ask, “Does the software work?”

It asks, “Was your approach structured in such a way that it is likely to work next time too?”

Cybersecurity expands on this idea: “Do you have processes in place to ensure that your product is also robust against attacks?”

ASPICE 4.0 at a glance – what's new

ASPICE 4.0 was released in November 2023 and brings with it some tangible changes:

Shorter VDA mandates in the assessment, e.g., reduction to basic and domain parts—less paperwork, more focus.
Strategy documents are moving from Level 1 to Level 2—Level 1 is easier to achieve.
Fewer but more strongly combined base practices – such as traceability and consistency in one.
Assessors must requalify – more expertise is required.

Cybersecurity process groups in practice

The cybersecurity extension (Cybersecurity PAM) has been available since 2022. The VDA has published it in the form of a supplementary Process Reference & Assessment Model.

The extension of ASPICE for cybersecurity (Cybersecurity PAM) fills precisely the gaps left by ISO/SAE 21434 in the audit context. It provides procedural evidence that can be evaluated in the assessment.

Let’s make the processes tangible:

ACQ.2 – Supplier Request & Selection

Theory: Selection and evaluation of suppliers based on their cybersecurity capabilities.

Practical example:
Imagine your company wants to purchase a new ECU.

You don’t just ask, “Does the ECU have all the necessary technical capabilities?”
You also ask, “Does the supplier have verifiable cybersecurity processes?”
Do you have evidence of this, such as a previous ASPICE cybersecurity assessment or CSMS certification according to ISO/SAE 21434:2021?

Tip: Develop a “Cybersecurity Supplier Checklist” or agree on a Cybersecurity Interface Agreement. This should include:

Does the supplier have a TARA process in place?
How does it document vulnerability management?
Does it have patch management in accordance with SOP?
What work products are delivered by the supplier and when?

MAN.7 – Cybersecurity Risk Management

Theory: Identify, analyze, and address risks.

Practical example:
You are working on a gateway control unit. Vulnerability: OTA updates.

Risk analysis (TARA): OTA could introduce fake firmware.
Treatment: Implement secure boot + digital signatures.
Documentation: Risk identified, mitigated, reassessed.

Tip for projects:

Identify assets sensibly.
Use attack path analysis (as described in the yellow band).
Ensure traceability, for example when deriving attack probabilities before and after risk treatment.
Always ask yourself: “If I were a hacker, where would I start?”
Document every assumption. Because that’s exactly what the assessment will probe: “Why did you decide to accept this risk?”
Ensure that the risks are addressed in the cybersecurity concept and that the cybersecurity process is planned.

SEC.1 – Cybersecurity Requirements Elicitation

Theory: Deriving security objectives from risk analyses.

Practical example:
You have identified the risk “Remote exploit via infotainment.”

Objective: “Prevent unauthorized access to driving functions.”
Derived requirements:
All external connections must be authenticated.
Data between infotainment and gateway must be encrypted.

Tip: Use bidirectional traceability (as required in the yellow band). This means that each requirement is linked to the associated risk and the subsequent test case.

SEC.2 – Cybersecurity Implementation

Theory: Implementing requirements in architecture and design.

Practical example:

Requirement: “Encrypt communication.”
Implementation:
- TLS 1.3 on the infotainment interface.
- HSM (hardware security module) for key management.

Practical tip: Be aware that cybersecurity controls are not free.
They often have a massive impact on the architecture (CPU load, memory, timing). Plan for them early on—otherwise, you may face expensive redesigns.

SEC.3 – Risk Treatment Verification

Theory: Verify that implementation meets requirements.

Practical example:

Verify that TLS 1.3 is configured correctly.
Test whether attacks such as downgrade attacks are blocked.

Tip: Automate wherever possible!

Static code analysis (e.g., MISRA-C with security checks)
Security test automation in CI/CD
Regression tests for patches

Note: Ensuring the effectiveness of measures depends on the quality of the specifications. The better and more detailed the requirements are written, the more confident you can be that the measures will be effective.

SEC.4 – Risk Treatment Validation

Theory: Validation that the system is truly secure – in other words, the “reality check.”

Practical example:

Penetration test against the real ECU.
Fuzzing against CAN interface.

Tip: Think of the “red team” approach here.
The difference to verification: It is not just about “correct implementation,” but about whether the right measures have been chosen.

ASPICE Cybersecurity vs. ISO/SAE 21434 – who does what

ISO/SAE 21434 → provides the framework: What activities are required?
ASPICE Cybersecurity → reviews the processes: How mature are these activities in your company?
In practical terms, this means that 21434 requires you to perform a TARA. ASPICE evaluates whether your TARA process is repeatable, traceable, and robust.

What an assessment looks like in reality

An ASPICE cybersecurity assessment is not an examination of your product – but of your processes. Typical procedure:

Define scope: Which processes (SEC.1–4, MAN.7, ACQ.2) are relevant?
Interviews: Assessors talk to developers, architects, testers.
Review work products: requirements, architecture documents, risk analyses, test reports.
Evaluation: Each process is assigned a maturity level (from “not achieved” to “fully achieved”).
Result: You receive a profile – and see where there are gaps.

Tip: Prepare your teams. Assessors often ask very specific questions:

“Show me the traceability of this risk to the test case.”
“How do you ensure that external suppliers also meet your security requirements?”

Common pitfalls (and how to avoid them)

Double documentation: Mapping ISO/SAE 21434 & ASPICE in parallel → Chaos.
Solution: Shared templates.
Traceability only on paper: Maintaining requirements tools (DOORS, Polarion) → but Excel lists are used in the project.
Solution: Standardize toolchains, integrate evidence.
Validation underestimated: Verification (tests) ≠ Validation (reality check).
Solution: Plan external pen tests as early as the acquisition stage, before SOP is due.
Supplier management: Often the weakest point.
Solution: Involve suppliers at an early stage, check with ASPICE checklists.

Conclusion – what you can do now

ASPICE for Cybersecurity is more than just a new buzzword—it is a practical tool for making cybersecurity processes in the automotive sector tangible and measurable.

If you: