Cybersecurity Goals vs. Security Requirements: Understanding the Distinction in ISO/SAE 21434

One of the most persistent sources of confusion in automotive cybersecurity engineering is the distinction between cybersecurity goals and cybersecurity requirements. Both terms appear throughout ISO/SAE 21434, both relate to protecting vehicle systems from cyber threats, and both feed into the cybersecurity case that OEMs and suppliers must build for UNECE R155 type approval. Yet they serve fundamentally different purposes in the engineering process, are produced at different stages, and carry different levels of abstraction. Confusing them — or treating them as interchangeable — leads to incomplete risk treatment, untraceable security architectures, and audit findings that delay certification.

This guide provides a thorough examination of what cybersecurity goals and security requirements are, how they relate to each other within the ISO/SAE 21434 framework, how they are derived from the TARA process, and how to avoid the common mistakes that engineering teams make when transitioning from risk assessment to cybersecurity concept specification.

Where Goals and Requirements Live in ISO/SAE 21434

ISO/SAE 21434 organizes automotive cybersecurity engineering into a structured lifecycle. Two clauses are particularly relevant to this discussion:

Clause 9: Threat Analysis and Risk Assessment (TARA)

Clause 9 defines the TARA methodology, which is the systematic process for identifying assets, analyzing threats and attack paths, assessing the feasibility of attacks, and determining the impact of successful exploitation. The output of TARA is a set of risk values for each identified threat scenario. Where the assessed risk exceeds the organization’s risk acceptance threshold, clause 9 requires a risk treatment decision. The four risk treatment options are: avoiding the risk (by removing the feature or asset), reducing the risk (by implementing countermeasures), sharing the risk (by contractual or insurance mechanisms), or retaining the risk (by accepting it with justification). When the decision is to reduce the risk, the standard requires defining cybersecurity goals — high-level statements of what the risk reduction must achieve.

Clause 10: Cybersecurity Concept

Clause 10 takes the cybersecurity goals produced by clause 9 and translates them into an actionable cybersecurity concept. The cybersecurity concept consists of cybersecurity requirements that specify how each goal will be achieved at the system or component level. Requirements are allocated to specific elements of the system architecture, are sufficiently detailed to be implementable and verifiable, and maintain explicit traceability back to the goals they satisfy. The cybersecurity concept also includes requirements for validation and verification methods that will be used to confirm that the requirements are met.

Think of it this way: clause 9 answers the question “What must we protect against?” while clause 10 answers “How exactly will we protect against it?” Goals state the security objective; requirements specify the technical mechanism.

What Is a Cybersecurity Goal?

A cybersecurity goal is a high-level, solution-independent statement of the security property that must be maintained for a specific asset in the context of a specific threat scenario. Goals are derived directly from the risk assessment: when TARA identifies that a particular attack path poses an unacceptable risk, the cybersecurity goal captures the defensive intent without prescribing a specific technical approach.

Characteristics of Well-Formed Goals

• Asset-specific: A goal references the asset or function being protected. For example, “Prevent unauthorized modification of firmware on the telematics control unit” identifies both the asset (firmware) and the component (telematics control unit).
• Threat-linked: A goal is always traceable to a specific threat scenario identified in TARA. It does not exist in isolation — it exists because a concrete risk was assessed and found to require treatment.
• Solution-independent: A goal states what must be achieved, not how. “Prevent unauthorized CAN bus access” is a goal. “Implement CAN message authentication using CMAC” is a requirement. The goal does not foreclose on implementation options.
• Tied to a Cybersecurity Assurance Level (CAL): ISO/SAE 21434 assigns a CAL (1 through 4) based on the assessed risk. The CAL associated with a goal determines the rigor of the engineering process applied to the requirements and verification activities that flow from it. Higher CAL means more rigorous analysis, testing, and documentation.
• Expressed in terms of security properties: Goals typically reference one or more of the classical security properties: confidentiality, integrity, availability, and authenticity. For example, “Ensure the integrity of diagnostic messages received by the gateway ECU” explicitly targets the integrity property.

Examples of Cybersecurity Goals

• “Prevent unauthorized access to the in-vehicle CAN bus network from external interfaces.”
• “Ensure the authenticity of over-the-air software update packages before installation on any ECU.”
• “Maintain availability of the braking system communication channel under denial-of-service conditions.”
• “Protect the confidentiality of personally identifiable information stored in the infotainment system.”
• “Prevent unauthorized modification of safety-critical calibration parameters in the engine control unit.”

Notice that none of these goals mention specific protocols, algorithms, key lengths, or implementation mechanisms. They define the security boundary that must be maintained, leaving the how to the requirements phase.

