ISO/SAE 21434 Attack Feasibility: Choosing a Method You Can Defend

Two engineers assess the same diagnostic programming attack. One chooses High feasibility. The other selects Low. Both write a short comment. Neither records the scoring inputs. A risk matrix cannot settle that disagreement without an agreed method and evidence.

Attack feasibility is a structured engineering judgement. ISO/SAE 21434 Annex G describes guidance for rating feasibility, including an attack-potential method, a CVSS-based method and an attack-vector-based method. ¹ The engineering team needs to choose and document the method used for each assessment.

Start with a credible attack path

A path should describe the attacker, access point, target asset and necessary steps. Example: a service technician's diagnostic route reaches an ECU's programming function. The attacker seeks unauthorized firmware modification.

Do not assign feasibility from the threat title alone. “Firmware modification” describes an objective, not the effort required to reach it. The engineer needs to inspect routing, access controls, required tools and implementation assumptions.

Record alternative paths separately. Physical debug access and remote diagnostic access have different prerequisites. Combining them into one average rating hides a material difference.

Understand attack potential

The attack-potential method considers five factors: elapsed time, specialist expertise, knowledge of the target, window of opportunity and equipment. The factors describe attacker effort under a defined scenario.

A scoring table maps the selected factor values into an attack-potential band and feasibility rating. The precise mapping belongs to the approved method version. Do not copy numeric thresholds from an old spreadsheet without checking the organization's selected scheme.

An assessor should see each factor and its rationale. “Specialized equipment” needs a description of what equipment is required and why a standard diagnostic interface is insufficient. “Restricted knowledge” needs a defensible account of what technical information the attacker lacks.

Know where CVSS fits

CVSS scores communicate vulnerability characteristics. FIRST warns that the Base score measures severity rather than deployment-specific risk. ² A CVSS-based feasibility method still needs a defined mapping and a credible attack scenario.

Avoid taking a published CVSS Base score and directly calling it the vehicle's TARA risk. A component vulnerability can be irrelevant to the deployed firmware. A reachable diagnostic service can create a meaningful threat without a public CVE.

Where CVSS metrics inform an assessment, retain the full vector and method version. The numeric score alone hides the selected assumptions.

Use an attack-vector method deliberately

An attack-vector method groups routes by how an attacker reaches the target. Physical contact, local network access and remote access create different conditions. The selected categories need definitions that match the product context.

This method is useful for high-level screening, but a broad label can omit important prerequisites. A physically accessible interface can demand specialized credentials. A network route can sit behind several independently tested controls. Use the method for its intended level of analysis.

If the assessment needs detailed reasoning about attacker effort, the attack-potential method can offer richer evidence. The right choice follows the project process and the evidence available.

Keep impact separate from feasibility

Impact asks what damage results from a successful attack. Feasibility asks how plausible the attack path is under the selected method. A severe safety consequence does not prove a high likelihood of exploitation.

Record the four SFOP impact categories under your approved scale. Link each damage scenario to the affected asset. Then combine impact and feasibility through the documented risk matrix. A reviewer should be able to reproduce the risk rating from stored inputs.

A changed security control can alter feasibility. A changed vehicle function can alter impact. The tool needs to preserve which part of the assessment changed.

Make disagreements visible

If the imported workbook reports Medium but recalculated factors give Low, keep both. Label the difference as a method or data discrepancy. Record the engineer's resolution. Silent correction is not trustworthy engineering.

When a team changes its calculation method, preserve old results under their earlier method version. A later project revision can use a new method with explicit conversion rules. Do not rewrite historical approvals.

Demonstrate the calculation in QuickTARA

QuickTARA records attack paths, assessment inputs, feasibility and connected risks. During evaluation, ask for a complete calculation from factor values to decision and check the effect of a control on the residual assessment.

Book a QuickTARA feasibility-method demonstration. Bring one disputed risk case and use it to test whether the engineering reasoning remains visible.

Frequently asked questions

Is attack feasibility the same as vulnerability severity?

No. A CVSS Base score describes vulnerability severity. A TARA feasibility assessment evaluates a particular attack path under an explicit engineering method. ²

Can a team change feasibility methods mid-program?

It can adopt a revised assessment policy, but previous results need their original method and revision history. A new mapping should not silently rewrite historical decisions.