AutoGuardX: Cybersecurity for Connected Vehicles

• AutoGuardX is a comprehensive cybersecurity framework for connected vehicles that integrates ISO/SAE 21434, ISO 26262, and machine learning-based anomaly detection.
• It employs a layered and modular architecture combining runtime security functions, IoT protocols, encrypted communications, and incident logging for adaptive defense.
• Performance evaluations show that AutoGuardX achieves high detection accuracy and complete blocking of multiple cyber attack vectors in simulated environments.

AutoGuardX is a proposed comprehensive cybersecurity framework for connected vehicles that combines ISO/SAE 21434 and ISO 26262 with machine learning-based anomaly detection, IoT security protocols, encrypted communication channels, and incident logging and forensic tooling. It is presented as a layered, runtime-focused defense system intended to complement standards-based engineering with continuous, adaptive, and operational protection against cyber-enabled theft and intrusion, including relay attacks, controller area network (CAN) bus intrusions, OBD port exploitation, RF signal replay, IoT compromise, and future-facing concerns associated with 5G and quantum computing (Nadeem et al., 25 Aug 2025).

1. Definition, scope, and design philosophy

AutoGuardX is described as a modular and platform-agnostic framework for vehicle cybersecurity rather than a single detector or a single cryptographic mechanism. Its architecture combines normative standards, runtime security functions, IoT protections, communication security, incident response, and user-facing controls. The paper explicitly positions the framework as a complement to existing automotive standards rather than a replacement for them (Nadeem et al., 25 Aug 2025).

The standards layer consists of ISO/SAE 21434 and ISO 26262. In the paper’s description, ISO/SAE 21434 provides a lifecycle cybersecurity process covering risk assessment, concept, design, implementation, validation, production, operation, maintenance, and decommissioning, while ISO 26262 governs functional safety in case of electrical and electronic failures. AutoGuardX is intended to fill the gap those standards leave by adding runtime defense against malicious attacks (Nadeem et al., 25 Aug 2025).

At the architectural level, the framework combines runtime security functions such as ML-based anomaly detection, threat prediction, and behavioral monitoring with IoT protections including device authentication, secure OTA updates, and network isolation. It also incorporates encrypted RF, encrypted CAN, rolling codes, secure Bluetooth and telematics pathways, logging, forensic analysis, law-enforcement integration, a mobile app, geofencing alerts, and educational tools. This organization gives AutoGuardX the character of a layered operational security stack for vehicles rather than a purely compliance-oriented process framework (Nadeem et al., 25 Aug 2025).

2. Motivation and threat model

The paper motivates AutoGuardX by arguing that modern vehicles now depend on remote keyless entry, in-vehicle networking, infotainment and telematics systems, V2V and V2I connectivity, IoT sensors, and cloud-linked services, and that this connectivity has expanded the attack surface dramatically. The framework is therefore directed at connected vehicles rather than isolated embedded control systems (Nadeem et al., 25 Aug 2025).

The threat model is anchored in the paper’s account of rising cyber-enabled theft. It reports that in Ontario, Canada, auto theft increased by 48.2% between 2021 and 2023; in the United States, auto theft increased by 105% in 34 major cities between 2019 and 2023; and ENISA reported that cyberattacks on IoT-equipped vehicles increased by 62% between 2019 and 2024. The paper further characterizes auto theft as a low-risk, high-reward crime, often tied to organized criminal networks, with stolen vehicles frequently exported abroad or resold after VIN forgery (Nadeem et al., 25 Aug 2025).

Traditional protections are described as largely static. The paper lists mechanical locks, alarms, steering wheel locks, immobilizers, and VIN etching, and argues that such defenses can be bypassed by key cloning, relay attacks, OBD exploitation, and CAN bus injection. Even immobilizers, although mandated in Canada since 2007, are not treated as sufficient against contemporary multi-layer attacks (Nadeem et al., 25 Aug 2025).

The explicit attack vectors discussed in the paper include relay attacks, OBD reprogramming or OBD port exploitation, CAN bus injection, RF signal replay or key fob spoofing, wireless hacking tools such as Flipper Zero and HackRF, multi-vector coordinated attacks combining RF, CAN, and OBD compromise, 5G-based threats such as DDoS against vehicular communications, quantum-computing threats to current cryptography, and IoT device compromise in infotainment, telematics, sensors, and connected subsystems. A central claim of the framework is that attackers increasingly combine physical access, RF attacks, and in-vehicle network attacks to bypass immobilizers and alarms (Nadeem et al., 25 Aug 2025).

3. Architecture and operational workflow

The operational logic described for AutoGuardX is a staged runtime workflow. The framework collects vehicle telemetry and traffic, including CAN messages, RF signals, Bluetooth and telematics traffic, and sensor and ECU data. It then compares these inputs against normal behavior through ML anomaly detection and behavioral analysis. If an anomaly is detected, the system generates instant alerts, logs the event, isolates suspicious components or traffic, and blocks unauthorized communication where possible. The workflow then proceeds to forensic processing, with event data stored for post-incident analysis and relevant data shared with law enforcement (Nadeem et al., 25 Aug 2025).

