Linkedin-inYoutube
logotype
  • Consulting
    • Automotive
      • Functional Safety
      • Cybersecurity
      • Autonomous Product Development
      • Electric Vehicle (EV) Development
    • Physical AI
      • Robotics Safety
    • Responsible AI
      • Responsible Artificial Intelligence
  • Training
    • Functional Safety
    • Cybersecurity
    • ADS and Responsible AI
  • Company
    • Why SRES Training
    • Leadership
    • Partnerships
    • Careers
  • Insights
  • Contact
Let's Talk
logotype
  • Consulting
    • Automotive
      • Functional Safety
      • Cybersecurity
      • Autonomous Product Development
      • Electric Vehicle (EV) Development
    • Physical AI
      • Robotics Safety
    • Responsible AI
      • Responsible Artificial Intelligence
  • Training
    • Functional Safety
    • Cybersecurity
    • ADS and Responsible AI
  • Company
    • Why SRES Training
    • Leadership
    • Partnerships
    • Careers
  • Insights
  • Contact
Let's Talk
  • Consulting
    • Automotive
      • Functional Safety
      • Cybersecurity
      • Autonomous Product Development
      • Electric Vehicle (EV) Development
    • Physical AI
      • Robotics Safety
    • Responsible AI
      • Responsible Artificial Intelligence
  • Training
    • Functional Safety
    • Cybersecurity
    • ADS and Responsible AI
  • Company
    • Why SRES Training
    • Leadership
    • Partnerships
    • Careers
  • Insights
  • Contact
logotype
logotype
  • Consulting
    • Automotive
      • Functional Safety
      • Cybersecurity
      • Autonomous Product Development
      • Electric Vehicle (EV) Development
    • Physical AI
      • Robotics Safety
    • Responsible AI
      • Responsible Artificial Intelligence
  • Training
    • Functional Safety
    • Cybersecurity
    • ADS and Responsible AI
  • Company
    • Why SRES Training
    • Leadership
    • Partnerships
    • Careers
  • Insights
  • Contact
Could ISO/SAE 21434 Have Stopped the TeslaLogger Exploit?
09/18/24
149 Likes

Could ISO/SAE 21434 Have Stopped the TeslaLogger Exploit?


This article offers an in-depth look at topics related to Cybersecurity.

For expert-level training—including certification-based programs—on these topics and more, explore our Automotive trainings. To learn how we support product development, compliance, and organizational safety goals with consulting support, visit our Functional Safety & Cybersecurity page—or contact us directly.


Modern vehicles are not just mechanical devices anymore. According to Porsche Engineering Magazine in 2021, “Even today, cars are very much rolling computers. They contain a network of electronic control units (ECUs), with between 70 and 100 being installed in every modern vehicle” and “100 million. This is how many lines of code feature in today’s car.” [1]

To make matters more complex, these ECUs and lines of code are developed by different vendors and are designed to run on different operating systems. These ECUs control various functions in the vehicle, including propulsion, braking, advanced driver assistance, and steering. These devices are often communicating across a CAN bus (Controller Area Network) in which an attacker only needs one vulnerability to gain access into the vehicle CAN.

In May 2024, a security researcher, Harish Santhanalakshmi Ganesan, a Master’s student in cybersecurity at the University of Texas, Dallas, claimed to have exposed a significant vulnerability in TeslaLogger which is an open source third-party data logging software for Tesla vehicles, allows user to monitor, analyze and visualize data including: trips, charge, battery health. By exploiting the security vulnerabilities, Harish was supposedly able to gain unauthorized access to over 30 Tesla cars worldwide, demonstrating the potential risks posed by insecure third-party integrations.[2]

Harish downloaded the open source software from the internet and was able to run a simple nmap vulnerability scan and he was able to discover several open ports including: 

  • Port 3306/ tcp: which is MariaDB
  • Port 3000/ tcp which is Graphana
  • Port 8888/tcp which is admin panel

The vulnerabilities he identified included the use of insecure default settings, plain text storage of sensitive API keys, and a lack of proper security authentication mechanisms.  These vulnerabilities allowed him to control various functions of the vehicles, such as unlocking doors and manipulating climate settings. Before publishing his findings, Harish contacted the developer and maintainer so that they can apply necessary mitigations. According to him, “Maintainer has enabled encryption to store Tesla API key and refresh token in Database. so even though an attacker compromises the Data Base or graphana he cannot get the API Key in plain text. Also the maintainer has added authentication in the admin panel already.” 

Notably, the author did not seem to have reported this particular vulnerability with Tesla’s product security team because of their response to a security issue he had identified with a different third party software (Teslamate) in the past.

From Author's Original Article

