Automotive TARA Example: An Unauthorized UDS Programming Route
See a worked automotive TARA example for unauthorized UDS programming through a gateway, including assets, damage scenarios, attack paths and controls.
Sources checked 12 October 2026
A powertrain controller accepts diagnostic programming over an internal vehicle network. A workshop tester reaches the vehicle through OBD-II. The gateway mediates the route. That architecture creates a concrete cybersecurity question: what prevents an unauthorized tester from changing the controller firmware?
This is an illustrative assessment, not evidence that a particular gateway or controller has a defect. It shows how an automotive engineer can connect technical facts to a traceable threat analysis and risk assessment.
Define the item and trust boundaries
Start with the function. The target motor-control ECU receives torque commands and runs firmware that influences traction. A gateway connects diagnostic access to a powertrain CAN-FD network. A diagnostic programming service provides an authorized route for software maintenance.
Record the external tester, the OBD-II entry point, the gateway, the network, the diagnostic service and the ECU firmware. Identify the trust boundary at each transition. Do not describe a physical connection as authenticated access. Those are separate properties.
For this example, assume an attacker obtains physical diagnostic access. Do not assume access to privileged diagnostic services. Whether the tester can enter a programming session remains an explicit technical question.
Identify the asset and the damage scenario
The protected asset is the integrity of the motor-control firmware. The related damage scenario is unintended traction behaviour following unauthorized firmware modification. Another plausible outcome is loss of propulsion. The actual vehicle architecture and operating conditions determine the impact ratings.
A damage scenario describes harm to a stakeholder. It is not the same thing as a cybersecurity threat. “Unauthorized firmware replacement” states an attack outcome. “Unexpected vehicle acceleration” describes possible damage.
Record the safety, financial, operational and privacy impacts separately under the organisation's approved method. A severe safety rating needs an engineering justification and coordination with functional safety specialists where required.
Build an attack path from reachable steps
The candidate route is:
An attacker obtains diagnostic access at OBD-II.
The gateway passes an authorized form of diagnostic traffic toward the target network.
The attacker gains an unauthorized programming capability on the motor-control ECU.
The ECU accepts a malicious or otherwise unapproved firmware image.
The modified firmware executes and affects the protected asset.
Each step is a condition to investigate, not a claim that the attack succeeds. A secure gateway can stop the route. ECU authentication or firmware signature checks can stop later steps. A diagram should mark these defenses at their actual positions.
UDS is a diagnostic protocol family used for vehicle service functions. Do not treat its existence as proof of weak access control. The engineering assessment concerns the implementation, authorization rules and update verification mechanisms.
Rate feasibility without pretending to know the answer
An attack-potential assessment considers elapsed time, attacker expertise, knowledge of the item, opportunity and equipment. The team needs evidence for its chosen factor values. A workshop test, supplier specification or verified security design can support a rating.
Avoid assigning a final feasibility score from the five narrative steps alone. The route's feasibility depends on the diagnostic security mechanism, network restrictions, programming policy and other implementation details. Mark missing evidence and preserve the rationale for later review.
If another assessment method is approved for the product, record that method explicitly. A borrowed matrix or undocumented conversion makes the result difficult to defend.
Connect security controls to the attack route
Consider controls at three places. The gateway can restrict diagnostic routing and expose only necessary services. The ECU can enforce authenticated programming authorization. The boot process can verify firmware integrity through a protected trust anchor.
These controls address different steps. Secure boot does not prove that a diagnostic session was authorized. A protected security-access mechanism does not prove that the boot chain will reject modified firmware. The review must identify the exact security claim of each control.
Distinguish planned controls from implemented and tested controls. A planned control does not justify a verified residual rating. Reassess the attack path after evidence establishes that the deployed control works as claimed.
Decide treatment and preserve the review trail
For an unacceptable risk, the team can select treatment and define a cybersecurity goal. A suitable goal can require the ECU to execute only authorized firmware. That goal needs an implementation strategy and verification evidence.
Record the owner, rationale, decision status and review date. Link the goal to the relevant risk and control. Reopen the assessment after a change to the gateway configuration, programming service or firmware distribution route.
See the engineering chain in QuickTARA
QuickTARA models architecture elements, attack paths, risk treatment and related evidence in one engineering workflow. A useful product demo should show the selected route and the decisions attached to each step.
Ask to inspect this type of diagnostic programming assessment in QuickTARA. Bring your own gateway diagram and ask the engineer presenting the demo to show what happens to the risk record after a control changes.
Frequently asked questions
Does OBD-II access mean a vehicle ECU can be reprogrammed?
No. The connector is an entry point. Programming depends on routing, diagnostic services, authorization and firmware acceptance mechanisms.
Does secure boot eliminate the need for secure updates?
No. Secure boot checks a defined startup trust chain. Secure update controls govern image authenticity, authorization and the update operation. They protect related but different stages.
The engineering scenarios in this article are illustrative. They do not describe a defect in any production vehicle or ECU. QuickTARA does not replace an assessment, a certification or engineering judgement.