VWAY

Newsroom
Technical Resources


etc.[VisualPro Tech Brief] Expecting Attacks Within Three Years? When to Reopen Your TARA

VisualPro Tech Brief
Cover illustration on a dark green background: a vehicle stands on a platform with three bars in time order in front of it. A short green bar is followed by the tallest red bar and an orange bar, an OTA update signal comes down to the vehicle from the upper right, and an analysis document lies reopened in the foreground
Expecting Attacks Within Three Years? When to Reopen Your TARA
One public exploit moves a risk level from 2 to 5: reassessing post-production cybersecurity with VisualPro TARA
VWAY Tech Brief · November 4, 2026 · About 8 min read
TARAISO/SAE 21434Attack feasibilityRisk treatment decisionOTAPost-production security
November 4, 2026

01Summary

In a survey commissioned by QNX, 83% of 1,100 embedded automotive software developers said software-defined vehicles (SDVs) will become a major cyberattack target within three years. That figure is what developers expect, not a count of attacks. The question it raises is still clear. Vehicles stay on the road for well over a decade, so how long does a threat analysis and risk assessment (TARA) finished at start of production stay valid? Attack feasibility in a TARA is a judgment about how hard an attack is right now, and that judgment goes stale the moment attack code is published. We assessed a fictional telematics path in VisualPro TARA. When we reflected a published exploit, the total for one attack path fell from 27 points to 5 and the risk level rose from 2 to 5. The other path did not move. But the treatment decision still said "Retaining". The risk value is recalculated, but people have to make the decision again. This article sets out the signals that should reopen a TARA and which cells to look at when it does.

02What the 83% tells us and what it does not

QNX's "Under the Hood: SDV Developer Report" 2026 edition was fielded online by OnePoll from July 20 to August 4. The security figures are these.

FigureFinding
83%Expect SDVs to become a major cyberattack target within three years
48%Rank security threats as their top future concern (up 5 points on last year)
47%Name cyber vulnerabilities as the biggest risk to rolling out SDVs at scale
46%Name cybersecurity standards (UNECE WP.29, ISO/SAE 21434) as the hardest regulation to meet
79%Feel pressure from faster-moving competitors

Keep two things in mind when reading these. The survey was commissioned by a company that sells vehicle software, and respondents were paid to take part. And the 83% is a forecast by developers, not a statistic of attacks that happened. It does not mean 83% of vehicles will be attacked.

TheAutoExec's article on the survey goes a step further. Its author writes that manufacturers should be able to say how long a vehicle will receive security updates and how they respond when a vulnerability appears. That is the author's opinion, not a survey finding. For engineers, though, the question immediately turns into another one: is the risk assessment behind that answer still correct?

03A TARA at start of production rests on assumptions

ISO/SAE 21434 does not stop at concept and development. Its scope includes production, operation, maintenance and decommissioning. Clause 8 covers the activities that feed ongoing risk assessment and vulnerability management until the end of cybersecurity support, clause 13 covers incident response and updates, and clause 14 covers end of support and decommissioning. The cyber security management system under UN R155 also reaches the post-production phase.

Why does the assessment change after production starts? In the attack potential method, attack feasibility is the sum of five factors.

FactorWhat it asksOver time
Elapsed timeHow long does it take to find and carry out the attack?Drops sharply once attack code is published
Specialist expertiseWhat level of specialist is needed?Falls when tools appear
Knowledge of the item or componentHow hard is the target information to get?Falls as analysis material spreads
Window of opportunityHow much opportunity is there to reach the target?Gets easier as connected features grow
EquipmentWhat equipment is needed?Falls as equipment becomes common

A lower score means an easier attack. Most of the reasoning behind "this attack is hard" at start of production sits in these five cells, and all five change when the world outside the vehicle changes. The attack can get easier while the asset and the size of the damage stay the same.

04Example 1: when attack code is published

This is a fictional system for education (not the design of any vehicle or manufacturer). A telematics control unit (TCU) is connected to the cellular network and uses an open-source library in its network stack. An update manager verifies OTA packages with a signature verification key. There are two threats.

  • TH-1 Execute remote code through a TCU network stack vulnerability and send forged vehicle control messages (impact Severe)
  • TH-2 Read ECU memory through the diagnostic port, extract the signature verification key and install a forged update package (impact Major)