This incident highlights the importance of implementation of cybersecurity measures in automotive software development. ISO/SAE 21434:2021 Road vehicles – Cybersecurity engineering, is an automotive standard focusing on the cybersecurity risk management in the automotive industry [3]. The standard emphasizes the importance of cybersecurity implementation throughout the lifecycle of the vehicle. 

A proactive implementation of a Threat Analysis and Risk Assessment (TARA) based on ISO/SAE 21434 Clause 15 could have addressed the vulnerabilities in TeslaLogger. RQ-15-03 under sub-clause “15.4. Threat Scenarios and Identification” specifically requires the inclusion of malicious use cases resulting from reasonably foreseeable misuse and/or abuse. 

We want to show you a high-level example of how a TARA could have captured the admin panel vulnerability. While the TARA is still based on a threat “model” and could suffer from unknowns, a systematic approach highlighted in a standard like ISO/SAE 21434, along with the right combination of experts with diverse experience, will greatly reduce the likelihood of vulnerabilities in released products.

Building a Simplified TARA for Admin Panel Vulnerability

The TeslaLogger exploit demonstrates a critical need for comprehensive implementation of cybersecurity measures by OEMs, suppliers and third-party software vendors operating in the automotive industry. More importantly, it drives the question “What is the scope of responsibility an OEM development team shoulder for their customer’s use of third-party software and the related vulnerabilities they may pose?”.

In the automotive functional safety standard, ISO 26262: 2018 [4], and the Safety of the Intended Functionality (SOTIF) standard, ISO 21448:2022 [5], ‘reasonably foreseeable misuses’ of the safety-critical product are systematically analyzed during development and counter-measures subsequently developed. Even in these standards, what is “reasonable” is not clearly defined. Therefore, we clearly need industry alignment on “what is good enough” when it comes to foreseeable misuses and/or abuses over time. At the same time, it is also equally important for security researchers to remain optimistic and continue reporting the vulnerabilities to all stakeholders regardless of past reactions from automakers and suppliers. 

Currently vehicles are as vulnerable as computers were in the early 2000s making it necessary to stay ahead of hackers and learn from each other. We have a joint responsibility to apply state-of-the-art standards and methods to keep ourselves and our loved ones secure and safe. The worst thing we can do is do nothing.

References

  1. https://www.porscheengineering.com/filestore/download/peg/en/magazine-2021-01/default/ab93c8ce-7b56-11eb-80d3-005056bbdc38/Download-Magazine.pdf
  2. Hacking into 30+ tesla cars around the world using a third party software | by Harish SG | May, 2024
  3. ISO/SAE 21434:2021 – Road vehicles — Cybersecurity engineering
  4. ISO 26262-1:2018 – Road vehicles — Functional safety
  5. ISO 21448:2022 – Road vehicles — Safety of the intended functionality

Have insights or questions? Leave a comment below—we welcome thoughtful discussion from our technical community.

Interested in learning more about our services? Find all upcoming trainings here and all consulting offerings here.


Digging into the ISO/IEC 5469:2024 – Artificial intelligence: Functional safety and AI systems standard

Digging into the ISO/IEC 5469:2024 – Artificial intelligence: Functional safety and AI systems standard

04/28/24

Syntax, Semantics…Say What?

05/13/24
Syntax, Semantics…Say What?

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Insight Categories

  • Autonomous Systems18
  • Electric Mobility3
  • News11
  • Videos11
  • Functional Safety31
  • Responsible AI21
  • Cybersecurity5
Most Recent
  • CES Wrap-Up 2026: The Humanoid Robot Safety Question
    CES Wrap-Up 2026: The Humanoid Robot Safety Question
    01/15/26
  • Conversations on Randomness of Software
    Conversations on Randomness of Software
    12/16/25
  • ISO 26262 Edition 3: Part 3 and Part 4 – Item and System Level
    ISO 26262 Edition 3: Part 3 and Part 4 – Item and System Level
    12/10/25
  • Humanoid Robot Safety Comes Into Focus
    Humanoid Robot Safety Comes Into Focus
    11/25/25
  • The Governance Gap: Why Companies That Move Fast on AI Without Guardrails End Up Moving Slower
    The Governance Gap: Why Companies That Move Fast on AI Without Guardrails End Up Moving Slower
    12/09/25
logotype
  • Company
  • Careers
  • Contact Us
  • info@sres.ai
  • 358 Blue River Pkwy Unit
    E-274 #2301 Silverthorne,
    CO 80498

Services

Automotive

Physical AI

Responsible AI

Training

Resources

Insights

Video

Legal

Privacy Policy
Cookie Policy
Terms & Conditions
Training Terms & Cancellation Policy
Accessibility
Consent Preferences

© Copyright 2025 SecuRESafe, LLC. All rights reserved.

Linkedin Youtube