What breaks when vehicle access relies on short-range wireless trust?

How short-range wireless trust breaks in vehicle access

Vehicle access systems often treat proximity as a shortcut for trust, but that assumption only works when distance is actually being measured and enforced. If the challenge-response exchange can be relayed, the car is no longer authenticating physical presence, it is only authenticating that a valid credential answered in time. That makes “nearby” a weak security claim unless it is independently verified.

Modern keyless entry depends on more than radio signalling. The access decision is really a combination of cryptographic proof, timing, signal characteristics and sometimes device posture or motion signals. When one of those signals is missing or too easy to proxy, the system can mistake an indirect path for a legitimate local interaction.

The important distinction is between convenience and assurance. Short-range wireless is useful for user experience, but it should not be treated as a standalone proof of legitimacy when the attacker can extend the communication path. In practice, the control only remains trustworthy when the system verifies the factors that short-range transport was implicitly standing in for.

Why relay attacks defeat proximity-based assumptions

A relay attack extends the radio conversation between the key and the vehicle without requiring the key to be close to the car. The vehicle sees a valid response and assumes the key is nearby, while the key may be far away and responding to a forwarded request. The authentication technically succeeds, but the trust model fails because the environment was never what the system believed it to be.

NIST SP 800-207 Zero Trust Architecture is useful here because it frames proximity as an unsafe trust proxy: verify the interaction, do not infer legitimacy from network location or convenience. For this kind of access path, the security decision should degrade gracefully when the signal cannot prove locality.

SPIFFE workload identity specification is a good analogue for the same principle in other systems: identity has to be asserted and checked, not assumed from the communication route. The vehicle case is different in implementation, but the security lesson is the same, trust the proof, not the path.

Short-range systems are also vulnerable to timing and replay-style abuse when the design gives too much weight to response speed. If the enforcement logic accepts a response that arrived within an expected window, an attacker only needs to preserve the timing envelope, not the physical distance. That is why delay-tolerant designs need extra controls beyond raw proximity checks.

What the control has to verify instead of assuming

The access decision needs at least one factor that is hard to proxy at range. That may include stronger cryptographic challenge handling, distance-bounding mechanisms, motion or wake-state checks, user presence confirmation, or anomaly detection that flags an impossible access pattern. The goal is not to make every entry slow, but to stop the system from equating “answered correctly” with “physically present.”

RFC 8705: OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens illustrates a broader control pattern that matters here: bind the credential to the intended participant so the assertion is harder to replay or redirect. For vehicle access, the equivalent design principle is to bind legitimacy to the local context, not only to possession of a token.

RFC 6749: The OAuth 2.0 Authorization Framework is also relevant as a reminder that authorization should be scoped tightly to the intended action. If an access proof can be forwarded, the vehicle has effectively granted an action outside the context it meant to authorize.

Good implementations look for divergence between expected and observed behaviour, such as repeated unlock attempts at unusual times, inconsistent signal strength, or a key that is apparently active when the owner is elsewhere. The more the system can correlate multiple signals, the harder it becomes for an attacker to satisfy the control with a simple relay.

Practitioner Guidance

What to prioritise: Treat proximity as a convenience signal, not a trust boundary. If the access decision can be satisfied by a forwarded radio exchange alone, the design is still vulnerable even if the cryptography is sound.

What to verify: Confirm that the vehicle or access platform has some mechanism that makes relay materially harder, and that it produces usable telemetry when the mechanism is bypassed or behaves inconsistently. If it cannot distinguish a local interaction from a relayed one, it is relying on the wrong control.

Common mistake: Teams often focus on whether the credential is strong enough and miss the deeper problem that the environment is weakly asserted. A strong credential inside a weak locality model still grants access to the wrong actor.

Practitioner takeaway: The right design question is not “is the key valid?” but “can the system prove this access is happening where and when it expects?”

Related resources from NHI Mgmt Group

• What breaks when access governance still relies on standing entitlements in a zero trust model?
• Why do ephemeral credentials still leave risk in machine access models?
• What breaks when Oracle SoD reporting relies on assigned roles instead of effective access?
• What breaks when AI agent access relies on long-lived secrets?