Connected Fleet and Telematics Security Guide: Secure Devices, APIs and Vendor Access

Every telematics unit plugged into a truck, van or car is a networked computer wired to the vehicle bus, managed from a cloud platform that can usually reach the whole fleet. For commercial fleets that platform holds live location, driver records and, in many cases, the ability to send commands to vehicles. A weakness in the device, the mobile app or the back-end API can therefore expose every vehicle at once. This guide covers the telematics attack surface, the requirements that carriers can put into procurement (using the NMFTA Telematics Security Requirements and NHTSA best practices), API and credential security for fleet platforms, monitoring and incident response. It is for fleet operators, carrier IT and security teams, telematics service providers and OEM connected services teams. For vehicle-internal security, see the Connected and Autonomous Vehicle Security Guide.

Key takeaways

• The back end is the fleet-wide risk. A single broken API authorisation check or leaked key can expose every vehicle the platform manages, which is far worse than one compromised device.
• No shared secrets across devices. NMFTA SCP-011 and SCP-120 forbid identities, keys or credentials common to multiple devices or software copies, and NHTSA [T.5] says a credential from one vehicle should not give access to others.
• Limit what the device can send to the vehicle network. NMFTA SCP-060 requires controls that limit the commands and data the telematics device can transmit to the vehicle network.
• Buy security, then verify it. Use the NMFTA requirements matrix in RFPs and ask for penetration test results, update mechanisms and a vulnerability disclosure programme.
• Treat platform integrations as identities. API keys and OAuth clients used by dispatch, payroll and fuel card systems need owners, scopes and rotation.

The telematics attack surface

NMFTA structures its requirements around four components: the vehicle-connected device, the cloud or back end, the mobile app and connectivity. That is a useful map of where to look.

The most serious incidents with connected vehicle services have tended to come from the back end rather than the radio. The Toyota T-Connect Key Exposure 2022 is an example: a subcontractor published source code for the T-Connect website on public GitHub, and it contained an access key to a customer data server that exposed the email addresses and customer management numbers of 296,019 customers.

Requirements to put in procurement

The National Motor Freight Traffic Association (NMFTA) publishes Cybersecurity Requirements for Telematics Systems as an open matrix on GitHub, developed with motor freight carriers, telematics service providers and security experts for telematics, FMIS and ELD systems. The latest official release is v1.5 (February 2022), with a v1.6 release candidate that moves the matrix to strictdoc format and adds NIST SP 800-82 references. It is licensed CC BY-NC-ND 4.0. The requirements below are the ones carriers most often need to test.

NHTSA's "Cybersecurity Best Practices for the Safety of Modern Vehicles" (2022) adds the vehicle maker's view. It asks that connections to third-party and aftermarket devices be authenticated and given limited access [G.42], that networks outside the vehicle's wireless interfaces be treated as untrusted [T.14], that segmentation and gateways limit wireless-connected ECUs from reaching safety-critical controls [T.15, T.16], and that back-end to vehicle communication use appropriate encryption and authentication [T.20]. For secure update design see the IoT Secure Firmware Update Guide.

Hardening the in-vehicle device

The device sits between an untrusted network and the vehicle bus, so it has to be hardened both ways. The NMFTA matrix and the NHTSA best practices give concrete requirements a carrier can ask a provider to evidence.

• Wireless interfaces: NMFTA AC-060 asks the vendor to list every wireless interface and how each can be configured or disabled. AC-061 forbids deprecated Wi-Fi protection (it names WEP, WPS and open networks), and AC-062 requires Bluetooth pairing to be enabled by a physical control on the device and time-limited, without legacy pairing.
• Troubleshooting and debug: CM-020 requires troubleshooting services to be disabled or protected, and CM-030 requires test and debug interfaces to be unavailable in production builds. NHTSA [T.1] says developer-level access should be limited or eliminated where there is no foreseeable operational reason for it, and [T.2] that any necessary debugging interfaces be protected so only authorised privileged users can reach them.
• Diagnostics: NHTSA [T.8] advises minimising global symmetric keys and ad hoc cryptography for diagnostic access, and [T.9] that diagnostic tool access be controlled through authentication and access control. [T.7] gives the example of restricting brake-related diagnostics to low speeds.
• Code and protocol hygiene: NMFTA SII-070 asks for exploit mitigations such as ASLR, DEP, CFI, stack guards, fortification and RELRO across executables, SII-071 for input sanitising or memory-safe parsers, and SCP-130 for limiting hardware support for deprecated or insecure protocols.
• Secure by default: CM-040 requires the default configuration to be the most secure, with additional features enabled deliberately.
• Bus access limits: SCP-060 requires controls integrated into the device that limit the commands and data it can transmit to the vehicle network. Ask the provider which message types the device can send and how that list is enforced.

For hardware roots of trust and boot verification, NMFTA SII-040 and SII-041 require asymmetric boot verification with a hardware-based root of trust. See the Firmware and Boot Security Guide.

Securing fleet platform APIs

Telematics platforms expose APIs to their own apps, to customers' systems and to partners. The OWASP API Security Top 10 2023 risks map directly onto them.

• API1:2023 Broken Object Level Authorization: a request for vehicle or driver data must be checked against the caller's fleet, not just the presence of a valid token. Test by requesting another tenant's vehicle identifiers.
• API2:2023 Broken Authentication: weak login flows, missing rate limits (NMFTA AC-070) and long-lived tokens.
• API3:2023 Broken Object Property Level Authorization: responses that return more fields than the caller needs, such as driver personal data in a location feed.
• API5:2023 Broken Function Level Authorization: remote command endpoints (immobilise, unlock, configure) reachable by ordinary user roles.
• API9:2023 Improper Inventory Management: old API versions and test hosts left running with weaker checks.

