If you ask your favourite browser for details of “SAE International’s Surface Vehicle Recommended Practice SAE J3061”, it will likely tell you that ISO/SAE 21434 “Road Vehicles – Cybersecurity Engineering” superseded it in August 2021. You will also learn that SAE J3061 was stabilized in December 2021 to reflect this transition.
The problem is that embedded software developers often find ISO/SAE 21434 too high-level and detached from daily engineering practices. It tells teams what must be achieved but offers little insight into how to integrate cybersecurity into real-world software development workflows.
This is where SAE J3061, despite being an earlier and now less formally cited guideline, still offers critical value. SAE J3061 provides a more adaptable framework that software engineers can use to infuse cybersecurity thinking directly into their development lifecycle.
There were very sound reasons for the development of this new, more comprehensive and internationally harmonised new standard by ISO & SAE and indeed, ISO/SAE 21434 has been highly successful in providing requirements and guidelines for managing cybersecurity risks throughout the lifecycle of road vehicles.
ISO/SAE 21434’s collation of the essential activities and work products needed to manage cybersecurity risks throughout the vehicle development life cycle has seen growing international acceptance.
Its adoption is closely linked to regulatory developments such as the UNECE WP.29 Cybersecurity Regulation (R155), effective from 2021, which requires manufacturers to implement cybersecurity management systems for vehicle approval. While R155 does not mandate a specific standard, ISO/SAE 21434 is widely recognized as the primary framework for compliance.
In response, major OEMs and suppliers have integrated ISO/SAE 21434 into their cybersecurity processes, and certification bodies now offer audits and training. This widespread uptake shows that ISO/SAE 21434 has been adopted both formally and practically across the automotive industry.
The problem is that embedded software developers often find ISO/SAE 21434 too high-level and detached from daily engineering practices. It tells teams what must be achieved but offers little insight into how to integrate cybersecurity into real-world software development workflows.
This is where SAE J3061, despite being an earlier and now less formally cited guideline, still offers critical value. SAE J3061 provides a more adaptable framework that software engineers can use to infuse cybersecurity thinking directly into their development lifecycle.
ISO/SAE 21434 outlines an engineering process with required activities like Threat Analysis and Risk Assessment (TARA), cybersecurity validation, and assurance arguments. Yet, it largely assumes that the mechanisms to deliver secure software are already mature and established within an organization.
For developers, this leaves a gap:
ISO/SAE 21434 is a “destination standard” — it describes where you must end up but not how to get there. For developers used to working with the prescriptive detail of ISO 26262, that is a significant failing.
The lack of detailed prescriptive guidance for software developers has been recognised and there is an ongoing effort to develop a more direct successor to SAE J3061. The proposed standard, ISO/SAE PWI 8477, titled “Road vehicles — Cybersecurity verification and validation”, was initiated in June 2021. This project aims to provide detailed guidance on the verification and validation (V&V) of cybersecurity in road vehicles, addressing the need for more specific methodologies than those outlined in ISO/SAE 21434.
Although ISO/SAE PWI 8477 is designed to address this problem, that doesn’t help in the short term. SAE J3061, although originally published as a guideline and not a standard, focuses heavily on embedding cybersecurity into the daily reality of system and software development and so still fits those criteria. It offers:
For developers, SAE J3061 provides practical cues for how to make cybersecurity a first-class citizen in the engineering process, not just a compliance checkbox.
SAE J3061 can be considered complementary to ISO 26262 in that it provides guidance on best development practices from a cyber security perspective, just as ISO 26262 provides guidance on practices to address functional safety.
SAE J3061 calls for a similar sound development process to that of ISO 26262. For example, hazard analyses are performed to assess risks associated with safety, whereas threat analyses identify risks associated with security.
The considerations for the resulting security requirements for a system can be incorporated in the process described by ISO 26262-8 §6: “Specification and management of safety requirements”.
Another parallel can be found in the use of static analysis, which is used in safety critical system development to identify construct, errors, and faults that could directly affect primary functionality. In cybersecurity critical system development, static code analysis is used instead to identify potential vulnerabilities in the code.
Despite the clear synergy between the ISO 26262 and SAE J3061, the latter does more than simply establish a cybersecurity process inspired by functional safety. Much of this blog focuses on an appropriate process once functional, safety and security requirements are established but the significance of malicious intent in the definition of those requirements should not be underestimated.
SAE J3061 emphasizes this point throughout. It argues that cybersecurity is likely to be even more challenging than functional safety, stating that “Since potential threats involve intentional, malicious, and planned actions, they are more difficult to address than potential hazards. Addressing potential threats fully, requires the analysts to think like the attackers, but it can be difficult to anticipate the exact moves an attacker may make.”
Perhaps less obviously, the introduction of cybersecurity into an ISO 26262-like formal development implies the use of similarly rigorous techniques into applications that are NOT safety critical. SAE J3061 discusses privacy in general and Personally Identifiable Information (PII) in particular, and highlights both as key targets for a bad actor of no less significance than the potential compromise of safety systems.
In practical terms, it therefore demands that ISO 26262-like rigour is required in the defence of a whole manner of personal details potentially accessed via a connect car, including personal contact details, credit card and other financial information, and browse histories. It could be argued that this is an extreme example of the general case cited by the SAE J3061 standard, which states that “…there is no direct correspondence between an ASIL rating and the potential risk associated with a safety-related threat.”
Not only does SAE J3061 bring formal development to less safety-critical domains, it also extends the scope of that development far beyond the traditional project development lifecycle. Consideration for an incident response process, over-the-air (OTA) updates, and changes of vehicle changes ownership are all examples of that.
The synergy between SAE J3061 and ISO 26262 underpins a practical route to concurrent compliance with both ISO 26262 and ISO/SAE 21434. The SAE J3061 cybersecurity lifecycle begins with the development of the Cybersecurity Program Plan to describe the activities to be carried out. Threat analysis and risk assessments (TARA) are used to identify and assess the potential threats to the system and to determine the risk associated with each identified threat. The TARA results then drive subsequent activities by focusing analyses on the highest risk cybersecurity threats.
Figure 1 shows how the ISO/SAE 21434 expands the familiar safety impact analysis of ISO 26262 to three other damage categories, giving four in total – safety impact, financial impact, operational impact, and privacy impact. The table uses abbreviated impact rating descriptions taken from ISO/SAE 21434 tables F.1 to F.4 inclusive.
Figure 1: ISO/SAE 21434 damage categories
These ISO/SAE 21434 impact categories can help drive proportionate verification and validation effort within a SAE J3061-compliant software development process, mirroring the formal, risk-based approach already established for safety in ISO 26262.
The product development phase of the SAE J3061 lifecycle is subdivided into system, hardware and software levels as reflected in Figure 2. The diagram shows the relationship between the concept and product development phases, and the system, hardware and software product development phases.
Figure 2: An ISO 26262-aligned cybersecurity process
From the software perspective, ISO 26262 & SAE J3061 standards lend themselves to integration at each stage of the product lifecycle – even to the extent that the same test team could be deployed to fulfil both safety and cybersecurity roles where both requirements apply.
For example, it is possible to perform concurrent hazard analysis, safety risk assessment, threat analysis, and security risk assessment, using a single integrated template and method.
LDRA has long experience in easing the path to critical application certification that expertise can be leveraged in the development applications that are compliant with both ISO 26262, and ISO/SAE 21434 through SAE J3061 (Figure 3). Some key elements of that process are discussed in the following
Figure 3 Mapping the capabilities of the LDRA tool suite to the SAE J3061 process guidelines
The primary objective here is to review and update the cybersecurity requirements previously identified in the context of the system. This activity will reference such as hardware and software interfaces, data flow, data storage, data processing, and any subsystems supporting cybersecurity functionality
The objective of this phase is to develop a software architectural design that realizes the security requirements, leveraging the analysis of the “data types being used, how the data will flow, how the software will detect errors; and how the software will recover from errors”. The TBvision component of the LDRA tool suite has a part to play in the verification of the design by reference to the control and data flow analysis of the resulting code. The tools derive the relationship between some or all the code components and represent it graphically such that it can then be compared with the design.
This is a security specific activity, and so it is supplementary to the processes specified by ISO 26262. SAE J3061 refers to “Trust Boundaries”, which can be thought of lines drawn through a program. On one side of the line, data is untrusted. On the other side of the line, data is assumed to be trustworthy. The objective of Software Vulnerability Analysis (SVA) is to perform an analysis of the software cybersecurity requirements and the data flow from the software architectural design, to define where these trust boundaries exist (Figure 4).
Figure 4: Trust boundary layers https://www.researchgate.net/figure/Trust-boundary-Layers-of-Use-Case_fig2_317546519
The first step in a software vulnerability analysis is to decompose the application, and to analyse the data and control entry and exit points. The second step involves using threat categorization techniques to identify threats based on that break-down of the system. In some models, severity values for process, control, and data areas are determined while in others, any entry point or trust boundary is treated as critical for the final step.
LDRA tools support taint analysis (also known as taint checking), a security technique used to track the flow of potentially harmful data through a program. It identifies data that originates from untrusted sources – that is, crossing the trust boundaries from outside the current, trusted domain – and monitors how this “tainted data” propagates. The goal is to ensure that tainted data cannot compromise sensitive parts of the application.
Complementing ISO 26262, secure coding best practices include the application of secure coding standards such as MISRA, CERT, or CWE. It is entirely possible for language subsets to encompass both functional safety and cybersecurity, and indeed MISRA guidelines are designed to do just that (Figure 5). The TBvision component of the LDRA tool suite can be configured to combined rules from more than one source should that be a preferred option.
Figure 5: Applying MISRA C:2025 using the LDRA tool suite
Establishing appropriate project guidelines for coding, architectural design and unit implementation are three discrete tasks but software developers responsible for implementing the design need to be mindful of them all concurrently.
Although the flow of the SAE J3061 document sees software implementation code reviews following logically from software integration, they are usually applied in tandem such that the code is reviewed as it is written. A fully integrated tool suite automates that process, helping to ensure that the good practices required by IEC/SAE 21434 through SAE J3061 are adhered to whether they are coding rules, design principles, or principles for software architectural design.
Metrics relating to such as software component size, complexity, cohesion, and coupling are concerned with the structure of the code base so for them to be meaningful it needs to be a little more complete. Complexity metrics are generated as a product of interface analysis, cohesion evaluated through data object analysis, and coupling through data control coupling analysis.
SAE J3061 suggests that “Code reviews should be conducted on the software throughout the software design and implementation phase.” Traditional peer code reviews may well still have a place in the development process – they can be very useful as an aid to learning between team members, for example – but automating the more tedious checks is far more efficient and less prone to error.
ISO 26262-6:2018 §9 and §10 state that
“The objective of this [Software unit testing] sub-phase is to demonstrate that each software unit fulfils its specification and that there are no unintended functionalities.”
“The first objective of this [Software integration and testing] sub-phase is to integrate the software elements into software components according to the software architectural design.”
“The second objective of this [Software integration and testing] sub-phase is to verify that the software architectural design is realized by the embedded software”
All these objectives remain valid when applying SAE J3061 in tandem with ISO 26262, with the following addition:
“The second objective of this [Software Integration and Testing] sub-phase is to demonstrate that the software architectural design is realized by the embedded software [and there is no malicious logic which can be sabotaged.]”
Just as static analysis techniques embraced verification of adherence to the ISO 26262-6 guidelines for coding, architectural design and unit implementation, the dynamic analysis techniques (which involve the execution of some or all the code) are helpful in both software unit testing, and software integration and testing.
Tables 8, 9, and 10 in ISO 26262-6 list techniques and metrics for performing unit and integration tests, as supported by the TBrun component of the LDRA tool suite (Figure 6). A primary function is to ensure that the expected functionality and software interfaces are verified at the unit and integration levels.
Unit and integration test with the TBrun component of the LDRA tool suite
Software unit and integration tests need to be executed on target hardware and if the developed unit or integrated software is safety-related, then test results should comply with safety requirements. Fault injection and resource tests help further ensure robustness and resilience. For organizations that apply model-based development back-to-back testing at the model and code level is recommended.
Bidirectional traceability is referenced throughout ISO 26262, and SAE J3061 states that the software cybersecurity design is to be “… traceable to, and validated, against the software cybersecurity requirements” and that the implementation is to be “…traceable to and validated against the software cybersecurity design”. The TBmanager component of the LDRA tool suite (Figure 7) can help in establishing the traceability from system level requirements, through high-level requirements and low level requirements, and on to source code and test cases.
Requirements traceability with the TBmanager component of the LDRA tool suite
ISO 26262-8 §11 defines a mechanism to provide evidence that the software tool chain can be relied upon.
The required level of confidence in a software tool depends upon the circumstances of its deployment, with particular focus on the potential for a malfunctioning software tool to introduce or fail to detect errors in a safety-related development.
The LDRA tool suite has been TÜV certified for use with ISO 26262 compliant products up to ASIL D, which removes considerable user overhead in providing evidence of that confidence.
Both ISO/SAE 21434 and SAE J3061 are laudable in their own ways. ISO/SAE 21434 is essential for compliance and regulatory alignment. SAE J3061, on the other hand, remains a rich source of practical insight for embedded software developers who must build security in, not bolt it on.
For teams tasked with delivering secure automotive software, the smartest move is to use ISO/SAE 21434 as the formal guidepost while leveraging SAE J3061 as a practical companion for engineering excellence. Together, they offer both the destination and a usable map to get there.
Where both security and safety are critical, SAE J3061 can be considered complementary to ISO 26262 in that it provides guidance on best development practices from a cybersecurity perspective, just as ISO 26262 provides guidance on practices to address functional safety.
SAE J3061 also calls for a similar sound development process to that of ISO 26262 and mirrors its development phases, and so the standards are not contradictory such that functional safety requirements are mirrored by cybersecurity requirements, designs must reflect both safety and cybersecurity, and so on.
None of these documents mandate the use of automated tools, but their use is almost essential in all but the simplest of projects. Just as the standards complement each other, so the same tools can be used to support those standards concurrently.
White paper: Applying SAE J3061 to ISO 26262
Technical briefing: Underpinning cybersecurity in ISO 26262 compliant applications
Website: Automotive
Website: Taint analysis
Website: Cybersecurity
Webinar on demand: Taint Analysis, Functional Safety, Cybersecurity, and you
Technical white paper: Secure code properly
Email: info@ldra.com
EMEA: +44 (0)151 649 9300
USA: +1 (855) 855 5372
INDIA: +91 80 4080 8707