What Is a Cybersecurity Requirement?

A cybersecurity requirement is a specific, implementable, and verifiable statement that defines the technical or procedural mechanism by which a cybersecurity goal will be achieved. Requirements belong to the cybersecurity concept (clause 10) and must be allocated to specific components or subsystems in the system architecture. Unlike goals, requirements are solution-specific — they prescribe concrete technical measures.

Characteristics of Well-Formed Requirements

• Traceable to a goal: Every requirement must have a clear, documented link to one or more cybersecurity goals. This traceability is audited during CSMS certification and type approval.
• Allocated to architecture elements: A requirement must specify which component, subsystem, interface, or layer of the E/E architecture is responsible for fulfilling it. “The gateway ECU shall validate CMAC tags on all CAN messages received from the external diagnostic interface” is allocated to the gateway ECU.
• Specific and measurable: Requirements use precise, testable language. Instead of “strong encryption,” a requirement specifies “AES-128-GCM encryption” or “TLS 1.3 with ECDHE key exchange.” The requirement must be verifiable through testing, analysis, or inspection.
• Solution-dependent: Unlike goals, requirements commit to a specific technical approach. This is intentional — the purpose of the requirements phase is to make implementation decisions and document them precisely enough that development teams can build and testers can verify.
• Classified by type: ISO/SAE 21434 distinguishes between cybersecurity requirements at different levels. There are high-level cybersecurity requirements (part of the cybersecurity concept), which may be decomposed into detailed cybersecurity requirements during component-level design. Additionally, requirements may cover technical controls, process controls, or operational controls.

Examples of Cybersecurity Requirements

• “The gateway ECU shall authenticate all CAN messages received on the external diagnostic port using CMAC with AES-128 and 64-bit truncated tags, rejecting any message with an invalid or missing authentication code.”
• “The OTA update client shall verify the Ed25519 signature and SHA-256 hash of each firmware image against the OEM root certificate before initiating the installation process. If verification fails, the update shall be rejected and a security event shall be logged.”
• “The CAN bus arbitration controller shall implement message rate limiting at 500 messages per second per source ID, dropping excess messages and generating a diagnostic trouble code (DTC) when the rate limit is exceeded for more than 2 consecutive seconds.”
• “The infotainment system shall encrypt all PII at rest using AES-256-GCM with keys stored in the hardware security module (HSM), and shall erase all PII upon factory reset or ownership transfer.”
• “The engine ECU shall store calibration parameters in write-protected flash memory accessible only through authenticated diagnostic sessions using security access level 0x27 with a challenge-response protocol based on AES-128.”

Goals vs. Requirements: A Detailed Comparison

The following table summarizes the key differences between cybersecurity goals and cybersecurity requirements across multiple dimensions. This comparison is useful for engineering teams who need a quick reference during TARA workshops and cybersecurity concept development sessions.

The Derivation Flow: From Risk to Goal to Requirement

Understanding the derivation flow is essential for producing a coherent cybersecurity case. The flow follows a logical chain from asset identification through to verifiable requirements:

Step 1: Asset Identification

The TARA process begins by identifying assets — the items, functions, or data that have cybersecurity relevance. An asset is anything whose compromise could affect safety, operational capability, financial interests, or privacy. Examples include the CAN bus communication channel, the OTA update mechanism, the diagnostic interface, the telematics gateway, and stored personal data. Each asset is characterized by the security properties that matter for it: confidentiality, integrity, availability, and authenticity.

Step 2: Threat Scenario Identification

For each asset, the TARA team identifies threat scenarios — credible ways in which an attacker could compromise the relevant security properties. Threat identification typically uses STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) or similar methodologies applied to each asset and its interfaces. A threat scenario describes the attacker’s objective, the attack vector, and the consequence of successful exploitation.

Step 3: Attack Feasibility and Impact Assessment

Each threat scenario is assessed for attack feasibility (how difficult is it to execute the attack, considering required expertise, equipment, knowledge of the target, and window of opportunity) and impact (what are the consequences in terms of safety, financial loss, operational disruption, and privacy violation). The combination of feasibility and impact produces a risk value.

Step 4: Risk Treatment Decision

For each threat scenario whose risk value exceeds the acceptance threshold, the team selects a risk treatment option. When the decision is to reduce risk, one or more cybersecurity goals are formulated. Each goal addresses a specific threat scenario and states the security property that must be maintained for the affected asset. The goal is assigned a Cybersecurity Assurance Level (CAL) based on the assessed risk, which determines the rigor of subsequent engineering activities.

