A quick history of vehicle cybersecurity

Published on March 19, 2018 in Compliance by Tom Walli |  3 minute read

Read an overview of vehicle cybersecurity, from the introduction of the OBD II port to the present telematics cybersecurity.

Since 1996, it has been legislated in North America that vehicles have an OBD II (J1962) port. Its regulated use was for emissions testing, so a standard was created to allow data to be viewed in a designated format. The OBD II standard data received through the diagnostic port allowed mechanics in mom and pop shops to perform Drive Clean tests on vehicles (mandatory in many states and provinces) and also diagnose without having to buy expensive tools.


See also: 

History of GPS satellites and commercial GPS tracking

What you need to know about the FBI notification on electronic logging


The convenience of this port expanded its capabilities with various protocols such as ISO 9141 (requirements for digital interchange of information for road vehicles), J1850 VPW/PWM, ISO 14230 (Diagnostic communication over K-Line) and CAN ISO 15765 (Diagnostic communication over Controller Area Network).


The standard protocols were designated to certain pins on the diagnostic port and for the most part are followed by every manufacturer. Non-designated pins on the OBD II port are populated with manufacturer-specific protocols for internal and vehicle specific data not needed for emissions. Although these pins are manufacturer-specific, there are common placements for other protocols.


See Also: Federal Fleet Manager Cybersecurity Considerations for Telematics

Vehicle network development included a party line or broadcast network of data sharing/communication among network nodes and the ability to flash and reflash vehicle ECUs connected to this network. Since the OBD is hardwired to this network, the ability to access ECU information and update vehicle ECUs through this port became a reality. This changed the way a vehicle was serviced and allowed deep diagnoses to find issues with a component.

Introduction of new standards

With this data being available and ever increasing technology being put into vehicles it became necessary to make standards to allow component ECUs to be updated. Protocols like ISO 14229 (Road Vehicles — Unified diagnostic services) and J2534 (vehicle ECU reprogramming) were developed to allow tools to share methods used to update vehicles so tool developers could use their software to connect without vehicle manufacturer-specific tools.


Updating and programming parameters became cost-effective and feasible for small vehicle repair shops. They didn’t need to go to the dealer to reset the vehicle computer every time a component was replaced.


As well, this allowed vehicles being serviced within a dealership to have multiple stations sharing its connection through Ethernet, Wi-Fi and Bluetooth. Having a central computer with multiple tools attached resulted in cost savings for all. This also allowed the harvesting of data for manufacturers to make improvements and crowdsourcing of common issues.


See also: Three pillars of information security management

Vehicle security is tested

These standards, which opened up so many benefits, also allowed people to make changes with harmful intent. Although these components have security checks before being able to change parameters, individuals of nefarious intent with some knowledge of microprocessors and disassembly can circumvent these security measures and hack parameters for example.


By the time Electronic Control Modules (ECMs) get to market, the components used in the device can already be circumvented and hackers have already been able to bypass internal security on chipsets. Being able to disassemble code from a vehicle’s ECU can give you the secret sauce. With that said, once a hacker has the ability to get to a vehicle’s diagnostic port, any change can be made without removing a component from the vehicle. In the same way, gaining physical access to a vehicle can allow brake lines to be cut or other damage.


Through field testing, some vehicles were found to have a very weak security and no safety put in place to protect a vehicle from being programmed during a driving condition, once a researcher had access to the vehicle network.

Geotab telematics security

Then in comes telematics, that provides remote cellular connection to the vehicle communication network. Like door locks that restrict access to the vehicle contents, telematics security is intended to prevent unauthorized access to the vehicle network.


Geotab takes a rigorous approach to security and has gone to great lengths to secure the connection between the vehicle and the user interface. Geotab also takes pride in being active in SAE committees and conferences regarding security and belong to groups to enhance security.


Geotab is working with industry stakeholders including (industry associations like SAE, IEEE, Auto-ISAC, Universities, regulators, OEMs) and shares best practices developed with our customers and competitors alike to keep the connected vehicle secure.


For more details on telematics security and data privacy, visit the Geotab Security Center.


Securing the future of connected mobility

Building a platform resilient to cyber threats

If you liked this post, let us know!


Geotab's blog posts are intended to provide information and encourage discussion on topics of interest to the telematics community at large. Geotab is not providing technical, professional or legal advice through these blog posts. While every effort has been made to ensure the information in this blog post is timely and accurate, errors and omissions may occur, and the information presented here may become out-of-date with the passage of time.

Get industry tips and insights

Sign up for monthly news and tips from our award-winning fleet management blog. You can unsubscribe at any time.

Republish this article for free