ISO/SAE 8475: Cybersecurity Assurance Levels (CAL) and Targeted Attack Feasibility Explained

Every team that has completed a Threat Analysis and Risk Assessment under ISO/SAE 21434 knows the moment the methodology goes quiet. The TARA says a threat scenario carries high impact and a plausible attack path. The Risk Treatment decision says reduce the risk. Then someone asks the question the standard never quite answers: how much engineering rigor does this item actually deserve? Should Verification stop at requirements-based testing, or extend to weeks of independent Penetration Testing? Does the review need to leave the project team? ISO/SAE 21434 gestures at an answer through an informative annex. ISO/SAE 8475 exists to answer it properly.

Publication status as of 17 July 2026: the ISO catalogue lists ISO/SAE DPAS 8475 as under development at stage 50.20 — the final approval phase. The final text is registered and publication is expected imminently. This post will be updated when the final document is released.

What ISO/SAE 8475 Is — and Where It Comes From

ISO/SAE 8475, titled “Road vehicles — Cybersecurity Assurance Levels (CAL) and Targeted Attack Feasibility (TAF),” is developed by ISO/TC 22/SC 32 jointly with SAE International — the same joint working group that produced ISO/SAE 21434. It is being released as a Publicly Available Specification (PAS), a faster publication route that gets a stable, citable document into industry hands without waiting for a full International Standard cycle.

The CAL concept is not new. ISO/SAE 21434:2021 introduced it in Annex E — an informative annex — as a classification scheme with four numbered levels, CAL1–CAL4, derived from the impact and attack vector of threat scenarios at the concept stage. Because Annex E was informative, it standardized neither how to assign a CAL nor what a given CAL obliges you to do. Adoption was accordingly uneven: some OEMs began writing CAL requirements into sourcing documents, while many programmes ignored the concept entirely. ISO/SAE 8475 closes that gap. It makes the scheme prescriptive — defining the levels, the basis for assigning them, and what each level means for engineering rigor — and it consolidates the four numbered levels into three named ones.

The timing matters. A second edition of ISO/SAE 21434 is expected to start development in 2026 on a roughly three-year track, which points at publication around 2029. Publishing CAL and TAF as a PAS now gives OEMs and Tier-1 suppliers a usable reference years ahead of that cycle — and almost no explainer content exists for it yet, which is why CAL requirements arriving in RFQs tend to catch supplier teams unprepared.

The Three Cybersecurity Assurance Levels

ISO/SAE 8475 defines three CALs: Basic, Intermediate, and Advanced. A CAL is not a risk value and not a security rating of the product. It is an assurance dial — a statement of how much confidence the engineering process must generate that the cybersecurity work was done well. Two items can face similar threats yet warrant different CALs because the consequences of getting one of them wrong are far worse.

What actually changes as the level rises? Four things, applied across the ISO/SAE 21434 lifecycle:

Activities. Which assurance activities the Cybersecurity Plan must include at all. A Basic item may be covered by requirements-based security testing; an Advanced item adds systematic fuzzing campaigns and full attack-path-driven Penetration Testing.

Depth. How far each activity goes. Scanning an interface for known vulnerabilities, fuzzing its protocol implementation, and attempting exploit development against it are the same activity — Verification — performed at three very different depths.

Formality. What the evidence looks like. Engineering notes and test logs may carry a Basic item; an Advanced item needs structured, auditable evidence that can stand inside a Cybersecurity Case presented for Type Approval.

Independence. Who checks the work. At the low end, reviews stay within the project team. As the CAL rises, review and assessment move to people organizationally independent of the developers — mirroring the confirmation measure logic that ISO 26262 applies as ASIL rises from A to D.

Targeted Attack Feasibility: A Target, Not a Rating

The second concept in ISO/SAE 8475 is Targeted Attack Feasibility. The name invites confusion with the Attack Feasibility rating every TARA already produces, so the distinction is worth stating precisely.

In a TARA, Attack Feasibility is descriptive. You analyse an attack path against the item as designed and rate how easy it is to execute — using the attack-potential, CVSS-based, or attack-vector approaches that ISO/SAE 21434 Clause 15 offers. The rating reflects the current state of the design and the current state of attacker knowledge, and it feeds risk determination.

TAF is prescriptive. It expresses the intended level of attack feasibility — the bar an item should present to an attacker once its cybersecurity controls are in place. Where an Attack Feasibility rating answers “how easy is this attack today?”, TAF answers “how difficult must every remaining attack be before we accept this item?” It is a design target, set early, that controls are then engineered to meet.

The two concepts complement each other across the lifecycle. TAF gives Verification an acceptance criterion: a Penetration Testing campaign is no longer just a hunt for findings, it is a check that no demonstrated attack path undercuts the targeted feasibility level. And the pair divides labour cleanly with CAL: the CAL scales how rigorously the engineering process must work, while TAF sets the technical bar the engineered product must reach.