Step 5: Cybersecurity Concept Development

The cybersecurity concept takes each goal and derives one or more cybersecurity requirements that specify how the goal will be achieved within the constraints of the system architecture. This is where engineering decisions are made: which cryptographic algorithm to use, where to place security controls in the architecture, what monitoring mechanisms to deploy, and how to handle security events. Each requirement is allocated to a specific component and must be verifiable through defined test methods.

Step 6: Traceability and Completeness Verification

The final step is verifying that every cybersecurity goal is fully covered by one or more requirements, that every requirement traces back to at least one goal, and that no goals are left without implementation. This bidirectional traceability is a core audit artifact and a prerequisite for demonstrating compliance with ISO/SAE 21434 and UNECE R155.

Common Mistakes and How to Avoid Them

In our experience working with automotive OEMs and Tier-1 suppliers, the following mistakes occur repeatedly when teams transition from TARA to cybersecurity concept:

Mistake 1: Writing Requirements as Goals

This is the most common error. Teams write goals that are too specific, effectively embedding implementation decisions in the risk assessment phase. For example, writing “Implement SecOC on all CAN messages” as a goal skips the architectural analysis that should inform the choice of SecOC versus other authentication mechanisms. It also creates a problem if the architecture later changes — because the “goal” is now tied to a specific technology, changing the implementation requires re-doing the risk assessment, which is unnecessary overhead.

Fix: Keep goals at the “what” level. The correct goal would be “Ensure authenticity and integrity of CAN messages on safety-critical communication channels.” The choice of SecOC is a requirement-level decision made during cybersecurity concept development.

Mistake 2: Writing Goals as Requirements

The inverse error is writing requirements that are too vague to be implementable or testable. “The system shall be secure against network attacks” is not a requirement — it is an aspiration. It cannot be allocated to a specific component, it cannot be tested (what constitutes “secure”?), and it does not reference any specific mechanism. If your requirements team cannot write a test case for a requirement, the requirement is too abstract and is actually a goal that needs further decomposition.

Fix: Apply the “can I write a test for this?” litmus test to every requirement. If the answer is no, the statement is still at the goal level and needs to be decomposed into specific, testable requirements.

Mistake 3: Missing Traceability Links

Some teams produce goals and requirements in separate documents or tools without maintaining explicit links between them. During audits, the assessor will ask “which requirements implement this goal?” and “which goal does this requirement trace to?” If the answer requires manual searching through spreadsheets, the traceability is insufficient. This is not just a documentation issue — missing traceability usually indicates that goals and requirements were developed independently, which means there may be gaps where goals have no implementing requirements or requirements exist without a risk justification.

Fix: Use a requirements management tool (or a purpose-built TARA platform like ThreatZ) that enforces bidirectional traceability between goals and requirements. Generate traceability matrices automatically and review them for completeness at every milestone.

Mistake 4: One-to-One Mapping Assumption

Teams often assume that each goal maps to exactly one requirement and vice versa. In practice, the relationship is many-to-many. A single goal like “Prevent unauthorized access to the CAN bus from external interfaces” may require multiple requirements: firewall rules at the gateway, authentication on the diagnostic port, intrusion detection on the CAN bus, and network segmentation between domains. Conversely, a single requirement like “Deploy a hardware security module in the telematics ECU” may contribute to satisfying multiple goals related to key storage, authentication, and secure boot.

Fix: Model the goal-to-requirement relationship as a many-to-many mapping. Document which requirements contribute to which goals and ensure that the combined set of requirements for each goal provides complete coverage of the goal’s intent.

Mistake 5: Ignoring CAL Propagation

The Cybersecurity Assurance Level assigned to a goal determines the rigor of the engineering process for its derived requirements. If a goal is assigned CAL 4 (highest rigor), then the requirements derived from it must be developed, verified, and documented with CAL 4 rigor — which includes specific requirements for verification methods, independence of verification activities, and documentation depth. Teams that ignore CAL propagation may apply insufficient verification rigor to high-risk requirements, creating compliance gaps.

Fix: Ensure that CAL values propagate from goals to all derived requirements, and that the verification plan for each requirement matches the required CAL level. When a requirement satisfies multiple goals with different CALs, the requirement inherits the highest CAL.

Mistake 6: Treating Goals as Static After TARA

Some teams treat cybersecurity goals as frozen artifacts that never change after the initial TARA is complete. In reality, goals may need to be updated when the system architecture changes (new interfaces, new ECUs, new communication channels), when new threat intelligence emerges (new attack techniques, new vulnerability classes), when the risk assessment is re-evaluated based on field data, or when regulatory requirements change. ISO/SAE 21434 requires continuous cybersecurity activities across the product lifecycle, which includes re-evaluating and updating goals as needed.

