Automotive SPICE for Cybersecurity: Automotive SPICE for Cybersecurity – Tutorial (about 60 minutes)

Automotive SPICE for Cybersecurity is a process assessment model from the German automotive association's quality centre (VDA QMC) that extends Automotive SPICE with processes for cybersecurity engineering. Carmakers use it to find out whether a supplier's development projects actually manage cyber risks in a disciplined, traceable way, and suppliers use it to prepare for those questions and to improve. After this tutorial you will be able to explain what the model adds to Automotive SPICE, walk through its six processes from threat analysis to validation, read an assessment result, and plan how a project gets ready for one.

Free tutorial · about 60 minutes · 7 lessons · 4 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: the current edition is the Automotive SPICE for Cybersecurity Process Reference and Assessment Model for Cybersecurity Engineering, version 2.0, written by VDA QMC Working Group 13 and dated 28 March 2025, status "Released". Version 2.0 revised the first edition (version 1.0, July 2021, written against Automotive SPICE 3.1) and adapted it to Automotive SPICE 4.0, which it supplements. In August 2026 VDA QMC released Automotive SPICE 4.1 as the current core model; at the time of writing the publications page lists cybersecurity model 2.0 as the current cybersecurity edition alongside 4.1, with no newer cybersecurity edition announced, so check with the assessment sponsor which combination of core model and cybersecurity model a given assessment uses. A companion book, Automotive SPICE for Cybersecurity guidelines (2nd edition, 2025, print only, sold through the VDA webshop), contains the model plus interpretation and rating guidelines for its processes. The model itself is a free download from VDA QMC. Verified 2026-10-29 against the VDA QMC Automotive SPICE publications page, the VDA webshop entry for the guidelines and the version 2.0 model document.

Who it is for: engineers, architects, testers, project managers, quality and process specialists, and cybersecurity managers at vehicle manufacturers and suppliers who are new to this model and expect to take part in, prepare for or commission a cybersecurity process assessment.

Prerequisites: none. It helps to have met Automotive SPICE or ISO/SAE 21434 before (there are separate courses on both), but every term is explained here when it first appears.

By the end of this tutorial:

You will be able to explain why the industry added a cybersecurity extension to Automotive SPICE and how it relates to UN Regulation No. 155 and ISO/SAE 21434.
You will be able to define the core vocabulary: assets, damage and threat scenarios, attack feasibility, risk treatment, cybersecurity goals, requirements and controls, weaknesses and vulnerabilities.
You will be able to describe the six processes of the model (ACQ.2, MAN.7 and SEC.1 to SEC.4) and the purpose of each.
You will be able to trace the chain from threat scenarios to cybersecurity goals, requirements, design, verification and validation, and explain what an assessor checks on it.
You will be able to explain the prerequisites, scoping rules, rating method and assessor qualification for a cybersecurity assessment, and what such an assessment does not prove.
You will be able to plan practical steps for a project that must show capability Level 2 on the cybersecurity processes.

Lesson 1 – Origins, purpose and scope

Why vehicle cybersecurity became a process question

A current passenger car is a network of computers on wheels. Dozens of electronic control units (ECUs) talk to each other over in-vehicle buses, and several of them talk to the outside world: the telematics unit over the cellular network, the infotainment system over Bluetooth and Wi-Fi, the charging controller over the charging cable, and the diagnostic port to workshop testers. Every one of those interfaces is a possible way in for an attacker. Well-publicised research in the 2010s showed that remote attackers could, in some vehicles, reach safety-relevant functions such as braking or steering. From that point on, cybersecurity was no longer an IT topic that a carmaker could handle at the end of development; it had to be engineered into every connected vehicle function from the start.

Two developments turned that insight into firm obligations. First, the United Nations Economic Commission for Europe (UNECE) adopted UN Regulation No. 155 (often written UN R155) in 2020. It requires a vehicle manufacturer to run a certified cybersecurity management system and to show, for each vehicle type it wants approved, that cyber risks were identified and managed, including risks coming through its suppliers. In the European Union and other countries that apply the regulation, type approval of new vehicles now depends on it. Second, ISO and SAE International jointly published ISO/SAE 21434 in 2021, the engineering standard that describes what organisations and projects should do to manage cybersecurity across the vehicle lifecycle, from concept through development, production, operation and decommissioning.

