The Missing Check Between Identity and Permission
The central mechanism in the connected-vehicle authorization problem is a missing comparison. The backend can identify the vehicle associated with a credential, yet fail to compare that identity with the topic, object, or command named in the request. This chapter makes that comparison explicit so readers can inspect any telematics request in two steps: who was authenticated, and what is that identity actually allowed to use?
Every request contains two different questions
The first question is authentication: who is communicating? A backend receives some credential or session material and associates it with a principal, meaning the entity it recognizes as the requester. In a vehicle system, that principal may be a device identity established through mutual TLS, a user identity represented by an app token, or an identity associated with a fallback channel.
The second question is authorization: may this principal access this resource? The resource might be a vehicle-specific MQTT topic, an HTTPS media object, a telemetry record, or a command that can change vehicle state. Authorization is not a description of the requester. It is a decision about the relationship between that requester and that target.
The distinction is easiest to see with two vehicles. Suppose the backend accepts a certificate as belonging to Vehicle A. That result answers the first question. If Vehicle A then requests a command topic or object belonging to Vehicle A, the backend may allow the request. If the same authenticated session names Vehicle B’s topic or object, the correct result is denial unless there is an explicit policy allowing the cross-vehicle access. The certificate has not stopped being valid. The target simply falls outside the identity’s permitted scope.
This is why a secure request cannot be reduced to “the credential checked out.” A credential can identify the principal while saying nothing about the set of resources that principal may use. In a well-designed telematics backend, the identity-to-resource relationship is part of the authorization policy, not an assumption inherited from the transport layer.
The distinction also applies when the requester is a user rather than a vehicle. A mobile account may be associated with a vehicle, but the association still needs an authorization decision. The backend must determine which vehicle resources that account may access and whether a particular action is permitted in the current context. Likewise, a device identity should not be silently treated as a user identity simply because both can reach related APIs. Different principals can have overlapping resources without having identical authority.
The two questions therefore form a sequence, not a choice between two competing security methods. Authentication supplies an identity to the policy decision. Authorization uses that identity, the requested resource, and any relevant conditions to produce an allow or deny result. If the second step is missing, the first step can work perfectly while the system still exposes the wrong resource.
The same-vehicle rule and its failure mode
For the vehicle-to-cloud relationship studied here, the intended rule is straightforward: an authenticated vehicle session should be authorized for resources associated with that same vehicle, unless a separate and explicit policy says otherwise. The rule does not claim that vehicles can never interact with shared services. It says that cross-vehicle access must be a deliberate decision, not an accidental consequence of accepting a valid credential.
The vulnerable behavior described in the study is weaker. It can be understood as checking two conditions: the credential is valid, and the referenced target exists or can be routed. What is omitted is the ownership or authorization check connecting the two. A request may therefore be well formed, addressed to a real resource, and accepted through a genuine session while still violating the intended policy.
That failure explains why transport protection is necessary but insufficient. Mutual TLS can prevent an outsider from establishing a session without the right device credential. Encryption can prevent observers from reading or altering traffic in transit. A token can prove that a request came from a recognized app session. None of those facts, on their own, proves that the authenticated principal is allowed to use every target identifier presented after the channel is established.
The difference is between protecting the path and protecting the resource. Transport authentication protects the establishment of communication. Application authorization protects what that communication is permitted to address. A backend that treats the first protection as a substitute for the second may appear hardened at the network boundary while leaving the object or command boundary open.
The sequence matters. The backend should first determine who is communicating and then decide whether that identity may access the requested resource. The flawed path does not require the backend to mistake Vehicle A for Vehicle B at the transport layer. It only requires the backend to accept Vehicle A’s session and neglect the mismatch when the application request names a resource associated with Vehicle B.
The phrase “the target exists” is especially dangerous because existence and ownership answer different questions. A broker can resolve a topic, an API can find a record, and a storage service can locate an object. Those successful lookups show that the target is real and reachable inside the system. They do not show that the current principal may use it. A resource lookup should therefore be followed by a policy decision, not treated as the decision itself.
The same reasoning applies when identifiers are supplied by a trusted component. On a normal vehicle request, the device software may generate the vehicle identity and the target together, so they appear naturally consistent. A backend can begin to rely on that consistency as an unstated invariant. A controlled client breaks the assumption by keeping the genuine session identity while changing only the application-level target. If the request remains meaningful, the result reveals whether the backend checked the relationship or merely accepted the two fields independently.
This is also why a denial must be interpreted carefully. A failed request can mean that authentication failed, that the target was malformed, that routing broke, or that authorization worked. The useful authorization test keeps the transport and message valid, then observes whether the service rejects a real but out-of-scope target. The security question is not whether the system rejects arbitrary input. It is whether it rejects a properly formed request that the authenticated identity should not be allowed to complete.
Different failures, same missing relationship
Once the identity-to-resource comparison is visible, several vulnerability categories can be separated without losing their common cause.
A control-plane failure occurs when command authority crosses a vehicle boundary. In an MQTT deployment, the session may be able to publish to, subscribe to, or otherwise interact with a topic namespace that should belong only to another vehicle. The missing check is between the authenticated vehicle and the topic or command scope. The impact can include unauthorized command delivery or exposure to message flows outside the intended namespace.
A data-plane failure occurs when a vehicle-authenticated session reaches an object or record outside its scope. An HTTPS request can contain a vehicle identifier, an object reference, or a media path that the server resolves without verifying ownership on that request. The missing check is between the authenticated principal and the referenced object. This is an object-level authorization problem even if the surrounding HTTPS session is encrypted and valid.
A cross-context failure occurs when the backend confuses principal types. A vehicle-authenticated session may be treated as if it belonged to a user or app context, allowing access to resources linked to a different identity relationship. The issue is not only that the wrong vehicle was named. It is that the backend failed to preserve the distinction between a machine identity and a user identity while deciding what the requester could see or do.
A cross-channel failure occurs when a fallback path does not preserve the authorization guarantee of the primary path. An SMS command may arrive through an accepted delivery mechanism and match the expected format, but the receiving side may still fail to authenticate its origin, verify freshness, or bind the command to the intended vehicle. In that case, the message is recognizable without being authorized.
These categories matter because the remedy must reach the point where the relationship is lost. A broker ACL cannot by itself authorize an HTTPS media object. A private storage bucket cannot by itself validate an SMS sender. A stronger certificate in the vehicle cannot by itself correct an API that accepts another vehicle’s object identifier. The common principle does not make the enforcement point interchangeable.
They also differ in what must be observed before calling the result a failure. For a topic boundary, the relevant signal may be a subscription or command operation that reaches a non-seed namespace. For an object boundary, the response must contain a coherent resource belonging to the wrong vehicle, not merely a generic success status. For a fallback command, the strongest evidence is a downstream action or state transition on the target vehicle. The same “allow” label has different meanings in each system, so a careful analysis follows the effect to the resource rather than stopping at a response code.
This distinction protects the diagnosis from two opposite errors. One error is to call every unexpected response an authorization flaw. The other is to treat a valid session as evidence that every later effect was intended. The right question remains relational: did this identity gain a meaningful capability over a resource outside its policy scope, and can the result be separated from transport or parsing behavior?
What Zero Trust adds to the model
Zero Trust is useful here because it rejects an implicit shortcut: trusting a requester because of where it is located, who owns the asset, or which network path it used. NIST’s Zero Trust Architecture guidance treats authentication and authorization as discrete functions and puts the protected resource, rather than the network segment, at the center of the decision.
In the telematics case, that principle becomes concrete. A vehicle certificate does not authorize every topic in a broker. A valid API token does not authorize every media object. A command that reaches a vehicle through an OEM-managed service is not automatically authorized merely because the service is familiar. Each request still needs a decision about the exact resource and the identity permitted to use it.
Zero Trust does not, by itself, specify the topic hierarchy, object model, or fallback message format of a particular vehicle platform. Nor does adopting the label guarantee that broker policies are consistent or that storage URLs enforce ownership. Its value is as a test of assumptions: if the system would allow a request solely because the session or network is recognized, it has introduced implicit trust where a resource-level decision is required.
A useful implementation consequence follows. The authorization decision must be repeatable at the point where the target is known, and its result must remain tied to the identity that was authenticated. A service may delegate the decision, but delegation cannot turn a vehicle identity into a blanket grant. The system should be able to explain why the target belongs within scope and should produce the same answer when the request is handled by another equivalent service instance or by a different protocol path with the same security requirement.
The practical diagnostic is now precise. Preserve the authenticated session, identify the resource named in the request, and ask whether the backend would deny the same request if the target belonged to another vehicle. The next question is how the study obtained a valid seed session and tested that boundary without forging a victim identity or relying on stale traffic.