etc.[VisualPro Tech Brief] Expecting Attacks Within Three Years? When to Reopen Your TARA
01Summary
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.
| Figure | Finding |
|---|---|
| 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.
| Factor | What it asks | Over time |
|---|---|---|
| Elapsed time | How long does it take to find and carry out the attack? | Drops sharply once attack code is published |
| Specialist expertise | What level of specialist is needed? | Falls when tools appear |
| Knowledge of the item or component | How hard is the target information to get? | Falls as analysis material spreads |
| Window of opportunity | How much opportunity is there to reach the target? | Gets easier as connected features grow |
| Equipment | What 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 factor | T0 start of production | T1 after publication | Why it changes |
|---|---|---|---|
| Elapsed time | 17 | 1 | Months to find it yourself, days to adapt public code |
| Specialist expertise | 6 | 3 | A proficient person can run it; no expert needed |
| Knowledge of the item or component | 3 | 0 | The information needed is now public |
| Window of opportunity | 1 | 1 | The cellular connection is unchanged |
| Equipment | 0 | 0 | Standard equipment is enough |
| Total | 27 | 5 | |
| Attack feasibility | Very Low | High |
Next is the risk calculation screen.
| Threat | Impact rating | T0 feasibility · risk level | T1 feasibility · risk level | Treatment decision |
|---|---|---|---|---|
| TH-1 | Severe | Very Low · 2 | High · 5 | Retaining (the decision made at T0, unchanged) |
| TH-2 | Major | Very Low · 1 | Very Low · 1 | 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 item | What was added |
|---|---|
| Asset | Remote start command authentication token (confidentiality, integrity) |
| Damage scenario | Unauthorized remote start leads to vehicle theft (Financial Major) |
| Threat | TH-3 An unauthorized user sends a start command by exploiting an authentication flaw in the remote start API |
| Attack path | AP-3 Analyze the API between app and server, forge the authentication token and send a remote start command |
| Attack feasibility · risk level | Total 10 · High · 4 |
| Treatment decision · cybersecurity goal | Reducing · SG-3 Remote start commands run only with valid authentication issued to the vehicle owner |
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
| Signal | Check first | What changes in the TARA |
|---|---|---|
| Public vulnerability or attack code | Does it apply to a part or library we use? | Attack feasibility factors → risk level → treatment decision |
| OTA feature addition or interface change | Is there a new asset or a new attack path? | New asset, damage, threat and attack path |
| Actual incident or signs of compromise | Has a start-of-production assumption broken? | Attack feasibility, cybersecurity goals |
| Decision to end cybersecurity support | How 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.
2It rates attack feasibility three ways.
3Change an assessment value and the risk level is recalculated.
4Work with AI through the MCP connection.
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
10Frequently asked questions
Q1Do we have to redo the TARA from scratch every time a vulnerability appears?
Q2When attack feasibility rises, does the impact rating change too?
Q3If a vulnerability has a high CVSS score, isn't the risk automatically high?
Q4Is a decision to retain a risk wrong?
Q5Where should we start?
· 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

