Automakers should treat API security as a vehicle safety control, not just an application issue. Start by inventorying every API, documented and shadow, then stress-test registration, enrollment, and authorization flows. Continuously monitor live traffic for abnormal requests, validate dealer and owner onboarding, and correlate API events with vehicle actions so remote commands, location data, and identity changes cannot be abused.
Why API Security Becomes a Vehicle Control Problem
Remote vehicle functions are not ordinary app features once they can lock doors, start the engine, unlock a trunk, locate a car, or alter ownership and dealer permissions. The security goal is to make every command traceable to the right user, the right vehicle, and the right context, because a broken API can become a direct path to unsafe vehicle behaviour, privacy exposure, or account takeover.
That means automakers need to think in terms of command authority, not just transport security. A protected endpoint is not enough if registration, enrolment, token issuance, or role assignment can be abused to bind the wrong person or dealer to the wrong vehicle.
What Must Be Locked Down Before Remote Controls Go Live
The first control is complete inventory. Teams need to know every customer-facing, dealer-facing, mobile-app, partner, and internal API that can affect a vehicle or a vehicle-linked account, including shadow and legacy endpoints that still respond to authenticated requests.
The second control is binding and authorisation. Registration, enrolment, and re-enrolment flows should be tested for weak proofing, replay, privilege escalation, and broken object-level authorisation. For API-heavy ecosystems, the OWASP API Security Top 10 is a useful reference point for broken authorisation, unrestricted resource consumption, and exposed business flows, which are common failure modes when a command API is exposed too early. OWASP API Security Top 10
The third control is runtime verification. Monitor live requests for abnormal volume, unusual geolocation, impossible travel patterns, repeated failed enrolments, and commands that do not match the expected vehicle state. Correlate API activity with the physical action taken by the car so a remote unlock, location lookup, or ownership change is never treated as a standalone event.
Dealer, Owner, and Platform Trust Boundaries That Often Fail
Automaker APIs usually fail at the boundary between legitimate business convenience and overbroad trust. Dealer portals, customer apps, call-centre tooling, and support workflows often share identity, session, and entitlement assumptions that do not survive real-world abuse. If a dealer account can impersonate a customer session, or if a customer token can invoke dealer-only actions, the API design has already crossed a dangerous line.
The most important validation step is to prove that each actor can only affect the vehicles and functions explicitly assigned to that actor. That includes onboarding, delegated access, transfer of ownership, temporary service access, and revocation when a car is sold or a relationship ends. The The 52 NHI Breaches Report is a useful reminder that abused machine credentials, secrets, and service accounts are common breakpoints in large API ecosystems.
For broader control design, API exposure should sit inside a zero-trust mindset: verify every request, minimise implicit trust between services, and assume that a credential, partner integration, or support workflow can be misused if the authorisation logic is loose. NIST SP 800-207 Zero Trust Architecture
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack surface, NIST SP 800-53 Rev 5 sets the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Remote vehicle commands depend on strict action-level authorization. |
| API1 — Broken Object Level Authorization | Vehicle, account, and dealer bindings can fail when object access is weak. | |
| Recommendation — Enforce function-level checks before any remote vehicle action is executed. Validate object ownership on every request affecting a vehicle or account. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | API-driven vehicle access depends on secure lifecycle management for tokens and secrets. |
| AC-6 — Least Privilege | Remote controls should only permit the minimum vehicle actions needed by each role. | |
| Recommendation — Rotate, expire, and revoke credentials and tokens used by remote control APIs. Limit dealer and customer roles to the smallest necessary command set. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Vehicle APIs need explicit access rules for users, dealers, and service flows. |
| Recommendation — Define and enforce access rules for every vehicle-facing API. | ||
Practitioner Guidance
What to prioritise: Treat registration and ownership transfer as higher risk than the vehicle command itself. If an attacker can bind a vehicle to the wrong account, they usually gain durable control without needing to break every downstream endpoint.
What to verify: Before launch, validate every high-impact flow with negative testing, including stale tokens, reused sessions, account takeover scenarios, dealer impersonation, and direct object reference attempts against vehicle identifiers. Confirm that the API rejects commands unless the actor, the vehicle, and the current entitlement state all align.
What good looks like: Every remote action has an auditable identity, a bounded purpose, and a clear revocation path. The platform should be able to explain who requested the action, which policy allowed it, and what vehicle state changed as a result.
Practitioner takeaway: The safest launch criterion is not “the API works,” but “the API cannot be turned into an unreviewed control plane for a vehicle.”
Related resources from NHI Mgmt Group
- Why do mobile apps often expose sensitive credentials and API abuse risk even when they appear secure?
- How should teams secure Spring Boot applications before they expose sensitive data to the internet?
- What happens when customers expose sensitive data across API driven services without continuous API discovery?
- How should security teams secure microservices before they expose sensitive data or customer workflows?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