At start of production (T0), both threats were rated hard, because an attacker would have had to find the TH-1 vulnerability personally. Now assume that a vulnerability in the library the TCU uses, together with attack code, has been published (T1). The values of AP-1 change.

AP-1 factorT0 start of productionT1 after publicationWhy it changes
Elapsed time171Months to find it yourself, days to adapt public code
Specialist expertise63A proficient person can run it; no expert needed
Knowledge of the item or component30The information needed is now public
Window of opportunity11The cellular connection is unchanged
Equipment00Standard equipment is enough
Total275
Attack feasibilityVery LowHigh
Two VisualPro TARA attack feasibility screens stacked for comparison. At start of production AP-1 has elapsed time 17, expertise 6, knowledge 3, window 1 and equipment 0 for a total of 27, Very Low. After attack code is published AP-1 has 1, 3, 0, 1 and 0 for a total of 5, High, while AP-2 stays at a total of 38, Very Low at both points
VisualPro TARA attack feasibility screen at T0 and T1: only the AP-1 values change, and AP-2 stays at a total of 38, Very Low

Next is the risk calculation screen.

ThreatImpact ratingT0 feasibility · risk levelT1 feasibility · risk levelTreatment decision
TH-1SevereVery Low · 2High · 5Retaining (the decision made at T0, unchanged)
TH-2MajorVery Low · 1Very Low · 1Retaining
Two VisualPro TARA risk calculation and treatment decision screens stacked for comparison. At start of production TH-1 is Very Low, Severe, risk level 2, Retaining. After attack code is published TH-1 is High, Severe, risk level 5, but the treatment decision still reads Retaining, outlined in red. TH-2 is Very Low, Major, risk level 1, Retaining at both points
VisualPro TARA risk calculation and treatment decision screen at T0 and T1: the TH-1 risk level is now 5, but the treatment decision still reads "Retaining"

Two things stand out here.

First, there is no need to start over. What changed is the assessment of one attack path, and TH-2 stayed as it was. Once you know which asset and attack path a published vulnerability touches, the area to review narrows.

Second, the risk value is recalculated, but the decision does not change by itself. "Retaining" stays next to risk level 5. That decision was made when the risk level was 2. If nobody reopens it, the document goes on showing a stale decision as if it were still valid. A treatment decision is a judgment that carries responsibility, so a tool should not make it. That is why the procedure has to say who reviews it and when.

In this example we changed the TH-1 decision to "Reducing" and linked two cybersecurity goals to the attack path.

  • SG-1 Public vulnerabilities in the TCU network stack are resolved by an OTA patch within a defined period
  • SG-2 Only permitted control messages from the TCU pass through the gateway into the vehicle

The "defined period" in SG-1 is where this connects to the support commitment TheAutoExec's author asks about. To state a patch period and a support period, you need a risk assessment behind them.

05Example 2: when OTA adds a feature

The second signal comes from our own side, not from outside. Suppose a remote start feature is added over OTA after production starts (T2). The start-of-production TARA has neither the assets nor the attack paths for this feature. Correcting existing values is not enough; new entries are needed.

TARA itemWhat was added
AssetRemote start command authentication token (confidentiality, integrity)
Damage scenarioUnauthorized remote start leads to vehicle theft (Financial Major)
ThreatTH-3 An unauthorized user sends a start command by exploiting an authentication flaw in the remote start API
Attack pathAP-3 Analyze the API between app and server, forge the authentication token and send a remote start command
Attack feasibility · risk levelTotal 10 · High · 4
Treatment decision · cybersecurity goalReducing · SG-3 Remote start commands run only with valid authentication issued to the vehicle owner
Final state of the VisualPro TARA risk calculation and treatment decision screen. TH-1 is High, Severe, risk level 5, Reducing; TH-2 is Very Low, Major, risk level 1, Retaining; the newly added TH-3 is High, Major, risk level 4, Reducing
Final state of the VisualPro TARA risk calculation screen: TH-1 Reducing, TH-2 Retaining, newly added TH-3 Reducing
VisualPro TARA cybersecurity goal list. Attack path AP-1 with goals SG-1 and SG-2 sits under TH-1, AP-2 under TH-2, and AP-3 with goal SG-3 under TH-3, and each threat row shows its treatment decision, Reducing or Retaining
VisualPro TARA cybersecurity goal screen: treatment decisions, attack paths and linked goals SG-1 to SG-3 appear in one list

In the QNX survey, 79% reported pressure on speed. The more often features ship, the harder it is to treat a TARA as a document you finish once. The release procedure for a new feature needs a line that asks whether the TARA has been updated.