How CAL Assignment Flows From the TARA

CAL assignment is not a fresh analysis. It reuses information the concept-stage TARA already produces — which is exactly how Annex E framed the idea. The chain looks like this: the item definition scopes assets and interfaces; damage scenarios carry impact ratings across safety, financial, operational, and privacy categories; threat scenarios carry the attack vector through which they can be realized. Impact and attack vector — both available before any architecture is frozen — are the inputs from which a CAL is derived. High-impact scenarios reachable through remote attack vectors push an item toward Advanced; limited-impact scenarios requiring physical access stay near Basic.

Assigning the CAL that early is the point. The CAL shapes the Cybersecurity Plan, the depth of Verification activities, the independence of reviews, and the effort a supplier must quote — so it has to exist before development contracts are signed. In practice the CAL travels with the item into Cybersecurity Interface Agreements, where it tells a Tier-1 supplier not just what to build but how much assurance evidence to return. If you want a refresher on the analysis that produces these inputs, our primer on TARA for automotive systems walks the full method step by step.

The uncomfortable implication: your CAL rationale is only as defensible as the TARA underneath it. An assessor reviewing a CAL claim will walk the traceability chain — damage scenario to impact rating to threat scenario to attack vector to assigned level. Impact ratings without argued justification, or attack vectors assigned by habit rather than analysis, turn into CAL disputes at the worst possible time: during assessment, with contracts and Type Approval timelines already committed.

What OEMs and Tier-1s Should Do Now

Inventory where CAL already touches you. Search current RFQs, customer requirements, and Cybersecurity Interface Agreements for CAL references. Some OEMs have required CALs since Annex E appeared; those requirements will migrate to ISO/SAE 8475 terminology once the PAS publishes.

Pilot CAL assignment on one live item. Take a completed TARA and derive CALs from its impact ratings and attack vectors. The exercise costs days, exposes whether your TARA records the inputs cleanly, and produces a worked example your teams can standardize on.

Tighten Attack Feasibility rationale. TAF makes feasibility a contractual target, not just an analysis output. Ratings backed by explicit attack-potential reasoning will survive that shift; gut-feel ratings will not.

Decide review independence per level. Map who in your organization can review and assess at each CAL. Advanced items will need reviewers outside the developing team — a staffing question that takes quarters, not weeks, to solve.

Track publication, then baseline. When the final document lands, reconcile your scheme against it and fix your terminology. Teams building structured TARA practice now — our Automotive TARA solution outlines the approach we use — will absorb the PAS as an increment, not a restart.

For teams using KAVACH, the CAL conversation starts from a useful position: the workspace keeps damage scenarios, impact ratings, threat scenarios, attack vectors, and Attack Feasibility rationale linked as structured, traceable Work Products rather than scattered spreadsheet rows. That traceability chain — from impact and attack vector down to each treatment decision — is precisely the evidence a CAL assignment rests on, so the rationale an assessor asks for already exists as connected records instead of a reconstruction exercise.

Frequently Asked Questions

What is ISO/SAE 8475?ISO/SAE 8475, titled “Road vehicles — Cybersecurity Assurance Levels (CAL) and Targeted Attack Feasibility (TAF),” is a Publicly Available Specification developed by ISO/TC 22/SC 32 jointly with SAE International. It turns the informative CAL concept from ISO/SAE 21434:2021 Annex E into a prescriptive scheme: three assurance levels that scale the rigor of cybersecurity engineering activities, plus TAF as a target for the attack resistance an item should achieve. As of 17 July 2026 it is at the final approval stage (ISO stage 50.20), with publication expected imminently.

What is the difference between CAL and ASIL? ASIL A–D from ISO 26262 classifies safety risk using severity, exposure, and controllability, and scales the rigor of Functional Safety activities. CAL is the cybersecurity counterpart in spirit — it also scales engineering rigor — but it is derived from concept-stage TARA information such as impact and attack vector, and it addresses an intelligent adversary rather than random hardware faults or systematic errors. A CAL is not a risk value and does not replace the risk determination performed in a TARA.

Is ISO/SAE 8475 mandatory? No. It is a voluntary Publicly Available Specification, and UNECE R155 does not reference it. Adoption is likely to follow the ISO/SAE 21434 pattern: OEMs write it into sourcing requirements and Cybersecurity Interface Agreements, and assessors use it as the reference for how much rigor a given item deserves.

How many CALs does ISO/SAE 8475 define? Three — Basic, Intermediate, and Advanced. Each level scales four dimensions of assurance: which activities are performed, the depth to which they are performed, the formality of the resulting evidence, and the independence of the people who review or assess the work. This is a consolidation of the four numbered levels (CAL1–CAL4) that ISO/SAE 21434 Annex E sketched informatively.

For the full clause-by-clause treatment of the standard that ISO/SAE 8475 builds on, see our ISO/SAE 21434 Guide.