Put remote vehicle commands behind separate authorisation, step-up authentication and per-command logging, and rate-limit them per fleet. See the API Security Guide.

Where identity fits

A fleet platform is a dense web of non-human identities: device certificates, back-end service accounts, partner API keys, mobile app credentials and OAuth clients used by integrations.

• Per-device identity: each unit should have its own key or certificate, ideally generated in hardware, and NMFTA SCP-040 requires that data protection keys are not correlated to public device information. See the Identity for IoT Fleets Guide.
• No keys in apps: SCP-120 forbids hardcoded API keys in software. Mobile apps should obtain short-lived tokens after user authentication.
• Customer integration keys: carriers connect dispatch, payroll, fuel and insurance systems to the telematics platform with API keys. Scope each key to read-only data where possible, record an owner and rotate on staff or vendor changes. See the API Key Management Guide.
• Vendor support access: telematics provider staff often have access to customer tenants. Ask how it is granted, logged and reviewed (NMFTA PS-010 covers personnel security).
• Driver and user accounts: remove accounts promptly when drivers leave; shared driver logins make audit impossible.

Implementation roadmap for a carrier

1. Inventory: list every telematics, ELD, camera, trailer tracking and fuel device, the provider, firmware version and what each connects to on the vehicle.
2. Assess providers: send the NMFTA matrix to each provider, ask for penetration test summaries and disclosure policy, and score the gaps.
3. Fix integrations first: review all API keys and OAuth clients connected to the platform, remove unused ones, reduce scopes and turn on MFA for all platform users.
4. Restrict remote commands: disable immobilisation or configuration commands that you do not use, and restrict those you do to named roles with approval.
5. Pilot changes: apply new device configurations or firmware to a small group of vehicles first, confirm that tracking, ELD compliance and safety services still work, and keep the previous configuration available to roll back.
6. Monitor: collect platform audit logs into your SIEM and agree with each provider how they will notify you of incidents (NMFTA IR-010, SII-171).
7. Exercise: run a tabletop for loss of the telematics platform and for a provider breach, including the manual fallback for safety services (M-040).

Decision guidance: small fleets cannot test devices themselves; they should rely on the NMFTA matrix in contracts, insist on MFA and review integrations. Large carriers and OEM connected services should commission independent device and API testing, require hardware roots of trust and segment vehicle-bus access. Where a provider cannot meet core requirements such as unique per-device credentials (AC-080, SCP-011) or no hardcoded keys (SCP-120), treat it as a material risk and plan replacement, using the Open Telematics API (P-030) to reduce lock-in.

Detection and measurement

NHTSA [T.12, T.13] recommends logging sufficient to reveal the nature of an attack and aggregating logs across vehicles to identify trends.

Metrics:

• Percentage of telematics providers assessed against the NMFTA matrix in the last year.
• Percentage of platform users with MFA.
• Number of API keys without a named owner (target zero).
• Percentage of devices on the provider's current supported firmware.
• Number of remote commands issued outside approved roles per month.

Framework mapping

See also the Cybersecurity for Logistics and Shipping Guide.

Common failure patterns

• Keys in code: API keys in mobile apps, firmware or public repositories, as in the Toyota T-Connect case.
• Tenant checks missing: APIs that trust a vehicle identifier in the request without checking the caller's fleet.
• Fleet-wide secrets: the same password or key on every device, so one teardown compromises all units.
• Unrestricted bus access: telematics devices that can send any message onto the vehicle network.
• Forgotten integrations: API keys for former partners or projects still active years later.
• Debug left on: production units shipped with serial consoles, test services or Bluetooth pairing that never times out, which turns physical access to one parked truck into a way to study and attack the whole fleet.
• Old devices nobody owns: units from a previous provider still installed and connected after a contract change, with nobody receiving their updates or alerts. Decommission devices and revoke their credentials when a contract ends (NMFTA M-030 covers disposal).
• No fallback: safety or compliance processes that stop when the platform is down.

Practitioner checklist

• Every telematics device and provider is inventoried with firmware versions.
• Providers have been assessed against the NMFTA Telematics Security Requirements.
• Each device has unique credentials; no shared keys across devices or app copies.
• Device commands to the vehicle network are restricted to what the service needs.
• Platform users have MFA; remote vehicle commands need named roles.
• Every API key and OAuth client has an owner, minimal scope and a rotation date.
• Platform audit logs reach your SIEM and provider incident notification is contractual.
• Manual fallback for safety and compliance services has been tested.
• Devices removed at contract end are decommissioned and their credentials revoked.
• Provider device debug, wireless and pairing settings have been checked against NMFTA CM-020, CM-030 and AC-060 to AC-062.

Standards and references

• NMFTA: Cybersecurity Requirements for Telematics Systems
• NHTSA: Cybersecurity Best Practices for the Safety of Modern Vehicles
• OWASP: API Security Top 10 2023
• NHTSA: Vehicle Cybersecurity
• NIST: SP 800-53 Rev. 5, Security and Privacy Controls
• NIST: Cybersecurity Framework 2.0

Related NHI Mgmt Group resources: Connected and Autonomous Vehicle Security Guide · API Security Guide · Identity for IoT Fleets Guide · Uptane and Vehicle OTA Security Guide