06When to reopen it: four signals

SignalCheck firstWhat changes in the TARA
Public vulnerability or attack codeDoes it apply to a part or library we use?Attack feasibility factors → risk level → treatment decision
OTA feature addition or interface changeIs there a new asset or a new attack path?New asset, damage, threat and attack path
Actual incident or signs of compromiseHas a start-of-production assumption broken?Attack feasibility, cybersecurity goals
Decision to end cybersecurity supportHow long will we carry the risks we chose to retain?Treatment decision

Finding the signal and redoing the assessment are different jobs. Collecting vulnerability information and responding to incidents take a separate system. A TARA is where you record how what that system finds changes the risk and the decision.

07What VisualPro TARA can and cannot do

What it can do

1It takes you from asset to damage, threat, attack path, cybersecurity goal and risk treatment in one module.

The example in this article was entered in that order. More on VisualPro TARA

2It rates attack feasibility three ways.

Choose attack potential, attack vector or CVSS v3. This article uses attack potential because it shows the change factor by factor.

3Change an assessment value and the risk level is recalculated.

At T1 in this article, changing only the AP-1 values moved only the TH-1 risk level, from 2 to 5.

4Work with AI through the MCP connection.

This example was drafted by Claude through VisualPro's MCP connection and reviewed by VWAY.

What it cannot do

VisualPro TARA records and calculates assessments. It does not collect vulnerability information or respond to incidents, so the fact that attack code has been published has to be judged and entered by the person responsible.

08What to check tomorrow

Security

  • For each treatment decision, can you tell when it was made and what the risk level was at the time?
  • When a public vulnerability appears, can you find right away which assets and attack paths to look at?

Development and product

  • Does the release procedure for OTA features ask whether the TARA has been updated?
  • Are open-source libraries linked to the assets in the TARA?

Quality and regulatory

  • Does the procedure name the signals that reopen a TARA, the person responsible and the deadline?
  • Does the support period promised to customers match the risk assessment?

09Closing

A TARA at start of production is that day's judgment. While the vehicle is on the road, attacks get easier and features multiply, so decide first when you will reopen it and who will make the decision again.

10Frequently asked questions

Q1Do we have to redo the TARA from scratch every time a vulnerability appears?

No. Reassess only the assets and attack paths that the vulnerability touches. In this article's example, only one attack path changed. To find the affected area quickly, though, the assets in the TARA have to be linked to the actual components.

Q2When attack feasibility rises, does the impact rating change too?

They are separate. The impact rating is the size of the damage, and attack feasibility is how easy the attack is. In this article, TH-1 stayed at Severe impact while its attack feasibility rose from Very Low to High, and that is what changed the risk level.

Q3If a vulnerability has a high CVSS score, isn't the risk automatically high?

No. CVSS describes the severity of the vulnerability, while TARA risk also looks at the attack path it opens in your vehicle and the damage it leads to. The same vulnerability can lead to a different attack path rating depending on structures such as a gateway filter.

Q4Is a decision to retain a risk wrong?

No. Retaining a risk while it is low can be a sound decision. The problem is when the reasoning behind it changes and only the decision stays. Record the decision with the risk level at the time, and review it when a signal appears.

Q5Where should we start?

Pull out every item marked "Retaining" in your start-of-production TARA. Check line by line whether the attack feasibility reasoning for each item still holds, and you will see where to reopen first.
References
· QNX, "Under the Hood: SDV Developer Report" press release, Oct 21, 2026 — Read the press release
· TheAutoExec, "Four-fifths of automotive software developers expect their cars to be attacked by hackers within three years", Oct 28, 2026 — Read the article
· ISO/SAE 21434:2021 Road vehicles — Cybersecurity engineering (clause 1 scope, clauses 8, 13, 14, 15) — ISO overview page
· UN Regulation No. 155 Cyber security and cyber security management system — UNECE overview page
※ The telematics and OTA example in this article is a fictional system for education and not the design of any vehicle or manufacturer. The assessment values are illustrative judgments, and the published attack code and the remote start addition are assumed situations. The example analysis was written and reviewed by VWAY using Claude through VisualPro's MCP connection.
Start by reviewing the risks you chose to retain
Give us one threat and one attack path, and we will go through the reassessment with you in VisualPro TARA.
VWAY Co., Ltd.  |  sales@vwaycorp.com