TL;DR: DEF CON 23 demos showed low-cost keyless entry attacks, Tesla Model S compromise paths, and GPS spoofing techniques that can alter vehicle functions and location data, according to DigiCert. The lesson for identity and access teams is that connected-device trust models fail quickly when authentication, command control, and safety boundaries are too easy to bypass.
At a glance
What this is: This recap covers DEF CON 23 car-hacking demonstrations and shows how cheap tools, remote control paths, and GPS spoofing exposed weaknesses in smart automobile security.
Why it matters: It matters to IAM practitioners because connected devices increasingly depend on identity, trust, and command authorization patterns that fail when access is too easy to counterfeit or abuse.
By the numbers:
- $32.
- DEF CON 23 gathered thousands of hackers and security professionals in Las Vegas.
👉 Read DigiCert's DEF CON 23 recap for the smart car hacking demonstrations
Context
DEF CON 23 highlighted a familiar governance problem in a new domain: connected systems can look sophisticated while still exposing simple control paths that attackers or researchers can manipulate. In smart automobiles, the issue is not only technical weakness but also the absence of resilient trust boundaries around entry, command execution, and location data.
For IAM and security leaders, the relevance is broader than cars. As more operational technology, IoT, and autonomous systems rely on machine identity, remote control channels, and signed commands, the question becomes whether the system can verify who or what is issuing an action before the action reaches the physical world.
Key questions
Q: How should security teams reduce replay risk in keyless access systems?
A: Security teams should assume that proximity alone is not proof of legitimacy. The practical response is to require replay-resistant challenge-response design, test for relay attacks, and separate convenience features from high-impact actions. If a system accepts copied or delayed signals, the access model is already too weak for physical control.
Q: Why do connected devices need stronger authorization than simple network controls?
A: Connected devices fail when network location is mistaken for trust. A device can be reachable from the right network and still expose dangerous actions if the command plane is not separately authorized. Practitioners should evaluate which functions are exposed, who can issue them, and whether each action requires its own trust decision.
Q: What do teams get wrong about GPS and location-based automation?
A: Teams often treat GPS as an objective fact when it is really an input that can be forged. That creates a weak foundation for automation, routing, and safety decisions. The better approach is to validate location against multiple signals and fail safe when the signals do not agree.
Q: What should organisations do first when connected product controls are exposed?
A: Start by ranking the functions that can alter physical state or safety outcomes, then verify whether those functions can be reached through low-assurance signals. The first priority is not more monitoring, but removing implicit trust from the highest-impact control paths and limiting what each credential or signal can do.
Technical breakdown
Keyless entry attacks and replay-resistant authentication
Keyless entry systems are vulnerable when the lock accepts a signal that can be captured, relayed, or replayed without strong freshness checks. Devices like Rolljam exploit weak assumptions about proximity and timing, turning a convenience feature into an access path. The technical problem is not just radio interception, but the absence of cryptographic challenge-response design that proves the signal is current and bound to a specific session. In identity terms, the car is trusting a credential that was never strongly authenticated in the first place.
Practical implication: treat proximity-based unlock mechanisms as high-risk access paths and require replay-resistant authentication for any function that controls physical access.
Remote control of vehicle functions through exposed trust boundaries
The Tesla demonstrations show how a connected vehicle can expose internal functions through a chain of vulnerabilities that starts with initial access and ends with command execution. Once attackers can reach the trusted control plane, they may influence safety-relevant systems such as power, suspension, or lighting. This is a governance problem as much as a software one, because the vehicle effectively grants more authority than the original interaction should allow. In identity terms, privilege is broader than the user intent that initiated the request.
Practical implication: separate convenience functions from safety-critical commands and require stronger authorization boundaries for any action that changes vehicle state.
GPS spoofing and the identity of location data
GPS emulators demonstrate that location is not a trustworthy attribute unless the system can validate signal authenticity and consistency. If navigation or smartphone systems accept false coordinates, downstream automation can act on a fabricated state and make the wrong decision. The security issue is therefore not only data integrity, but identity integrity for environmental context. When location becomes an input to automation, the system needs assurance that the signal really came from the environment it claims to represent.
Practical implication: validate location-sensitive automation with multiple signals and assume GPS alone is an untrusted input.
Threat narrative
Attacker objective: The attacker aims to gain unauthorized control over vehicle functions and distort environmental inputs in ways that affect safety, movement, and trust in the system.
- Entry occurred through low-cost keyless entry abuse, where the attacker could exploit weak signal handling to access the vehicle or nearby control path.
- Escalation followed when the exposed trust boundary allowed movement from passive signal interception to active control over vehicle functions such as power, lights, and suspension.
- Impact was the ability to manipulate physical vehicle behavior and mislead navigation systems through GPS spoofing, creating safety and integrity risk.
Breaches seen in the wild
- IOS app secrets leakage report — iOS apps leaking hardcoded secrets and credentials endangering user privacy.
- DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Connected-device identity fails when convenience is treated as trust. Smart automobile systems often accept signals that are easy to imitate, relay, or spoof because product design optimizes user experience before security assurance. That creates an identity problem, not just a vulnerability problem, because the system cannot reliably distinguish a legitimate control signal from a counterfeit one. Practitioners should treat every convenience-based trust path as a potential authorization gap.
Physical systems need command-level least privilege, not just network segmentation. The Tesla demonstration is a reminder that a network boundary does not protect a function if the trusted control plane still exposes safety-relevant actions. Once an attacker reaches that plane, privilege becomes a property of command authority rather than of network location. Security teams should think in terms of which actions are reachable, not only which subnets are reachable.
Location spoofing shows why environmental inputs need identity assurance. GPS data is often consumed as if it were a reliable fact, but in autonomous or connected systems it should be treated as an asserted identity claim about the environment. When the claim is false, downstream automation can be steered into bad decisions. Practitioners need to design systems that verify context from multiple sources instead of trusting a single sensor identity.
Smart vehicle security is converging with broader identity governance. The same pattern appears across IoT, workload identity, and autonomous systems: a system grants trust to an entity, signal, or credential that was never strongly bound to the action being taken. That makes access review, command authorization, and trust validation part of the same governance problem. Security leaders should govern connected systems as identity systems with physical consequences.
From our research:
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
- That visibility gap is why teams should also review Ultimate Guide to NHIs , The NHI Market when mapping connected-device and machine identity scope.
What this signals
Connected product security is increasingly an identity problem. When a device accepts signals that can be replayed or spoofed, the programme is not just defending software, it is defending the identity of the action source. The same governance pattern appears in machine identity and workload controls, where a trusted signal can still be the wrong signal.
Location-aware systems need multi-signal assurance. A GPS reading is only useful if the platform can validate it against other telemetry and detect inconsistencies before acting. That principle aligns closely with the trust model behind NIST SP 800-63 Digital Identity Guidelines, where assurance depends on evidence, context, and resistance to impersonation.
Replay-resistant access is a boundary, not a feature. As connected devices and smart systems proliferate, the governance question shifts from whether a product can be controlled remotely to whether that control is cryptographically bound, least-privileged, and safely revocable. Teams managing IoT, workload identity, or autonomous controls should treat that as a baseline design requirement.
For practitioners
- Map convenience features to trust boundaries Inventory every remote unlock, remote start, telemetry, and navigation function, then document which signals are trusted for each action and whether replay resistance exists.
- Separate safety actions from convenience paths Require distinct authorization checks for functions that change vehicle state, especially actions affecting motion, power, steering, suspension, or lighting.
- Treat GPS as an untrusted input Correlate location with additional signals such as network context, sensor consistency, and device state before automating decisions that depend on position.
- Test replay and relay resistance directly Validate whether keyless and proximity-based systems reject captured signals, delayed transmission, and relayed authentication attempts under realistic field conditions.
Key takeaways
- DEF CON 23’s car hacks showed that low-cost tooling can undermine keyless access, vehicle command paths, and location trust at the same time.
- The scale of the issue is not theoretical because the demonstrations reached core functions such as power, lighting, suspension, and navigation integrity.
- Practitioners should harden connected systems by separating convenience from control, requiring replay resistance, and validating any location or command signal before acting on it.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST Zero Trust (SP 800-207), NIST CSF 2.0 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST Zero Trust (SP 800-207) | AC-3 | Vehicle control paths need explicit authorization, not implicit network trust. |
| NIST CSF 2.0 | PR.AC-4 | Access to connected-device functions should be limited by least privilege. |
| NIST SP 800-63 | Replay resistance and phishing-resistant assurance are relevant to keyless control analogues. |
Use strong authenticator assurance principles for any command path that controls physical access.
Key terms
- Replay-resistant authentication: An authentication method that prevents an intercepted signal from being reused later to gain access. In connected-device contexts, it must bind the response to a fresh challenge and the current session so copied commands cannot unlock or control a system.
- Trust boundary: The point where a system decides whether to accept a request, signal, or command as legitimate. For smart devices, a weak trust boundary allows convenience signals to become control paths, which is how benign user actions can be turned into unauthorized execution.
- Command plane: The set of functions that can change a device or system state, such as start, stop, unlock, or reconfigure. In connected products, the command plane must be governed separately from general connectivity because reachability does not equal authority.
- Signal spoofing: The act of fabricating or manipulating a sensor or communications signal so a system believes a false state is real. In navigation and automation, spoofing can alter decisions even when the underlying device has not been fully compromised.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
This post draws on content published by DigiCert: DEF CON 23 Recap. Read the original.
Published by the NHIMG editorial team on 2025-09-30.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org