OEMs should treat keyless entry as a cyber-physical control problem, not just a convenience feature. The strongest baseline is encrypted challenge-response authentication, hardened diagnostic access, and tamper-aware monitoring around reprogramming paths such as OBD-II ports. Security teams also need asset-specific risk assessment, because exposed signal handling and weak authentication can turn a vehicle into an easy target for cloning and takeover.
Why Relay and Replay Risks Matter in Keyless Entry
Relay and replay attacks exploit trust in a short-range access signal, so the failure is not just “someone copied a code.” The attacker either forwards the live exchange through a nearby device or reuses captured authentication material before the system can detect it. That makes distance assumptions, freshness checks, and anti-tamper monitoring central to the control design.
For OEMs, the practical issue is that convenience features can become proximityless access paths when the radio protocol, vehicle software, or reprogramming interface does not enforce enough cryptographic binding to the intended car and session.
Which Controls Actually Reduce Relay and Replay Exposure?
The most effective baseline is a protocol that proves freshness and origin every time, not just at enrollment. Encrypted challenge-response, tightly bounded session lifetime, and anti-replay protections should be designed together so a captured exchange cannot be reused later or from outside the expected range. RFC 9449: OAuth 2.0 Demonstrating Proof of Possession (DPoP) is not an automotive standard, but it illustrates the same sender-constraining principle: stolen proof is not enough if it cannot be replayed by another party.
Physical and diagnostic hardening matters as much as the radio layer. If an attacker can reach a reprogramming path, the keyless system can be bypassed through enrollment abuse, credential replacement, or configuration changes. That is why diagnostic ports, service tools, and firmware update paths need access control, logging, and tamper-aware design rather than being treated as maintenance conveniences. NIST SP 800-53 Rev 5 Security and Privacy Controls provides the control vocabulary for that access and monitoring discipline, and NIST SP 800-207 Zero Trust Architecture reinforces the design pattern of verifying access before granting control over sensitive functions.
Because the risk often emerges at the intersection of vehicle, mobile device, and backend services, OEMs should also treat cryptographic key lifecycle as a first-class dependency. Long-lived shared secrets, weak rotation, and poor separation between models or regions increase the blast radius if one component is exposed. NIST SP 800-57 Key Management is relevant here because key freshness, rotation, and protection directly affect whether a captured value can be turned into a durable bypass.
What OEM Teams Should Verify Before They Trust the Design
Verify that the system rejects delayed, duplicated, or relayed transactions under realistic timing conditions, including low-signal and high-interference environments. Verify that key programming paths require stronger authorization than ordinary door-unlock operations, and that service or diagnostic access cannot silently become an alternate enrollment route. The design is only as strong as the weakest path that can still produce a valid vehicle state change.
It also helps to test the system as an attacker would, not only as a developer would. Capture attempts, relay devices, stolen fobs, and access to maintenance interfaces should all be part of the validation plan. If a control depends on a hidden assumption like “the attacker will not be close enough” or “the service port is rarely used,” it is not a control, it is a hope.
Risk and Threat Considerations
Relay and replay attacks create a direct loss of access integrity, and in automotive environments that can become theft, unauthorized entry, or unauthorized start. The threat is attractive because it can preserve the appearance of legitimate use while bypassing the owner’s physical proximity.
Failure mechanism: An attacker relays live keyless authentication traffic or reuses captured material before freshness or origin checks invalidate it, then pivots through enrollment or diagnostic weaknesses if the radio layer alone is not sufficient.
Impact: The vehicle may unlock, start, or accept new credentials without the owner present, expanding the attack from opportunistic theft to persistent takeover of the access path.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | Controls access to diagnostic and reprogramming paths used in keyless-entry abuse. |
| IA-2 — Identification and Authentication (Organizational Users) | Keyless systems and service tools need strong authentication at access points. | |
| IA-5 — Authenticator Management | Keyless entry depends on protecting, rotating, and invalidating authenticators and secrets. | |
| Recommendation — Enforce access checks on programming and service interfaces before any trust-changing action. Require strong authentication before granting administrative or maintenance access. Manage authenticator lifecycle so captured or stale credentials cannot be reused. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | The subject depends on verifying every sensitive access path before trust is granted. |
| Recommendation — Apply continuous verification to access paths that can change vehicle trust state. | ||
Practitioner Guidance
What to prioritize: Start with the control path that grants the attacker the most leverage, usually the combination of radio authentication, key enrollment, and diagnostic access. If one of those can be abused to create a new trusted state, hardening the radio protocol alone will not solve the problem.
What to verify: Confirm that the anti-replay design is session-bound, time-bound, and resistant to relay at practical distances, and that firmware, service tools, and OBD-II or equivalent interfaces cannot be used to silently reset trust. The most useful test is whether a captured exchange still fails after delays, retransmission, or proxying through another device.
Practitioner takeaway: OEMs should treat keyless entry as a trust-boundary problem across radio, diagnostics, and lifecycle management, because the safest cryptography still fails if another path can re-establish trust more easily.
Related resources from NHI Mgmt Group
- How should security teams reduce replay risk in keyless access systems?
- How should travel companies reduce the risk of AI-powered bot attacks against booking and loyalty systems?
- Why does two-factor authentication reduce the risk of brute force attacks against identity systems?
- How should automotive security teams reduce the risk from remote keyless entry attacks in connected vehicles?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