Neither of those documents tells a carmaker how to judge, in a comparable and repeatable way, whether a particular supplier's project is really doing cybersecurity engineering well. A supplier can show a policy and a certificate for its management system and still run a project in which the threat analysis was done once and forgotten, security requirements are not traced to any threat, and penetration test findings are never fed back into design. Carmakers already had a trusted instrument for judging the quality of a supplier's development processes: Automotive SPICE (ASPICE), the process assessment model they have used since the mid-2000s. The natural step was to extend that instrument to cybersecurity engineering.

From version 1.0 to version 2.0

VDA QMC, the quality management centre of the German Association of the Automotive Industry (VDA), maintains Automotive SPICE through its Working Group 13. That group (then called Project Group 13) published the first cybersecurity model, version 1.0, in July 2021. It was designed as a supplement to Automotive SPICE 3.1, the core model in use at the time. When the core model was completely revised as Automotive SPICE 4.0 at the end of 2023, the cybersecurity supplement had to follow: version 2.0, released in March 2025, aligns the cybersecurity processes with the vocabulary, the information item concept and the measurement framework of version 4.0. VDA QMC also publishes a guidelines book for cybersecurity assessments, now in its second edition, which plays the same role for the cybersecurity model that the general Automotive SPICE guidelines play for the core model.

What the model covers and what it does not

The model deliberately adds only what Automotive SPICE lacks. It defines six additional processes: one for selecting suppliers of cybersecurity-relevant products, one for cybersecurity risk management, and four engineering processes that turn risks into goals, requirements, design measures, verification and validation. Everything else a cybersecurity project needs, such as project planning, configuration management, problem resolution, release and the ordinary engineering processes, is taken from the core model. That is why the model says an assessment against it presupposes an Automotive SPICE result for the recommended VDA scope; we will look at that rule in Lesson 5.

The model covers system, software and electronic hardware engineering, like Automotive SPICE 4.0. It does not provide indicators for mechanical engineering. It is also clear about where it stops in relation to ISO/SAE 21434. Some parts of that standard, such as the organisation-wide cybersecurity governance and culture, are not carried out inside a development project, so they are not assessed with this model; they belong to an audit of the organisation's cybersecurity management system. Conversely, the model's view of risk is intentionally broader than the road-user focus of ISO/SAE 21434: it asks projects to consider risks from the whole automotive ecosystem that could affect the development of cybersecurity-relevant systems, including technical, economic and schedule risks and risks in suppliers' deliverables.

Finally, the model is about process capability, not product security. An assessment tells you how well a project performs and manages its cybersecurity engineering processes. It does not include an in-depth technical analysis of the product, and a good result is not a statement that the vehicle or the ECU is secure.

Lesson 2 – Key concepts and vocabulary

The model borrows most of its cybersecurity vocabulary from ISO/SAE 21434 and its process vocabulary from Automotive SPICE 4.0. The terms below are explained in plain words; the official definitions are in the model's terminology annex and in the source standards.

