Regulation: The new gatekeeper

The most immediate pressure on automakers to take cybersecurity seriously comes not from consumer demand, but from regulation. Over the past five years, a global patchwork of mandates has emerged, forcing OEMs to treat cybersecurity not as a feature, but as a prerequisite for legal compliance and vehicle certification.

At the centre of this shift is the UNECE WP.29 framework, which introduced two pivotal regulations now adopted by over 60 countries:

• UN Regulation No. 155 requires manufacturers to implement a Cybersecurity Management System (CSMS). This is not embedded software — it’s an organizational framework that governs how threats are identified, mitigated, and monitored across the entire vehicle lifecycle. It covers design, production, post-sale updates, and decommissioning. To sell vehicles in regulated markets, OEMs must undergo a formal audit and renew their CSMS certification every three years.
• UN Regulation No. 156 complements this by mandating a Software Update Management System (SUMS). It ensures that over-the-air (OTA) updates are secure, traceable, and compliant with type approval. A key component is the RXSWIN (Regulation X Software Identification Number), which links each critical software version to its regulatory status. While immobilization of vehicles running unauthorized software is technically feasible, it is not explicitly required by regulation.

These frameworks are reinforced by ISO/SAE 21434, the global standard for cybersecurity engineering in road vehicles. It provides a technical blueprint for embedding security into the development process, introducing:

• Threat Analysis and Risk Assessment (TARA)
• Secure-by-design principles
• Verification and validation protocols
• Supplier coordination and documentation standards

Together, these standards form the regulatory backbone of automotive cybersecurity. But they are only as effective as the architectures and technologies that implement them — and that’s where AUTOSAR, NHTSA, and global consortiums come into play.

Architecture improvements: From domains to zones

Let’s step beyond the headlines and explore what could happen if attackers weaponise the whole stack of vehicle connectivity. These aren’t science fiction—they’re extrapolations based oLegacy vehicles were built around domain-based architecture, where ECUs were grouped by function — powertrain, infotainment, body control — and connected via long, complex wiring harnesses. This model led to:

• 100+ ECUs per vehicle
• Fragmented software stacks
• Difficult update and validation cycles

To support software-defined functionality and embedded security, OEMs are transitioning to zonal architecture, where ECUs are grouped by physical location and connected to centralised compute nodes.

Benefits of zonal architecture include:

• Reduced wiring complexity and vehicle weight
• Easier software deployment and OTA validation
• Improved segmentation and isolation for security
• Support for containerized services and real-time monitoring

Tesla, Rivian, and other EV-native platforms have adopted zonal models from the ground up. Legacy OEMs are layering zonal logic on top of domain structures as part of mid-cycle refreshes.

Embedded defence: Real products, real impact

The most meaningful progress is happening inside the vehicle — at the level of embedded software and hardware. Let’s discuss some real-world examples of modern Automotive security. Inside a modern connected vehicle, you will find a somewhat familiar, but heavily reworked network and security equipment – switches, firewalls, intrusion detection sensors and endpoint hardening software.

Automotive switches and firewalls:

Modern vehicles rely on high-speed Ethernet switches to route data between zonal gateways, central compute units, and external interfaces. But these switches are no longer passive -they’re becoming active security nodes.

A prime example is the collaboration between Marvell and Vector Informatik. Marvell supplies the Brightlane™ multi-gig Ethernet switch hardware, which supports MACsec encryption, low-latency switching, and hardware-level packet filtering. Vector complements this with its MICROSAR Classic veSwitch software stack, built on AUTOSAR standards.

Together, they enable:

• Layer 2–7 firewalling directly on the switch to secure Ethernet communication across zonal domains
• MACsec encryption for encrypting Ethernet communication
• Deep Packet Inspection (DPI) for SOME/IP and other automotive protocols
• Intrusion Detection System (IDS) integration, reporting suspicious traffic to the vehicle’s IdsM (Intrusion Detection System Manager)

This hardware-software pairing transforms the switch from a simple router into a security-aware gateway, capable of enforcing policy, detecting anomalies, and isolating compromised segments in real time.

In short, Marvell builds the silicon, Vector builds the intelligence. Note: Marvell, sold its entire automotive networking business to Infineon Technologies in Augusts 2025

Automotive IDS

Another significant initiative is the development of a standard for onboard Intrusion Detection System (IDS) comprising Security Event Sensors and IDS M (Intrusion Detection System Manager), which gathers, analyses, and forwards events to the remote centralised backend or vSOC (Vehicle Security Operations Centre). The concepts and elements of vehicle IDS are illustrated below:

Although the standard for IDS was ratified at the end of 2020 (AUTOSAR Classic Platform release R20-11), there are only a few market options. You will not find well-known IT cybersecurity vendors in this space. It is instead existing automotive hardware specialists pivoting into the security space. Unfortunately, the information about IDS implementations is not always publicly announced, but there is evidence that some from 2023, using Vector’s MICROSAR suite (e.g. BMW, VW Group, Daimler) are likely implementing IDSM-compatible IDS and vSOC.

Endpoint security

Another security measure, Control Flow Integrity (CFI) is quietly becoming one of the most essential embedded security techniques in automotive systems. CFI is officially recognised in the AUTOSAR Foundation release R22-11, under the section on Protected Runtime Environments. CFI is especially valuable in ECUs that cannot rely on frequent updates or cloud-based anomaly detection. It offers deterministic protection with minimal runtime overhead, making it ideal for embedded environments with strict performance and safety constraints.

CFI is moving from research to production. Here are a few examples based on indirect evidence:

• Europe: BMW responded to high-profile infotainment vulnerabilities by integrating runtime protections. Tier-1 suppliers like Bosch and Continental now deploy CFI via Karamba’s Carwall® in MICROSAR-based ECUs, especially in ADAS and telematics domains.
• United States: While not publicly confirmed by OEMs, Karamba Security has stated its CFI technology is used by North American automakers and Tier-1s, particularly in ECUs for Ford, GM, and Stellantis platforms aligned with ISO/SAE 21434 and NHTSA guidance.
• China: Domestic OEMs and suppliers are adopting CFI as part of broader AUTOSAR integration, driven by initiatives like AUTOSEMO and CACIISA. Runtime integrity is increasingly embedded in ECUs to meet UN R155 compliance and reduce reliance on foreign IP.

CFI as the kernel-level equivalent of Zero Trust. It doesn’t just monitor – it enforces. It doesn’t guess – it validates. And in embedded environments like automotive ECUs, it’s one of the few defences that can operate without cloud connectivity or signature updates.

---