The Cloud Road: Vehicle, Backend, App, and Resource
This chapter maps the connected-vehicle system that makes the authorization problem possible. The focus is not a tour of components for its own sake, but the question of who presents an identity, who maps that identity to resources, and where a request crosses from one trust boundary to another. By the end, readers should be able to trace a vehicle or app request through the cloud backend and name the policy decision that must keep it tied to the right vehicle.
Three endpoints, three kinds of responsibility
The evaluated telematics ecosystems can be understood as three cooperating endpoints: the vehicle, the cloud backend, and the mobile app. Their cooperation is what gives a connected vehicle its useful features, but it also means that no single endpoint has the whole security story.
The vehicle is the edge execution node. Its Telematics & Connectivity Antenna Module, or TCAM, supplies cellular connectivity and acts as a gateway between in-vehicle components and the cloud. The vehicle may be provisioned with a device certificate and private key so it can authenticate with mutual TLS, commonly abbreviated mTLS. In simple terms, mTLS lets both sides of a connection present credentials and establish that the connecting device is one recognized by the service.
That credential identifies a device. It does not describe every action the device should be able to perform. The TCAM may be the endpoint that ultimately carries a command toward in-vehicle systems, but the cloud still decides which messages, objects, and commands are routed to that vehicle. The distinction matters because a device identity and a resource permission can be held at different layers.
The cloud backend, often operated by a telematics service provider, is the coordination point. It terminates authenticated sessions, maps device and user identities to backend objects, routes commands and telemetry, and exposes interfaces for the mobile app. It may rely on identity and access management services, message-broker access lists, and checks in REST-style APIs. Those mechanisms are not interchangeable. A broker can decide which topic a session may use; an API can decide whether a request may retrieve a particular object; a fallback service can decide whether a management instruction has an acceptable origin and target.
The mobile app represents a different kind of principal. It usually authenticates with a user-level token rather than a device certificate. The user account may be associated with one or more vehicles, while the vehicle itself is represented as a device identity. That relationship creates another boundary the backend must preserve. A request that begins with a user account, a request that begins with a vehicle session, and a request that begins with a backend service are not automatically equivalent merely because they can eventually reach related vehicle data.
This is why the cloud cannot treat identity as a single undifferentiated label. It needs to know not only that a credential is valid, but also what kind of principal it represents and what resources that principal may use. A vehicle identity should not silently inherit every user-scoped permission, and a user-facing request should not be allowed to cross vehicle boundaries merely because a valid account or session is present.
The key state transitions also occur at different places. The vehicle establishes or maintains connectivity. The backend turns a connection into a recognized session and routes messages to logical resources. The app creates requests based on a user interaction. At each transition, some identity or target information crosses an interface. If the backend fails to carry the binding between them, the system can remain authenticated while becoming incorrectly authorized.
Consider a remote action initiated from the app. The app presents a user identity, the backend resolves that user's relationship to a vehicle, and a command is eventually delivered through a vehicle-facing channel. The fact that the first step was authorized for the user does not remove the need to check the final vehicle target. Conversely, a vehicle session that is valid for telemetry does not automatically become a user session with access to account-linked or media resources. The backend is responsible for preserving the distinctions as the request changes form.
Identifiers make this responsibility easy to overlook. A VIN or internal vehicle ID is useful for routing, but an identifier is not itself a permission. It tells a service which object the request names; it does not establish that the current principal may use that object. That relationship must come from policy or an explicit association maintained by the backend. If the system treats the presence of a well-formed identifier as sufficient, it has confused naming with authorization.
The same issue appears when a request crosses a service boundary. A broker can know the session identity and topic. An API can know the token and object reference. A storage service can know an object key and a URL request. Each service sees only part of the overall interaction unless the system carries the authorization context forward. The component that makes the final decision must have enough information to compare the principal with the target, rather than inheriting a broad “already authenticated” result from an earlier step.
The same backend serves different resource planes
The architecture becomes clearer when the resource, rather than the component, is used as the organizing idea. The study identifies three important communication planes: MQTT for near-real-time control and telemetry, HTTPS for data and media, and SMS for legacy fallback management. Each plane makes a target visible in a different way.
MQTT is a long-lived publish-and-subscribe channel. A vehicle maintains a session with a cloud broker, and messages are addressed through named topics. In a connected-vehicle deployment, a topic namespace may encode a VIN or another vehicle identifier so that commands and telemetry reach the intended endpoint. The broker therefore has two related jobs. It must accept a legitimate connection, and it must constrain that connection to the topics and operations authorized for the associated vehicle.
Those jobs can be separated accidentally. A session authenticated as Vehicle A may be accepted by the broker, while a publish or subscribe request referring to Vehicle B’s namespace is checked only for syntactic validity or existence. If the broker or its upstream policy service does not enforce the vehicle-to-topic relationship, the session can cross the control boundary even though the connection itself is genuine. The important object in this plane is the topic and the command scope attached to it.
HTTPS has a different shape. Requests are usually shorter-lived and carry their own authentication material, such as a token or a session credential. The target can appear in a URL, a path segment, a query parameter, or a field in a request body. A service handling a media object or telemetry record must therefore perform an authorization decision for the particular object named in that request. It cannot assume that the session’s validity settles the ownership of every object identifier that follows.
This distinction becomes especially important when one service returns a reference to another service. An API may decide that a request is acceptable and return an object URL. The storage layer must still prevent that URL from exposing content to an unauthorized requester. Authorization can fail at the API boundary, at the storage boundary, or at both. The resource is not protected merely because one preceding request was authenticated.
SMS fallback introduces a third boundary. Some platforms retain a management channel for situations in which packet-data connectivity is unavailable or the vehicle is in a low-power state. The receiving telematics unit must assess more than whether a message has the expected format. It must establish that the message came from an authorized source, has not been replayed or altered, and is intended for this vehicle and action. Mobile-network metadata or a familiar message structure may be part of a delivery mechanism, but neither one alone is the same as target-specific authorization.
The contrast can be summarized in a single rule: every plane must bind the authenticated principal to the resource form used on that plane. MQTT binds a vehicle session to a topic namespace and command scope. HTTPS binds a principal to an object or record on each request. SMS binds a command to an authenticated, fresh origin and a target vehicle. The rule is shared, but the evidence of a correct decision is different: a broker restriction, an object-level denial, or the absence of an unauthorized vehicle action.
The timing of each path changes the risk of forgetting that rule. MQTT keeps a session alive, so a mistaken scope decision can remain useful across many messages and subscriptions. The broker must maintain the correct relationship while the session persists; accepting the connection once is not enough. HTTPS usually presents a new request with a new target, so the ownership decision must be repeated rather than inherited from an earlier object lookup. SMS is designed to work under constrained connectivity, which makes it tempting to rely on lightweight origin assumptions, but the vehicle still needs a reliable way to reject a command that is fresh-looking yet aimed at the wrong target.
The resource also determines what a successful mistake would mean. Crossing an MQTT topic boundary can expose telemetry or deliver a control message. Crossing an HTTPS object boundary can reveal a record or media asset without changing vehicle state. Crossing an SMS boundary can cause an action on the vehicle. These are not interchangeable impacts, and they should not be inferred from the same signal. A broker acknowledgment, a populated object response, and a confirmed vehicle state change answer different questions about what the backend allowed.
This is why a shared identity across channels is not a shared authorization decision. The backend may recognize the same vehicle on MQTT and HTTPS, yet each path still needs to connect that identity to its own target representation. A system model that names the actors but leaves this final comparison implicit is incomplete.
The diagram shows why “the backend” is not one authorization check in one place. A cloud service can distribute decisions across a broker, an API layer, object storage, and a fallback path. A policy that is correct in one layer can be absent or inconsistent in another. The vehicle and app may share a broader ecosystem identity, but the resource decision still belongs to the path that understands the target being requested.
Where the binding must be enforced
The most useful architectural checklist is to follow a request across boundaries and ask what information is available at each step. When a vehicle connects, the backend can identify the device associated with the credential. When an app calls an API, the backend can identify the user or session associated with the token. When the request names a topic, object, or command, the service handling that resource must compare the target with the authenticated principal and the applicable policy.
That comparison cannot be postponed indefinitely. If an upstream gateway strips the information needed to identify the target, a downstream service may be unable to enforce ownership. If a broker receives a topic without a reliable association to the session identity, it may apply a generic ACL instead of a vehicle-specific one. If an API returns a storage reference without carrying authorization context into the storage decision, a private object may become reachable through a valid-looking URL.
The boundary is also operational, not only logical. The backend may run several broker clusters or service instances. The policy must be consistent across them, because a request routed to a different instance should not acquire a different vehicle scope. A valid identity that is safe on one path but broad on another is not a stable security property. It is a property of the route that happened to handle the request.
This system model changes how the central failure should be described. The question is not whether the vehicle, app, broker, API, or storage service is “trusted” in the abstract. The question is which principal is recognized at each boundary, which resource is being addressed, and whether the component that can see both facts performs the authorization check. The next decision model can now be stated precisely: after the backend knows who is communicating, is that identity allowed to use this exact resource?