Fix: Establish a change management process for cybersecurity goals that triggers re-evaluation when architectural changes, new threats, or regulatory updates occur. Ensure that goal changes propagate to affected requirements through the traceability chain.

Practical Example: End-to-End Walkthrough

To illustrate the full derivation flow, let us walk through a concrete example from asset identification to requirement specification.

Asset: CAN Bus Communication on External Diagnostic Interface

The vehicle’s OBD-II port provides access to the CAN bus for diagnostic purposes. This is an asset because the CAN bus carries safety-critical messages (braking, steering, powertrain control), and the OBD-II port is physically accessible to anyone with access to the vehicle interior.

Threat Scenario: Unauthorized CAN Message Injection via OBD-II

An attacker connects a malicious device to the OBD-II port and injects fabricated CAN messages to manipulate vehicle behavior. This could cause unintended acceleration, braking, or steering inputs. The attack requires physical access to the vehicle (which is readily available in many scenarios: rental cars, fleet vehicles, valet parking) and commercially available CAN bus attack tools.

Risk Assessment

Attack feasibility is rated as “high” (low expertise and equipment required, widely documented attack techniques, no time window restriction once physical access is obtained). Safety impact is rated as “severe” (potential for life-threatening vehicle behavior). The combined risk value exceeds the acceptance threshold. Risk treatment decision: reduce risk. CAL assignment: CAL 3 (high rigor based on safety-severe impact).

Cybersecurity Goal (Clause 9 Output)

CG-014: “Prevent unauthorized injection of CAN messages into safety-critical domains via the external diagnostic interface.”

This goal is solution-independent. It does not specify the mechanism — only the defensive objective. It traces to the identified threat scenario and carries CAL 3.

Cybersecurity Requirements (Clause 10 Output)

The cybersecurity concept derives the following requirements from CG-014:

• CR-014.1: “The gateway ECU shall implement network segmentation between the diagnostic CAN domain and all safety-critical CAN domains (powertrain, chassis, ADAS), with message forwarding controlled by a configurable whitelist.”
• CR-014.2: “The gateway ECU shall authenticate all CAN messages received from the diagnostic port using SecOC with CMAC-AES-128 and 64-bit freshness values before forwarding them to safety-critical domains.”
• CR-014.3: “The gateway ECU shall enforce rate limiting on the diagnostic CAN interface at a maximum of 200 messages per second, dropping excess messages and logging a security event (DTC 0xD001) when the limit is exceeded.”
• CR-014.4: “The intrusion detection system shall monitor the diagnostic CAN interface for message patterns inconsistent with legitimate diagnostic sessions (UDS protocol violations, unexpected arbitration IDs, anomalous message timing) and generate a high-priority alert within 500 ms of detection.”

Each requirement is specific, allocated to a component (gateway ECU, IDS), testable, and traceable to CG-014. Together, the four requirements implement a defense-in-depth strategy for the single goal. The verification plan for each requirement must meet CAL 3 rigor, including independent testing and formal review of test results.

The Role of CAL in Bridging Goals and Requirements

The Cybersecurity Assurance Level is the mechanism that connects the severity of a risk (assessed at the goal level) to the engineering rigor applied to the requirements and their verification. ISO/SAE 21434 defines four CAL levels:

• CAL 1 (Low): Basic cybersecurity engineering processes. Verification by review or analysis is generally sufficient. Documentation requirements are minimal beyond standard engineering records.
• CAL 2 (Medium): Structured cybersecurity engineering with defined methods. Verification includes testing in addition to review. Documentation must demonstrate method application and results.
• CAL 3 (High): Rigorous cybersecurity engineering with semi-formal methods. Verification requires independent testing (tester is different from developer). Documentation must include detailed analysis of security properties and test coverage arguments.
• CAL 4 (Highest): Highly rigorous cybersecurity engineering with formal or semi-formal methods. Verification requires independent testing with formal coverage criteria. Documentation includes formal security arguments and comprehensive evidence packages.

The CAL assigned to a cybersecurity goal flows down to all requirements derived from that goal. If a single requirement satisfies multiple goals with different CALs, the requirement inherits the highest CAL among them. This ensures that the most safety-critical aspects of the system receive the most rigorous engineering treatment.

Tool Support: From Spreadsheets to Integrated Platforms