Item – one component, or several working together, that provides a function at vehicle level, such as "remote vehicle access" or "battery charging". Defining the item and its boundary is the first step of any cybersecurity analysis.
Asset – something worth protecting in or around the item, for example a firmware image, a cryptographic key, a diagnostic service or personal data stored in the vehicle.
Cybersecurity property – the quality of an asset that an attack could compromise, typically confidentiality, integrity or availability.
Damage scenario – the harmful consequence for a stakeholder (driver, passengers, other road users, owner, manufacturer) if a property of an asset is compromised; for example, the vehicle can be unlocked by a stranger.
Threat scenario – a possible way the property of an asset is compromised so that a damage scenario happens, for example spoofing an unlock command over the cellular link.
Attack path and attack feasibility – the sequence of steps an attacker would need to carry out a threat scenario, and an estimate of how easy that path is, considering factors such as required expertise, equipment, time and access.
Impact rating and risk value – an estimate of how severe a damage scenario would be (ISO/SAE 21434 considers safety, financial, operational and privacy impacts), which, combined with attack feasibility, gives a risk value used to prioritise.
TARA – threat analysis and risk assessment, the method that identifies assets, damage scenarios, threat scenarios and attack paths and rates the resulting risks.
Risk treatment – the decision on what to do with each risk: reduce it, avoid it (for example by removing a feature), share or transfer it (for example by contract or insurance), or retain it with justification.
Cybersecurity goal – a top-level requirement, at concept level, stating what protection is needed against one or more threat scenarios. Goals are what validation ultimately checks.
Cybersecurity requirement – a more detailed functional or non-functional requirement derived from a goal, specific enough to design and verify, for example a requirement for authenticated messages with replay protection.
Cybersecurity control – a technical or other measure that detects, counteracts or mitigates a risk, such as secure boot, message authentication codes, access control on diagnostic services or a hardware security module.
Weakness and vulnerability – a weakness is a defect or characteristic that can lead to undesired behaviour; a vulnerability is a weakness that an attacker could really use as a step in an attack path.
Cybersecurity event and cybersecurity information – cybersecurity information is any security-related news (a published flaw in a library, a researcher's report); it becomes a cybersecurity event once it is judged relevant to an item or component.
Risk treatment verification and validation – verification confirms that the design and its implementation meet the cybersecurity requirements and refined design; validation confirms that the integrated system really achieves the cybersecurity goals.
Interface agreement – the agreement between a customer and a supplier that splits responsibilities for distributed cybersecurity activities, including contacts, tailoring, information sharing on vulnerabilities, milestones and support duration.
Process reference model (PRM) and process assessment model (PAM) – the PRM lists processes with their purpose and outcomes; the PAM adds indicators (base practices, generic practices and information items) that assessors use to rate them. The cybersecurity document contains both.
Capability level and process attribute – the six-step scale (0 to 5) on which each process is rated, and the measurable attributes (such as performance management) that define each step. The cybersecurity model reuses these unchanged from the core model.
CSMS – cybersecurity management system: the organisation-level framework of policies, roles and processes that UN R155 requires a vehicle manufacturer to have. ISO/SAE 21434 describes the matching organisational cybersecurity management (its clause 5) for manufacturers and suppliers alike.

Two pairs of terms cause most of the confusion in practice. The first is damage scenario versus threat scenario: the damage is what hurts a stakeholder, the threat is how it could happen. One damage scenario usually has several threat scenarios. The second is goal versus requirement: a goal says what must be protected against which threat, while requirements say what the system, software or hardware must do so that the goal is met. Assessors will ask you to show both levels and the links between them.

Lesson 3 – Structure of the model

Two dimensions, borrowed from the core model

Like every SPICE-family model, the cybersecurity model has two dimensions. The process dimension lists processes, each with a purpose and expected outcomes. The capability dimension describes how well a process is performed and managed, on capability levels made up of process attributes. The model's own contribution is entirely on the process dimension: it states that the capability levels, process attributes, rating scale and rule for deriving a capability level are identical to those of Automotive SPICE 4.0. Whatever you know about rating in the core model applies here.

The six processes

The six processes are spread over three process groups, which sit in two of the three process categories of the core model. The model also shows them inside the full Automotive SPICE process landscape, because an assessment looks at both together.

ACQ.2 Supplier Request and Selection (acquisition group, primary category). Selecting a supplier for a cybersecurity-relevant product using criteria that include the supplier's cybersecurity capability, then contracting with agreed corrective actions. Note that the core Automotive SPICE 4.0 model has only one acquisition process, supplier monitoring (ACQ.4); ACQ.2 is defined in the cybersecurity model itself. Choosing capable suppliers is the first step in managing the supply-chain risks that UN R155 expects manufacturers to control.
MAN.7 Cybersecurity Risk Management (management group, organizational category). Defining the item and its boundaries, identifying assets, damage scenarios and threat scenarios, analysing risk from impact and attack feasibility, choosing treatment options, carrying out and monitoring treatment, and correcting course when treatment does not work. This is where the TARA lives, and it continues for the life of the project rather than happening once.
SEC.1 Cybersecurity Requirements Elicitation. Specifying cybersecurity goals for the threat scenarios that need treatment, deriving requirements from them (including requirements for production, operation, maintenance and decommissioning), keeping goals, requirements and threats consistent and traced, and communicating the agreed requirements.
SEC.2 Cybersecurity Implementation. Refining system, software and hardware architecture and detailed design so that the requirements are met, selecting cybersecurity controls with an explanation of how each mitigates its risk, analysing the architecture and design for weaknesses, keeping everything traced, and communicating the results, including vulnerabilities found.
SEC.3 Risk Treatment Verification. Specifying verification measures that show the implementation complies with the cybersecurity requirements and refined design, selecting measures for each release (including regression), performing them and recording results, tracing measures and results, and summarising and communicating them.
SEC.4 Risk Treatment Validation. Specifying validation measures based on the cybersecurity goals, selecting them, validating the integrated system and recording the results, tracing measures to goals and results to measures, and summarising and communicating them.

Why separate verification and validation processes?

Automotive SPICE 4.0 already has verification inside each engineering process and a separate validation process (VAL.1). So why does the cybersecurity model need SEC.3 and SEC.4? The reason is the different reference point. Ordinary validation asks whether the delivered product satisfies its intended use in its real operating environment. Cybersecurity validation asks something narrower and in a sense opposite: whether the integrated system still achieves its cybersecurity goals when someone tries to use it in unintended ways. Methods such as penetration testing, which try to find vulnerabilities nobody has identified yet, are typical here. Likewise, SEC.3 adds security-specific verification, such as simulated attacks on network interfaces, brute-force attempts, checks for unspecified functionality and static analysis against secure coding rules, on top of the verification that the core processes already require.

How each process is described

Each process follows the same template as the core model: a process ID and name, a one-sentence purpose, a numbered list of outcomes, base practices (process-specific activities that produce the outcomes, numbered like SEC.1.BP2), and a table mapping base practices and output information items to outcomes. Notes beneath the base practices give examples and clarifications; they are guidance, not additional requirements. Output information items refer to information the assessor expects to find, such as cybersecurity goals, threat scenarios, interface agreements, risk treatment records and verification measure data. Their typical characteristics are listed in an annex, and the model warns that these lists are not meant as a checklist; names and formats in your organisation can differ.

The annexes

The document has five annexes worth knowing. Annex A states conformity with the international process assessment standards (the ISO/IEC 33000 family) by reference to the core model. Annex B lists the information item characteristics relevant to the cybersecurity processes. Annex C collects the terminology and abbreviations. Annex D shows the expected chains of bidirectional traceability and consistency. Annex E sketches how the base practices relate to the requirements of ISO/SAE 21434, which is very helpful when one integrated process must satisfy both the standard and the assessment model.

The capability dimension in brief

Because the measurement framework is the core model's, a cybersecurity process is rated on the same six capability levels: 0 Incomplete, 1 Performed, 2 Managed, 3 Established, 4 Predictable and 5 Innovating. Level 1 has one attribute (process performance); every higher level has two, for example performance management and work product management at Level 2. Each attribute is rated N (not achieved), P (partially), L (largely) or F (fully), and a process reaches a level when that level's attributes are at least largely achieved and every attribute below it is fully achieved. At Level 1 the base practices and output information items of the six processes are the main indicators; from Level 2 upwards the generic practices of the core model are used, and they are the same for every process.

Lesson 4 – How it works in practice

The risk-driven flow

The heart of the model is a chain of work that starts with risk and ends with evidence that the risk was treated. Figure 2 shows the flow as a project lives it.

In words: the project first defines what it is protecting (the item, its functions and its boundary), then identifies assets, the damage that compromise could cause and the threat scenarios that could cause it. It rates impact and attack feasibility, derives a risk value, and decides on treatment. For risks it decides to reduce, it states cybersecurity goals and derives requirements. Architects and designers refine the system, software and hardware design to meet those requirements, choose controls, and look for weaknesses in what they built. Verification shows the implementation meets the requirements; validation shows the integrated system meets the goals. Any weakness found in design, verification, validation or after release goes back into risk management, which re-evaluates the risks and, if treatment is not working, triggers corrective action.

Two practical points follow. First, MAN.7 is not a single document produced in the concept phase. The model expects the scope, assets and threat scenarios to be updated regularly, cybersecurity information to be watched continuously, and risks to be re-evaluated over time. Second, the flow is iterative. In an agile project the TARA, goals and requirements grow increment by increment, and the model explicitly allows requirements to be refined in iterations. What matters is that each increment keeps the chain complete and consistent.

Traceability and consistency

Most base practices in the engineering processes come in a recognisable rhythm: specify, analyse or refine, ensure consistency and establish bidirectional traceability, then communicate the agreed result. Bidirectional traceability means you can follow a link in both directions: from a threat scenario down to the goal, requirements, design elements, verification measures and results that deal with it, and from any test result back up to the threat it addresses. Consistency means the linked content actually agrees; a link between a requirement and a test that checks something else is traceable but not consistent.

Figure 3 – The main bidirectional traceability links an assessor expects, from threat scenarios through goals and design to verification and validation results.

Figure 3 shows the main chains in the model's traceability annex. Notice the two branches leaving the goals: validation traces directly to goals, while verification traces to requirements and design. An assessor will typically sample a few high-risk threat scenarios and walk the chain both ways. Gaps (a goal with no validation measure, a control with no requirement behind it, a requirement with no verification) are the most common findings in cybersecurity assessments, exactly as in ordinary Automotive SPICE assessments.

Where the rest of ISO/SAE 21434 project work is covered

Because the model adds only six processes, it explains in its introduction how other project-level cybersecurity activities are covered by existing parts of Automotive SPICE. In summary:

Cybersecurity responsibilities and planning are covered by the Level 2 generic practices for planning and resources, and by project management (MAN.3).
Tailoring of cybersecurity activities is covered by process deployment at Level 3 and planning at Level 2.
Reuse and off-the-shelf components are covered by the make, buy or reuse analysis in the architecture processes, by reuse management (REU.2), by the project interface practices in MAN.3 and by MAN.7.
Components developed out of context (without a known vehicle) are covered by the SEC processes, working from assumed cybersecurity goals.
The cybersecurity case (the argument that the item is adequately secure) draws its input from the "summarise and communicate results" base practices of the engineering processes.
Release for post-development (production and operation) is covered by product release (SPL.2), configuration management (SUP.8) and quality assurance (SUP.1).
Requests for quotation and alignment of responsibilities with suppliers are covered by ACQ.2 and supplier monitoring (ACQ.4).

Working with suppliers

Cybersecurity work is almost always distributed. A tier-1 supplier develops an ECU but buys a modem module, an operating system and cryptographic libraries, and uses open-source components. ACQ.2 asks the buyer to define evaluation criteria that include the candidate's cybersecurity capability (its methods such as TARA and vulnerability analysis, its organisational cybersecurity, quality and information security management, its ability to support the product in operation, and its record in earlier projects), to evaluate candidates against those criteria, to issue a request for quotation that includes a corrective action plan for identified gaps, and to contract with those corrective actions agreed. Responsibilities for distributed activities can be fixed in an interface agreement. For free and open-source software delivered without any support, the model notes that no interface agreement is required, but the risks of using that software still have to be managed in MAN.7.

What Level 2 looks like for the cybersecurity processes

Many carmakers ask for Level 2 on the cybersecurity processes. In daily work that means each SEC process and MAN.7 is planned (with objectives, schedule and responsible people), resourced with people who have the needed security competence and tools, monitored and adjusted, and coordinated with the other parties involved, such as the customer's security team, the sub-supplier and the internal penetration testers. It also means the outputs are under control: the TARA, goals, requirements, controls rationale and test reports have defined content and quality criteria, are reviewed, versioned and baselined in configuration management, and changes to them are handled in a controlled way.

Implementation steps for an organisation

Clarify the driver: which customer asked for which cybersecurity processes, at which level, by when, and which version of the core and cybersecurity models they expect.
Check the foundation: is there a recent Automotive SPICE result for the recommended VDA scope? If not, plan for a combined assessment or close the gaps in the core processes first.
Map your existing ISO/SAE 21434 process to the six processes and to the related core practices; this shows gaps quickly.
Define the "how" where it is missing: a TARA method and tool, templates for goals and requirements, a controls catalogue, weakness analysis and secure coding rules, a security test strategy with selection criteria for regression.
Set up traceability in your requirements and test tools for the chains in Figure 3, and train people in using them.
Pilot on a live project, let quality assurance check adherence, and run an internal or informal assessment before the formal one.

Lesson 5 – Assessment, certification and compliance

The prerequisite: an Automotive SPICE result

The cybersecurity model is a supplement. It assumes that the processes it does not repeat (project management, configuration and change management, problem resolution, quality assurance, the core system and software engineering processes) are already performed and assessed. The model therefore states a clear prerequisite: an assessment with the cybersecurity model requires an existing Automotive SPICE assessment result for the recommended VDA scope. If no such result exists, the cybersecurity processes and the VDA scope processes must be assessed together. How long an existing result stays valid is a question the general Automotive SPICE guidelines address: they suggest relying on a result for about twelve months for the assessed project, less after significant changes. The assessment sponsor and lead assessor decide whether a previous result is still representative.

Scope and tailoring

As in every Automotive SPICE assessment, the sponsor (the party that commissions the assessment, often the carmaker) decides the scope: which project, which processes, which target level. When an existing assessment is reused for the full profile, the supporting processes need not be rated again. When the assessment takes place in a cybersecurity-relevant development, all cybersecurity aspects of the reference and assessment models must be considered.

The scope can be tailored to what the assessed organisation actually does. The model's own example: if a supplier has no part in validating the cybersecurity goals, SEC.4 can be left out. ACQ.2 is a special case. The model describes it as something performed once, in the sense of a potential analysis of a supplier for a cybersecurity-relevant product, so it is assessed in that context rather than across the whole project. Scope decisions and their justification should be documented in the assessment plan.

Figure 4 – How a cybersecurity assessment is set up and run, from the prerequisite check to the capability profile and improvement actions.

Running the assessment

The assessment itself follows the same steps as any Automotive SPICE assessment (Figure 4). The lead assessor plans it with the sponsor and the assessed organisation, agrees scope and schedule, then gathers evidence by interviewing the people who do the work and by inspecting work products and tool repositories: the TARA, goals and requirements, design documents, controls rationale, weakness analysis results, test specifications and results, penetration test reports, and the planning and configuration records behind them. The assessors map this evidence to the base practices, information items and generic practices, rate each process attribute on the N-P-L-F scale, derive a capability level per process, and report strengths, weaknesses and the resulting capability profile. Interpretation and rating guidelines for the cybersecurity processes are in the cybersecurity guidelines book, which complements the general Automotive SPICE guidelines that assessors also use.

A cybersecurity process assessment is not a cybersecurity assessment in the ISO/SAE 21434 sense, which is an independent judgement of the cybersecurity of a specific item or component. The model says plainly that an in-depth technical analysis is not part of its assessment. Assessors check that a TARA was done competently and maintained, not whether every attack path in it is correct.

Who may assess

Automotive SPICE assessors are certified by VDA QMC, the personnel certification body for Automotive SPICE, under the scheme defined by intacs (the International Assessor Certification Scheme). Assessor grades range from provisional assessor (who can take part in assessments) through competent and principal assessor (who can lead them). For the cybersecurity model there is an additional qualification: already-certified Automotive SPICE assessors attend an intacs training on the cybersecurity model and pass an exam. Training providers describe the rule that competent and principal assessors with cybersecurity expertise who hold this extra qualification may lead assessments with the cybersecurity model. Check the current intacs and VDA QMC rules before relying on any detail, because they change over time.

Certification and compliance: what exists and what does not

There is no certification of an organisation or product against Automotive SPICE for Cybersecurity. An assessment produces a capability profile for the assessed processes in the assessed project; it does not certify the company, does not "approve" a product and expires in practical terms as the project, people and organisation change. A carmaker can use the profile in supplier selection, in contracts (for example, requiring Level 2 on SEC.1 to SEC.3 by a certain milestone) and in supplier development.

The model sits next to, not in place of, the instruments that show legal and organisational compliance:

UN R155 type approval is granted by approval authorities, supported by technical services, which check the manufacturer's cybersecurity management system and the vehicle type. A supplier's assessment result can be part of the evidence a manufacturer uses to show supply-chain risk management, but it is not a type approval.
Cybersecurity management system audits check the organisation-level processes that do not belong to a single project. ISO/PAS 5112 gives guidance for such audits, building on the general auditing guideline ISO 19011.
Information security assessments such as TISAX (the industry's exchange of information security assessment results, based on the VDA information security assessment catalogue) check how a company protects information in its offices, IT and prototypes, which is a different question from product cybersecurity engineering.

Lesson 6 – Worked example: a telematics supplier prepares for its first cybersecurity assessment

The situation

Nordlicht Telematics (a fictional tier-1 supplier) develops a telematics control unit (TCU) for a carmaker's new vehicle platform. The TCU connects the vehicle to the carmaker's back end over the cellular network and supports remote unlock, remote climate control and over-the-air software updates. The carmaker's supplier quality team asks for an Automotive SPICE for Cybersecurity assessment of the TCU project in nine months, with a target of capability Level 2 on MAN.7 and SEC.1 to SEC.4. Nordlicht had an Automotive SPICE assessment for the recommended VDA scope on the same project two months earlier and reached Level 2 on most processes. The cellular modem module is bought from a sub-supplier, and the TCU software uses an open-source TLS library.

Step 1 – Confirm scope and prerequisites

The quality manager first meets the carmaker's sponsor and an external lead assessor. As the earlier core assessment will still be under a year old, they agree it can serve as the foundation. The supporting processes will not be rated again, but the assessors will still look at how cybersecurity work products are configured and released. Nordlicht selected the modem supplier two years ago, before cybersecurity criteria were part of its purchasing process, so the sponsor decides to leave ACQ.2 out for this project and assess it in a later supplier selection. SEC.4 stays in scope because the carmaker has delegated validation of the TCU's cybersecurity goals to Nordlicht in the interface agreement. The agreed versions of the core model and the cybersecurity model are written into the assessment plan.

Step 2 – Gap analysis on the risk chain

A small internal team walks through MAN.7 and SEC.1 to SEC.4 base practice by base practice. Their findings:

A TARA exists from the concept phase. It identifies the remote unlock command as an asset with an integrity property, the damage scenario "vehicle opened by an unauthorised person", and threat scenarios including spoofing and replaying unlock messages over the cellular link. Impact and attack feasibility were rated and risk values derived. However, it has not been updated in ten months, although the software architecture changed and a vulnerability in an older version of the TLS library was published in the meantime.
Cybersecurity goals exist, but only about half of them are linked to threat scenarios, so the team cannot show which threats each goal treats.
Cybersecurity requirements exist in the requirements tool and are well written, but some were added directly by developers without being derived from a goal.
Controls such as message authentication with keys held in the hardware security module, replay counters and authenticated over-the-air update packages are designed and implemented, but the rationale explaining how each control reduces its risk is missing in several cases.
Nobody analysed the architecture for weaknesses after the last redesign; the debug interface on the production board was never discussed.
Security tests exist (fuzzing of the cellular protocol stack, replay and spoofing tests on the test bench, static analysis against secure coding rules), but there is no documented rule for which tests are repeated in each release.
An external penetration test was performed once, but its results were not traced to the goals and two findings were never fed back to risk management.

Step 3 – Fix the process, not just the documents

The team resists the temptation to patch documents for the assessment. Instead it makes changes that will keep the chain healthy:

MAN.7: the cybersecurity manager defines triggers for updating the TARA (architecture change, new cybersecurity event, new feature, before each release) and adds a monthly review of vulnerability information for third-party and open-source components. The TLS library finding is recorded as a cybersecurity event, its risk re-evaluated, and the library updated as the treatment.
SEC.1: every goal is linked to the threat scenarios it treats. Requirements without a goal are either linked to an existing goal or sent back to risk management to check whether a threat scenario was missing.
SEC.2: an architecture weakness analysis is held with the architects and a security specialist. It identifies the open debug interface as a weakness that could become a vulnerability with physical access. The treatment is a new requirement to lock the debug interface in production units, the design is refined, and the decision is documented. Controls receive a short rationale linking them to the risks they reduce.
SEC.3: the test manager defines selection criteria for security verification in each release: all tests linked to changed requirements, a fixed regression set for high-risk goals, and the full suite before production releases. Traceability is created from tests to requirements and design elements, and from results to tests.
SEC.4: validation measures are specified per goal, including a repeat penetration test of the integrated TCU with the back end, and the earlier findings are fed into problem resolution and MAN.7.
Level 2: the cybersecurity activities are added to the project plan with responsible people and dates; the TARA, goals and test specifications get review criteria and are baselined with each release; a progress review of the cybersecurity work becomes part of the fortnightly project meeting.

Step 4 – The assessment and its result

Eight months later two assessors spend three days with the project. They sample the remote unlock and over-the-air update threat scenarios and follow them down to tests and back. Their resulting profile shows MAN.7 at Level 2, SEC.1 and SEC.2 at Level 2, SEC.3 at Level 2, and SEC.4 at Level 1. For SEC.4 the validation work itself was performed and traced, so its process performance attribute was rated fully achieved, but the second penetration test had been organised at short notice without a plan or agreed resources, so performance management was rated only partially achieved. The report also notes as a strength that new vulnerability information now reliably triggers risk re-evaluation.

What does this example teach? The assessors did not judge whether the message authentication scheme is cryptographically strong; that would be a technical cybersecurity assessment. They judged whether the project identified and treated its risks systematically, kept the chain traceable and consistent, and managed the work. Nordlicht's most valuable changes were the triggers for updating the TARA and the release-based selection of security tests, because these protect the product long after the assessment.

Lesson 7 – Relationship to other standards and frameworks

Automotive SPICE for Cybersecurity sits in a crowded neighbourhood.

Standard or framework	Question it answers	Relationship to Automotive SPICE for Cybersecurity
UN Regulation No. 155	Does the vehicle manufacturer manage cybersecurity well enough for the vehicle type to be approved?	The legal driver. Manufacturers must manage supplier risks; a supplier's process assessment result is one way to gain confidence in a supplier.
ISO/SAE 21434:2021	What must organisations and projects do to engineer and maintain vehicle cybersecurity across the lifecycle?	The engineering source. The model borrows its vocabulary and maps its base practices to the standard's requirements, but assesses process capability rather than conformity. A second edition of the standard is in development.
Automotive SPICE 4.x	How capable are the development processes for system, software, hardware and machine learning?	The core model. The cybersecurity model supplements it, reuses its measurement framework and relies on its processes and on an existing result for the VDA scope.
ISO/PAS 5112	How should a cybersecurity management system be audited?	Covers the organisation-level parts of ISO/SAE 21434 that a project assessment does not.
ISO 26262	Is the item functionally safe, with risks from malfunctions reduced?	Parallel discipline. Safety and security analyses should inform each other, and one integrated process can provide evidence for both, but each is judged separately.
TISAX and ISO/IEC 27001	Does the company protect its information, IT and prototypes?	Information security of the organisation, not product cybersecurity engineering; useful evidence in supplier evaluation under ACQ.2.
UN Regulation No. 156	Does the manufacturer manage software updates, including over-the-air updates, safely and securely?	Related regulation. Update-related threats and controls are typical topics in the TARA and in SEC processes for connected ECUs.

Building one integrated process

The most effective organisations do not run three separate machineries for Automotive SPICE, functional safety and cybersecurity. They build one development process in which cybersecurity requirements are a category of requirements traced like any other, the TARA and the safety analysis are coordinated so that conflicts (for example, a safety need for quick diagnostic access against a security need to lock it) are resolved explicitly, and the same configuration, change and problem management serve all three.

Common pitfalls and best practices

Common pitfalls

Treating the TARA as a one-off concept-phase deliverable, so it no longer reflects the current architecture, features or known vulnerabilities.
Writing cybersecurity requirements and selecting controls without traceable links to goals and threat scenarios, so nobody can show why a control exists or whether a threat is covered.
Believing that a penetration test at the end replaces systematic verification against requirements and design, or the reverse, believing that requirement-based tests replace goal-based validation.
Expecting the cybersecurity assessment to prove that the product is secure, or presenting a good profile to a customer as a security certificate.
Ignoring the prerequisite: requesting a cybersecurity assessment for a project whose core processes (configuration, change, problem management, project management) have never been assessed or are weak.
Forgetting third-party and open-source components, so vulnerabilities in them never become cybersecurity events in risk management.
Producing evidence just before the assessment; assessors look for work performed and managed over time, and dated, reviewed and baselined artefacts reveal the difference.

Best practices

Define explicit triggers for updating the TARA and a routine for monitoring cybersecurity information for all components, including bought and open-source ones.
Set up the traceability chains from threat scenarios to verification and validation results in your tools from the start, and check consistency in reviews rather than relying on links alone.
Write a short rationale for each control explaining which risk it reduces and how, and keep it next to the design decision.
Agree release-based selection criteria for security verification and validation, including regression, and document them.
Agree the assessment scope, tailoring and model versions with the sponsor early and record the justification.
Build one integrated process for Automotive SPICE, functional safety and cybersecurity, with shared configuration, change and problem management.
Fix responsibilities with suppliers in interface agreements, including how vulnerabilities and findings are shared and how long support lasts.

Summary and key takeaways

Automotive SPICE for Cybersecurity 2.0 (VDA QMC, 2025) supplements Automotive SPICE 4.0 with six processes for assessing cybersecurity engineering capability.
The processes are ACQ.2 Supplier Request and Selection, MAN.7 Cybersecurity Risk Management, and SEC.1 to SEC.4 for requirements elicitation, implementation, risk treatment verification and risk treatment validation.
Capability levels, process attributes, the N-P-L-F scale and the level rule are taken unchanged from the core model.
The work is risk-driven: TARA results lead to goals and requirements, design and controls answer them, verification and validation produce evidence, and new findings flow back into risk management.
Bidirectional traceability and consistency from threat scenarios to verification and validation results are central to both good engineering and a good rating.
An assessment presupposes an Automotive SPICE result for the recommended VDA scope, or a combined assessment, and the scope can be tailored with justification.
The result is a process capability profile, not a product security verdict and not a certificate; it complements UN R155 approval, CSMS audits and ISO/SAE 21434 cybersecurity assessments.
Assessments are led by certified Automotive SPICE assessors who hold the additional cybersecurity qualification.

Reflection questions

Pick one connected function in a product you know. What would be its item boundary, two assets, one damage scenario and two threat scenarios, and which process in the model would hold each of these?
Your project's TARA was last updated at the concept gate. Which events in your current project should have triggered an update, and who should decide on the new treatment?
For one cybersecurity goal in your area, describe the full traceability chain you would show an assessor, and identify where you expect the weakest link to be.
A customer asks for capability Level 2 on SEC.3 and SEC.4. What concrete planning and work product management habits would your team need to adopt, beyond performing the tests?
How would you explain to a manager why a good cybersecurity assessment profile does not mean the product is secure, and which other activities are needed to support that claim?