Cybersecurity Assurance Levels in Product Development Lifecycle

A Cybersecurity Assurance Level (CAL) is a rating from CAL1 to CAL4 that says how much rigor and independence the cybersecurity work on a vehicle item or component needs. In the example method of ISO/SAE 21434, you set it in the concept phase from the worst impact and the attack vector of the relevant threat scenarios, and it stays fixed while the design changes. A CAL leaves the choice of security controls to you; it sets how deeply you test for weaknesses and how independent the people checking the work should be.

CAL lives in Annex E of ISO/SAE 21434, the international standard for road vehicle cybersecurity engineering. That annex is informative, so the standard does not require you to use CALs. Many teams use them anyway because a shared number makes the conversation between a customer and a supplier much shorter. A companion Publicly Available Specification (PAS), ISO/SAE PAS 8475, turns the idea into something you can apply consistently. In this article we walk through what a CAL is, how to determine one, and what it changes in your testing and reviews.

What is a cybersecurity assurance level (CAL)?

A CAL is a statement of assurance: how confident you need to be that the protection of an item's assets was developed properly. Annex E describes four levels, and each step up asks for a meaningful increase in rigor across design, verification and cybersecurity assessment.

• CAL1: low to moderate cybersecurity assurance is required.
• CAL2: moderate cybersecurity assurance is required.
• CAL3: moderate to high cybersecurity assurance is required.
• CAL4: high cybersecurity assurance is required.

To make that concrete, here is how the levels might fall for a few systems in a vehicle with automated driving. These are our illustrative examples, not the standard's, and the real answer depends on your architecture and your TARA (Threat Analysis and Risk Assessment).

• Infotainment, CAL1: in an architecture where it is well separated, a compromise has little effect on safety or critical functions.
• Tire pressure monitoring, CAL2: false readings could lead a driver into unsafe decisions.
• Vehicle-to-vehicle communication, CAL3: forged messages could contribute to a collision.
• Automated driving controls, CAL4: a compromise could have catastrophic consequences.

How to determine a CAL from your TARA

A CAL is related to risk, but you cannot read it straight off a risk value. The standard explains why: a risk value moves as the specification, design, implementation and operating environment change, while a CAL is meant to stay fixed until the end of cybersecurity support. So you determine it at the start, in the concept phase, from parameters that are not expected to change, before any security controls are counted.

Those two parameters are the maximum impact and the attack vector of the threat scenarios behind a cybersecurity goal. The impact rating comes from your TARA's impact ratings, and the attack vector is the static part of attack feasibility. Annex E gives this example matrix.

The attack vector columns use the attack vector-based approach in Annex G of ISO/SAE 21434, which rates feasibility by how remote the attacker can be:

• Network (high): the attack path is bound to the network stack without limitation, for example a cellular connection that puts the electronic control unit (ECU) on the internet.
• Adjacent (medium): the attack path is bound to the network stack but limited physically or logically, for example Bluetooth.
• Local (low): the attacker needs direct access to the item, for example a USB storage device or memory card.
• Physical (very low): the attacker needs physical access to realize the attack.

Notice what the matrix does. A severe-impact threat that needs physical access lands at CAL2, while a major-impact threat reachable over the network lands at CAL4. Reach matters as much as consequence.

If the impact is negligible, no CAL is assigned. That ties to a permission in the standard: for threat scenarios with a risk value of 1, conformity with the cybersecurity concept, product development and validation clauses may be omitted.

Once you have CALs for your threat scenarios, they flow through the design like this:

• When the risk treatment decision for a threat scenario is to reduce the risk, you specify a cybersecurity goal, and a CAL can be determined for it. If goals are combined, the combined goal takes the highest CAL.
• Cybersecurity requirements inherit the CAL of the goal they come from.
• A component that receives requirements with different CALs is assigned the highest one.
• If a component is confirmed as protected from the other components in the architecture, its CAL can be reduced or dropped, with a rationale.

If the treatment decision is where you are stuck, our piece on navigating the risk treatment decision in TARA covers that step.

How CAL scales testing and independence

The CAL is used to pick methods: how you develop and verify, how you hunt for weaknesses, and how the work is assessed. Annex E offers what follows as examples, so treat them as a starting point to agree with your customer or supplier.

Searching for weaknesses

At CAL1 and CAL2, analysis and testing search for vulnerabilities based on known information, such as public vulnerability databases. At CAL3 and CAL4, the search adds exploratory methods that look for weaknesses nobody has published yet. Testing also widens: CAL3 tests all interactions between components, and CAL4 tests all combinations of those interactions.

Testing parameters

Annex E sorts testing into two parameter sets. Set 1 is the baseline (fuzz testing with a random selection of inputs, penetration testing that assumes moderate attacker expertise). Set 2 goes further (more fuzz iterations or adaptive input selection, penetration testing that assumes higher attacker expertise, knowledge or resources).

• Functional testing: set 1 at CAL1 and CAL2, set 2 at CAL3 and CAL4.
• Vulnerability scanning: set 1 at every CAL.
• Fuzz testing: no suggestion at CAL1, set 1 at CAL2, set 2 at CAL3 and CAL4.
• Penetration testing: no suggestion at CAL1 and CAL2, set 1 at CAL3, set 2 at CAL4.

That is why it pays to know the CAL before you scope a test program. If you are weighing the two methods, see fuzz testing vs penetration testing in automotive cybersecurity.

Independence of the reviewer

Annex E uses three notations for who performs a check:

• I1: a different person from the one who created the work product.
• I2: a person independent from the team that created it, reporting to a different direct superior.
• I3: a person independent from the creating department in management, resources and release authority.

In the standard's example, verification of the concept and design, verification of implementation and integration, and cybersecurity validation are I1 at CAL1 and CAL2 and I2 at CAL3 and CAL4. The cybersecurity assessment gets no suggestion at CAL1, then I1 at CAL2, I2 at CAL3 and I3 at CAL4.

What ISO/SAE PAS 8475 adds

Annex E describes CAL at a high level and stops there. ISO/SAE PAS 8475, "Road vehicles: Cybersecurity Assurance Levels (CAL) and Targeted Attack Feasibility (TAF)," was written to fill that gap. ISO lists it at stage 60.00, under publication, since September 1, 2026. Until the published text is out, treat the details in any draft as subject to change.

The PAS also introduces Targeted Attack Feasibility (TAF): the attack feasibility a customer wants to reach after controls are applied. It gives a supplier a target to design toward when the customer does not hand over a complete list of controls. ISO registered the second edition of ISO/SAE 21434 as a new project in October 2026, and a December 2025 committee update said it will draw on the CAL and TAF work, so this vocabulary is likely to stick.

Using CAL across the supply chain

The standard suggests sharing a documented rationale for each CAL between customer and supplier, and the CAL scheme can be written into the cybersecurity interface agreement. That is where CAL pays off: a supplier who knows a component is CAL3 knows to plan exploratory weakness analysis, set 2 fuzz testing and a reviewer from another team before the first line of code. Our article on supplier management and ISO/SAE 21434 covers the interface agreement in more detail.

We have run nearly 400 TARAs across automotive, agriculture and robotics, and setting CALs is part of that work. If you have a cybersecurity goal and are not sure which CAL it needs or what testing it implies, send us a note and we will walk through it with you.

References

[1] ISO/SAE 21434:2021, Road vehicles: Cybersecurity engineering, Annex E and Annex G

[2] ISO/SAE PAS 8475, Road vehicles: Cybersecurity Assurance Levels (CAL) and Targeted Attack Feasibility (TAF)