The ML integration layer is divided into three categories: anomaly detection models that monitor in-vehicle and network behavior and flag deviations from baseline behavior, threat prediction algorithms that use historical patterns to predict attacks before they occur, and adaptive learning models that update over time using prior incidents and user behavior. The paper does not specify a particular model class or formula for these models, but it does state that the system integrates with TensorFlow and Scikit-learn and was retrained after simulations (Nadeem et al., 25 Aug 2025).

The security mechanisms named in the framework are concrete and heterogeneous. For communications, the paper specifies encrypted RF signals, rolling code protocols, secure CAN with message authentication and encryption, secure Bluetooth and telematics pathways, and device authentication for IoT and OBD-connected devices. For maintenance and recovery, it includes secure OTA updates, encrypted HTTPS, and code signing. For containment, it includes network isolation to contain compromise. For user notification and response, it includes geofencing alerts and real-time alerts via a mobile app. For evidence retention, it includes incident logging and forensics (Nadeem et al., 25 Aug 2025).

The implementation stack listed in the paper spans hardware, software, and middleware. It names onboard processor units such as ARM Cortex and Intel Atom; secure communications technologies including AES-CTR, TLS 1.3, and ChaCha20; IoT gateway mechanisms such as MQTT, HTTPS, and ZeroMQ; ML frameworks including TensorFlow, PyTorch, and Scikit-learn; and logging and forensics platforms including ELK Stack, Graylog, and custom JSON logs. This stack description indicates that AutoGuardX is conceived as a systems framework with multiple deployable subsystems rather than a narrow algorithmic contribution (Nadeem et al., 25 Aug 2025).

4. Attack classes and mitigation logic

Relay attacks occupy a central place in the framework’s threat model. The paper describes these as attacks in which RF relay tools intercept and forward a key fob’s signal so that the car believes the key is nearby. AutoGuardX addresses this with encrypted RF, rolling codes, geofencing alerts, and anomaly detection. The intended effect is that captured signals cannot be reused and suspicious access patterns are detected early (Nadeem et al., 25 Aug 2025).

CAN bus intrusions are treated as attacks in which adversaries access the CAN network by damaging the headlight assembly or tapping wiring and then inject fake CAN messages such as “unlock doors” or “disable immobilizer.” The framework responds with CAN message authentication, CAN encryption, anomaly isolation, and logging and forensic tracing. The paper states that unauthorized CAN frames are blocked or isolated before they can command vehicle functions (Nadeem et al., 25 Aug 2025).

OBD reprogramming attacks are described as cases in which an attacker plugs a device into the OBD port and programs a blank key fob or extracts sensitive data. AutoGuardX mitigates these threats with device authentication, secure OBD access, HMAC-SHA256 authentication in the evaluation, and encrypted storage and transmission of data. RF signal replay attacks are separately addressed through rolling codes, signal variance, encrypted RF channels, and anomaly detection, with the stated objective that static replay attempts fail because each authentication code changes (Nadeem et al., 25 Aug 2025).

The paper also treats low-cost wireless hacking tools such as Flipper Zero, HackRF One, and similar SDR-based tools as explicit adversarial instruments. For these, the framework uses RF signature anomaly detection, secure communications, and lockout or blocking after suspicious patterns. The expected effect is earlier detection and reduced effectiveness of commodity attack tools (Nadeem et al., 25 Aug 2025).

The treatment of 5G and quantum computing is more forward-looking. For 5G-based threats, especially DDoS against vehicular communications, the paper states that AutoGuardX must incorporate advanced encryption, traffic filtering, and secure network controls. For quantum-computing threats, it states that the framework will need quantum-resistant cryptographic algorithms, but also notes that specific post-quantum algorithms are not implemented in the paper. This suggests that the 5G and quantum components function as architectural hardening requirements and future extensions rather than as fully instantiated modules in the present evaluation (Nadeem et al., 25 Aug 2025).

5. Evaluation protocol and reported results

The evaluation is described as a simulation and testbed study across 12 vehicles total, spanning 4 OEM brands anonymized as Brand A, B, C, and D, with 3 vehicles per brand. The detailed section states that the sample included compact sedans, SUVs, and pickup trucks manufactured between 2018 and 2023, while the abstract states that the evaluation covered a mix of Sedans and SUVs from four major vehicle brands manufactured between 2019 and 2023. The paper says the vehicles were chosen based on availability, prevalence in Canadian and U.S. markets, and known theft-related vulnerabilities (Nadeem et al., 25 Aug 2025).