Many organizations begin their ISO/SAE 21434 journey using spreadsheets for TARA and requirements management. While spreadsheets can work for small projects, they break down quickly as the number of assets, threat scenarios, goals, and requirements grows. Common problems with spreadsheet-based approaches include:

• Traceability fragility: Links between goals and requirements are maintained through manual cross-references that break when rows are inserted, deleted, or reordered.
• Version control chaos: Multiple team members editing the same spreadsheet leads to merge conflicts, lost changes, and inconsistent data.
• CAL propagation gaps: CAL assignments must be manually tracked and updated, leading to stale or incorrect CAL values on requirements.
• Audit readiness deficit: Generating traceability matrices, completeness reports, and change history from spreadsheets requires manual effort that delays audits.
• Reuse limitations: Goals and requirements from previous projects cannot be easily searched, adapted, or reused for new vehicle programs.

Purpose-built TARA platforms like ThreatZ address these problems by providing an integrated environment where assets, threats, risk assessments, goals, and requirements exist in a connected data model with enforced traceability, automatic CAL propagation, version-controlled change history, and audit-ready report generation. When a goal is created in ThreatZ, the platform ensures that it is linked to its source threat scenario and prompts the user to create derived requirements. When a requirement is created, the platform validates that it traces to at least one goal and inherits the correct CAL.

Goals and Requirements in the Broader Cybersecurity Case

The cybersecurity case is the structured argument, supported by evidence, that a vehicle item achieves an adequate level of cybersecurity. Both cybersecurity goals and requirements are essential elements of this argument:

• Goals provide the bridge between risk assessment and security architecture. They demonstrate that every identified risk above the acceptance threshold has been addressed with a clear defensive intent.
• Requirements provide the bridge between defensive intent and implementation. They demonstrate that every goal has been decomposed into specific, implementable, and verifiable technical measures.
• Traceability between goals and requirements demonstrates completeness: no risks are left untreated, and no requirements exist without risk justification.
• Verification evidence tied to requirements demonstrates that the implemented system actually achieves the stated goals. Test reports, analysis results, and inspection records are linked to specific requirements, which in turn link to goals and risk assessment results.

During a type approval audit or CSMS certification assessment, the auditor will walk through this chain: from identified risks to goals to requirements to verification evidence. Any break in the chain — an untreated risk, an unsatisfied goal, an unverified requirement — is a non-conformity that must be resolved before certification can proceed.

Relationship to Other Standards and Frameworks

The goals-vs-requirements distinction in ISO/SAE 21434 aligns with similar concepts in other standards used in automotive cybersecurity:

• UNECE R155: The regulation requires OEMs to demonstrate that identified risks are mitigated. The cybersecurity goals serve as the mitigation objectives, and requirements serve as the mitigation measures. The regulation’s Annex 5 threat catalogue maps directly to goal-level statements.
• ISO 26262 (Functional Safety): The concept of safety goals (derived from hazard analysis) and functional safety requirements (derived from safety goals) follows the identical pattern. Teams experienced with ISO 26262 will find the ISO/SAE 21434 approach familiar, and organizations often develop their cybersecurity goals and requirements using the same processes and tools as their safety goals and requirements.
• NIST Cybersecurity Framework: The NIST CSF “Protect” function outcomes align conceptually with cybersecurity goals (desired security properties), while the informative references and implementation tiers align with requirements (specific controls and maturity levels).
• ASPICE for Cybersecurity: The Automotive SPICE cybersecurity extension (ASPICE SEC) evaluates the process quality of goal derivation and requirement specification as separate process areas, reinforcing the distinction between the two activities.

Key Takeaways

• Cybersecurity goals (clause 9) are high-level, solution-independent statements of what must be protected. They are derived from risk assessment and assigned a Cybersecurity Assurance Level.
• Cybersecurity requirements (clause 10) are specific, implementable, and verifiable statements of how goals will be achieved. They are allocated to architecture components and tested against defined criteria.
• The relationship between goals and requirements is many-to-many: one goal may require multiple requirements, and one requirement may satisfy multiple goals.
• Common mistakes include writing goals that are too specific (embedding solutions), writing requirements that are too vague (not testable), and losing traceability between them.
• CAL propagation from goals to requirements ensures that engineering rigor matches risk severity throughout the development lifecycle.
• Tool support with enforced traceability, automatic CAL propagation, and audit-ready reporting is essential for managing the goal-to-requirement chain at scale.
• The goals-requirements distinction is not unique to ISO/SAE 21434 — it mirrors established patterns in ISO 26262, UNECE R155, and ASPICE, making it a fundamental skill for automotive cybersecurity engineers.