Cybersecurity Assurance Level (CAL) explained

What a CAL is — and what it is not

A Cybersecurity Assurance Level (CAL) is a way of scaling how much rigour a piece of cybersecurity work deserves. ISO/SAE 21434 defines four levels, CAL 1 to CAL 4, where a higher level calls for deeper analysis, more independent review, and more thorough verification. The idea is borrowed in spirit from the ASIL scheme in functional safety: not everything needs the same intensity of engineering, so you grade the effort to the stakes.

The most important thing to say about CAL is what it is not. It is informative in the standard, not normative — it is guidance, not a requirement. It is not a certificate, not a rating you display, and not a pass/fail grade. A component is not "CAL 3 compliant"; rather, an activity around a component is conducted at CAL 3 rigour. And UN R155 does not require any particular CAL. Reading CAL as a grade to be achieved is the most common mistake teams make with it.

How a CAL is derived

A CAL is determined during the concept phase, on the output of the TARA. Two factors drive it: the impact of the threat scenario and the attack vector — loosely, how severe the outcome is and how accessible the attack path is.

Factor	What it captures	Pushes CAL
Impact	Severity of the outcome across safety, financial, operational, privacy	Higher impact → higher CAL
Attack vector	Accessibility of the attack path (e.g. physical, local, adjacent, remote/network)	More accessible / remote → higher CAL

The intuition is straightforward. A severe outcome reachable remotely, over the network, with no special access is the sort of thing you want to engineer with the greatest care — a high CAL. A modest outcome reachable only with physical disassembly and specialist equipment warrants proportionately less — a lower CAL. Note that the CAL uses the attack vector rather than the full attack-feasibility rating; feasibility still feeds the risk determination in the TARA, but the CAL is a simpler, coarser dial set early to decide how hard to work.

What a higher CAL actually changes

Assigning a higher CAL does not change what a requirement says; it changes how much assurance you build around it. In practice a higher CAL tends to call for:

• more thorough and more independent review of work products;
• deeper analysis in the concept and design phases;
• more extensive verification and testing, including more adversarial testing;
• and stronger evidence that the activities were carried out and traced.

A lower CAL relaxes these proportionately. The point is efficiency with honesty: you spend your scarce senior review time where the stakes justify it, and you can say why. That "why" is the part an assessor cares about — a defensible rationale for the depth of work, applied consistently across the programme.

Where CAL sits in the lifecycle

CAL is set in the concept phase and then shapes everything downstream. It is decided alongside the cybersecurity goals, and it colours the cybersecurity concept, the requirements and the verification plan — the clauses we cover in Goals, claims and requirements. It is one of several informative devices in the standard that connect the risk picture to the engineering effort; the standard as a whole, and where CAL fits within it, is set out in ISO/SAE 21434 explained.

Because CAL is informative, organisations legitimately handle it in different ways. Some apply the standard's scheme as written. Some tailor the thresholds to their product lines. Some use an equivalent internal scheme and map it to CAL for communication. All of these are acceptable, provided the approach is documented and applied consistently. What is not acceptable is silence — depth of work that varies from item to item with no stated reason.

Common misunderstandings

Three recur. The first is treating CAL as a compliance target — "we must reach CAL 4" — when it is a rigour dial, not a hurdle. The second is confusing CAL with risk: a high risk is something you must treat, whereas a high CAL is a statement about how carefully you engineer, and the two do not move in lockstep. The third is assigning CALs and then never letting them influence anything — a spreadsheet column that no reviewer, tester or requirement ever responds to. A CAL that changes no behaviour is decoration.

Used well, CAL is a quiet, practical tool. It lets a programme concentrate effort where it matters and gives an assessor a coherent explanation for why one item was pentested to exhaustion while another was reviewed and moved on. Used badly, it becomes a grade nobody needed.

The AutoSifu view

We use CAL the way the standard intends — as a rigour dial set from the TARA, documented and applied consistently, not as a badge. With CIRT (Pune) as our strategic partner, we run one route: build the concept and the assurance argument, solution the controls at the depth the stakes justify, and prepare the CoC and type-approval evidence with the approval body in the room. The question an assessor should be able to answer from our work is simple — why this much rigour here — and CAL is one of the tools that lets us answer it.