A Guide to Road Vehicle Cybersecurity: Part 2

December 13, 2022 McKenzie Jonsson


In part two of our blog series, we cover the second half of our eBook, “A Guide to Road Vehicle Cybersecurity According to ISO 21434” – Click HERE for part one.

To read the entire eBook, click HERE. 

A Guide to Road Vehicle Cybersecurity: Part 2

Cybersecurity V-model


Much like other automotive standards, ISO 21434 defines a system engineering V-model to be followed for the development of cybersecurity features.

Concept Development

The cybersecurity V-model starts with the definition of the exact “item” that will be developed. The item is a component or set of components that implement functionality at the vehicle level and is defined in an item definition. In many cases, the same item definition may be used for both functional safety analysis and cybersecurity analysis.

Once the item has been clearly defined, a Threat Analysis and Risk Assessment (TARA) is performed to identify what cybersecurity threats exist for the item and what the risk of those threats are. For threats where the risk must be reduced, concept level requirements are developed, known as cybersecurity goals. Cybersecurity goals form the highest-level requirements for the system being developed from a cybersecurity perspective. For risks that will remain after cybersecurity goals are achieved, cybersecurity claims are documented to explain what, if any, risks still exist and why they can be accepted.

After defining cybersecurity goals, a cybersecurity concept is created. This documents the high-level concept that will be used to achieve the cybersecurity goals. The concept takes the form of cybersecurity requirements as well as requirements on the operating environment.

Product Development

Once a cybersecurity concept has been developed, the system must be designed in a way that will satisfy the cybersecurity requirements. Any existing architecture must be updated to consider the cybersecurity requirements. Each component of the system should be designed to support the cybersecurity requirements.

Although ISO 21434 provides an example of developing a system in two layers of abstraction, no specific number of layers is required. Instead, the standard leaves it to the product development organization to define a process appropriate for the complexity of their system. This ensures that organizations can adapt the standard to a wide range of systems and, for many, means that their existing system engineering process will satisfy ISO 21434.

Once the components of the system have been designed and integrated, the system must be verified to ensure that it meets the cybersecurity requirements.

The methods for verifying the system can include:

  • Requirements-based testing
  • Interface testing
  • Resource usage evaluation
  • Verification of the control flow and data flow
  • Dynamic analysis
  • Static analysis

The integration and verification activities should be documented in a verification specification and the results of verification documented in a verification report.

Validation of Cybersecurity Goals

While the focus of verification is ensuring that the item meets the cybersecurity requirements, validation ensures that the item achieves the cybersecurity goals. This is done by first validating that the cybersecurity goals are adequate and then validating that the item achieves the cybersecurity goals. Validation may involve reviewing work products, performing penetration testing and reviewing all the managed risks previously identified. A rationale for the validation activities is required. The completed validation is documented in a validation report.

RELATED: The Impact of ISO 26262 on Automotive Development

Post-Development Activities

Even after product development is complete, the cybersecurity lifecycle continues.


During the production phase, the item that has been developed is manufactured and assembled. A production control plan is required to ensure that cybersecurity requirements for post-development that were identified earlier in the lifecycle are applied to ensure that no vulnerabilities are introduced during production.

Operations and maintenance

Once an item has been integrated into a vehicle and the vehicle is on the road, new cybersecurity threats can still be identified. ISO 21434 requires organizations to have a plan for how to respond to this scenario.

Organizations must create a cybersecurity incident response plan each time a new cybersecurity incident occurs. This plan includes what remedial actions are required and how they will be performed. The response may range from providing new information to vehicle owners, to over-the-air updates, to recalls where the owner must bring the vehicle in for service.

End of cybersecurity support and decommissioning

Given that the cybersecurity lifecycle continues after vehicles have been sold to consumers, a method for ending cybersecurity support for those vehicles is needed. ISO 21434 focuses on developing a plan for communicating with customers when cybersecurity support ends. Since decommissioning can occur without the organization’s knowledge and in such a way that decommissioning procedures cannot be enforced, ISO 21434 only requires making documentation available to explain how to decommission the item with regards to cybersecurity, if this is even required.

RELATED: Best Practices to Accelerate Your Automotive Spice (ASPICE) Capabilities

Integrating the Cybersecurity with Overall System Engineering


ISO 21434 defines many cybersecurity-specific requirements and requires personnel with specific cybersecurity knowledge and skills. Because of this, it may be tempting for organizations to silo cybersecurity engineering activities from other engineering activities, but this would be a mistake. While risk analysis required by ISO 21434 can be considered as a separate activity from other system engineering activities, a single product still must be developed that meets a wide range of requirements, including cybersecurity requirements. For this reason, it is best to manage a unified database for requirements, architecture, and design, rather than tracking cybersecurity artifacts separate from others.

To support this, think of cybersecurity analysis as another input to product development, just like functional safety analysis and market analysis.

By taking a unified approach, a single system engineering V-model can be implemented that describes an overall product development process that incorporates cybersecurity without creating silos. While specialists will be focused on performing cybersecurity analysis, implementing known best practices and validating the final system achieves cybersecurity, this must be done in cooperation and coordination with the rest of product development.


How Jama Connect® Supports Cybersecurity Engineering

One way to implement a unified requirements, architecture, and design database is by using Jama Connect®. Jama Connect for Automotive provides a framework that incorporates the key requirements of ISO 21434 into a single project structure along with overall system engineering.

Specifically, Jama Connect for Automotive provides guidance on supporting the following activities:

  • TARA Cybersecurity goals
  • Cybersecurity concept
  • Design Integration and verification
  • Validation

An example of the framework is shown below:



ISO 21434 introduces a robust framework for organizations to apply the state-of-the-art in cybersecurity to their product development. This framework is necessary from both a market and regulatory perspective. The high-level of connectivity available in vehicles today means that there many ways for someone to maliciously change a vehicle’s operation. While many consumers may be unaware of the risks today, if there are ever accidents that result from cyber-attacks, that will change quickly. A vehicle OEM’s brand will surely be impacted by such as incident. In addition, regulators have already imposed strong cybersecurity requirements in many regions. ISO 21434 is quickly becoming an essential regulation for companies developing products at all levels of the automotive supply chain.

Whether your team is young or seasoned, small, or large, all together or scattered across boundaries, Jama Connect for Automotive can help improve processes, reduce costs, improve time to market, and help achieve ASPICE compliance. To learn more about Jama Connect for Automotive, download our datasheet.

Interested in learning more about how Jama Connect for Automotive can help provide your team meet market demands more quickly and efficiently?
Visit jamasoftware.com/solutions/automotive or contact us to learn how Jama Connect can optimize success for your organization.

Thank you for reading the conclusion of this 2 part blog series. To read the entire eBook, click HERE. 

Previous Article
Jama Connect® vs. IBM® DOORS®: Migration & Data Mapping: A User Experience Roundtable Chat
Jama Connect® vs. IBM® DOORS®: Migration & Data Mapping: A User Experience Roundtable Chat

Jama Connect® vs. IBM® DOORS®: Migration & Data Mapping: A User Experience Roundtable Chat Increasing indus...

Next Article
Euro Roundup: MDCG Publishes Guidance on MDR, IVDR Authorized Representative Requirements
Euro Roundup: MDCG Publishes Guidance on MDR, IVDR Authorized Representative Requirements

Jama Software® is always on the lookout for news and content to benefit and inform our industry partners. A...