The testbed includes ECUs from four OEMs, RF transceivers at 315/433 MHz, Bluetooth LE 5.0 modules, a Keysight E7515B UXM Wireless Test Platform for 5G emulation, Velodyne Puck LiDAR, radar, cameras, Android Automotive OS infotainment, NXP S32K microcontrollers, and NVIDIA Jetson Nano processors. The software environment includes QNX 7.1 RTOS, TensorFlow 2.15, Scikit-learn 1.4, AES-256, RSA-2048, Vector CANoe v17.0, CANalyzer SP3, Wireshark v4.2, Kali Linux 2024.3, HackRF One, Burp Suite 2024.8, Python 3.11, and stress-ng. The network design uses segmented VLAN architecture, critical versus non-critical separation between subsystems such as powertrain and braking versus infotainment, V2V and V2I simulation over Wi-Fi 802.11ax and 5G with low-latency emulation, and a separate attack subnet (Nadeem et al., 25 Aug 2025).

Experimental design is organized into four test categories: penetration testing, security simulations, stress testing, and compatibility testing. The paper reports 12 vehicles multiplied by 12 scenarios for 144 total test iterations, with each scenario run on all 12 vehicles for reproducibility and vehicles reset to factory settings before each test. The explicitly listed metrics are reaction time to threat events, alarm activation consistency, secure code extraction or rewrite success, and event detection and logging accuracy; it also reports detection latency, false positive rate, packet inspection rate, and compatibility or interference with OEM functions (Nadeem et al., 25 Aug 2025).

The quantitative results are reported as comparisons between factory-installed systems and factory plus AutoGuardX. In penetration testing, OBD port exploit attacks succeeded in 11 of 12 factory systems, whereas AutoGuardX blocked 100% of them; fob code injection or relay attack achieved 100% success for the attacker against factory systems, whereas AutoGuardX blocked 100%; and USB data logging achieved 100% data extraction in factory systems, whereas AutoGuardX prevented all unauthorized access. In security simulations, window glass break caused factory alarms to trigger in only 2 of 12 vehicles, while AutoGuardX detected 11 of 12 cases within 1 second and sent real-time alerts to users; headlight lens damage plus CAN access produced inconsistent factory alarms, with only Brand C reacting, while AutoGuardX achieved 100% detection of intrusion attempts and isolated and logged malicious signals; and remote key fob spoofing bypassed factory alarms in all cases, whereas AutoGuardX achieved 100% blocking and sent mobile app alerts to owners (Nadeem et al., 25 Aug 2025).

Stress testing reports that during a concurrent multi-vector attack consisting of simultaneous CAN injection, RF spoofing, and OBD exploit, AutoGuardX experienced no crashes, achieved detection latency of at most 1.2 s, and reached 94% overall detection accuracy. Under CAN flooding above 10,000 CAN messages per second, the framework sustained more than 95% packet inspection rate with no performance degradation. Under CPU and memory load above 90%, it maintained stable analytics, more than 94% detection accuracy, and no crashes. Compatibility testing reports 100% compatibility across all ECUs with no lag or interference with factory functions, less than 0.3% false positives over more than 1,000 hours of driving simulation, and 100% activation consistency under verified threat triggers (Nadeem et al., 25 Aug 2025).

6. Limitations, governance, and position in adjacent literature

The paper identifies several deployment barriers. Older vehicles may not support encrypted CAN or modern security hardware, making retrofitting costly and complex. ECUs have limited CPU and memory, which makes real-time ML difficult on legacy platforms. Attackers adapt quickly, so ML models and defenses need constant updating. The paper also notes regulatory fragmentation, pointing to the fact that in Canada the MVSA and ULC 338 are only partially prescriptive, while in the United States NHTSA guidance is voluntary. It further highlights fragmented OEM ecosystems, high implementation cost, and a shortage of professionals skilled in both automotive engineering and cybersecurity (Nadeem et al., 25 Aug 2025).

Privacy and data governance appear as explicit concerns. The paper states that AutoGuardX may process sensitive data such as location, driving behavior, and biometric identifiers, and therefore raises issues of informed consent, data minimization, privacy, data breach risk, and public trust. Its recommended response is privacy-by-design, impact assessments, and compliance with GDPR- and CCPA-style principles (Nadeem et al., 25 Aug 2025).

Future work identified in the paper includes 5G security hardening, quantum-resistant cryptography, better protection for growing IoT ecosystems, improved security for autonomous vehicles, continued adaptation of ML detection models, and broader deployment across legacy fleets and different OEM platforms. This suggests that the current framework is presented as a broad architectural synthesis with a substantial simulated evaluation, while several cryptographic and deployment aspects remain open engineering directions (Nadeem et al., 25 Aug 2025).

Within adjacent literature, AutoGuardX is distinct from other guard systems that target different layers of the automotive stack. Guardauto, for example, is a decentralized runtime protection framework for autonomous driving systems implemented on Autoware, emphasizing component isolation, local self-protection loops, and cooperative root-cause identification under cascading failures (Cheng et al., 2020). DriveGuard, by contrast, is a front-end robustification framework for automated driving perception that cleans corrupted camera inputs using a lightweight deep spatio-temporal convolutional autoencoder before segmentation (Papachristodoulou et al., 2021). AutoGuardX addresses a different problem boundary: RF, CAN, OBD, IoT, OTA, and forensic security for connected vehicles as operational cyber-physical systems, rather than runtime protection of an ADS software stack or robustification of a perception model (Nadeem et al., 25 Aug 2025).