CAL (Cybersecurity Assurance Level)

What is CAL?

A Cybersecurity Assurance Level (CAL) is a four-step classification, CAL 1 to CAL 4, that says how much assurance a cybersecurity goal needs and therefore how rigorous the engineering and testing behind it have to be. It plays a role similar to the ASIL in functional safety, but with one important difference: the CAL is informative guidance, not a normative requirement of ISO/SAE 21434.

Where is it defined?

ISO/SAE 21434:2021 Annex E, “Cybersecurity assurance levels”, describes the concept. Table E.1 derives the CAL from the impact rating of a threat scenario (the clause 15.5 rating) and the attack vector of the attack path (physical, local, adjacent, network). Table E.2 gives examples of how the rigour of methods may scale with the CAL, for instance in requirements verification, in the depth of integration testing and in the independence of validation. The standard allows a CAL to be assigned to a cybersecurity goal in the concept phase (clause 9) and carried down to the component.

UN R155 does not use the term. Its paragraph 7.3.6 simply requires the manufacturer to perform appropriate and sufficient testing to verify the effectiveness of the security measures, which in practice is where the CAL is used to argue what “sufficient” means.

What it means in practice

The CAL decides how deep a test programme has to go and who runs it. For a goal rated CAL 1 a review and functional tests of the security requirements may be enough. From CAL 2 upward, assessors expect fuzzing of the communication interfaces and vulnerability scanning, consistent with the recommendation [RC-10-12] in clause 10.4.2. At CAL 3 and CAL 4 they expect penetration testing by testers who are independent of the development team, named in clause 11 [RQ-11-01], with coverage across the whole attack surface and documented attack paths.

In the audit support we did for a Tier-1, the CAL argument was the first thing the assessor used to check the test plan: which goals carry which CAL, and does the test evidence for each goal match. A CAL 3 goal protected by SecurityAccess with no fuzzing results and no independent test was a gap, even though the service “worked”.

The CAL also sets priorities. An ECU reachable only over the physical CAN bus and an ECU reachable through a connected gateway over Ethernet may run the same software, but their attack vectors differ and so do their CALs and their test budgets.

How AutoST tests it

AutoST provides the repeatable part of the evidence that CAL 2 and higher demand: enumeration, SecurityAccess checks, UDS and CAN fuzzing with crash detection, DoIP and SOME/IP tests, with stored seeds, dated history and PDF and SARIF reports. For CAL 3 and 4 that is the baseline a penetration test builds on, not a replacement for one; the independence requirement is met by who runs the test, and AutoST does not change that.

Common misunderstandings

A CAL is not a certification and not a label an ECU “has”. It is assigned to a cybersecurity goal, and one ECU usually carries goals at several levels. And a high CAL does not make a weak control acceptable; it only raises the bar for how thoroughly that control has to be shown to work.