How Does a Car Keep Separate Networks Secure?

Gateway rules

In a segmented architecture, the networks meet at a gateway. This can be a dedicated central gateway module, or a function inside a domain or zone controller in newer designs. The gateway connects buses that may use different technologies, such as CAN, LIN, FlexRay, or automotive Ethernet. It does not pass all traffic from one side to the other. It forwards only the messages a destination domain needs. Wheel speed data, for example, may be useful to the instrument cluster and to infotainment features that adjust volume with speed. The gateway can forward that information outward without letting the infotainment domain send commands back into the chassis or braking domain.

Gateway filtering typically uses a few kinds of rules. Allow-lists define which message identifiers may cross between specific networks and in which direction. Some routes are one-way, so data can leave a sensitive domain but nothing can enter it on that path. Rate limits and plausibility checks can drop traffic that arrives too often or carries values that make no sense for the current vehicle state. Diagnostic requests are often treated separately: the gateway may block requests from the diagnostic connector, or allow them only after authentication. Manufacturers do not usually publish their exact rule sets, and the details vary between vehicle platforms.

The gateway matters because classic CAN, still common in vehicles, has no built-in way to verify the sender. Any node on a CAN bus can broadcast a message with any identifier, and receivers generally trust it. Separating networks and controlling the crossing points keeps a compromised or faulty device in one domain from directly addressing the modules in another.

Critical systems

Braking, steering, airbags, powertrain control, and driver assistance functions are the most safety-relevant parts of a vehicle network. Designers generally place them on segments with the fewest external connections, away from domains that face the outside world, such as infotainment, Bluetooth, Wi-Fi, and cellular telematics. A typical security goal is that an attacker would have to get past several separate barriers to reach a safety-critical controller from an external interface.

Critical modules also have protections of their own, so they do not rely only on the gateway. Many controllers check whether incoming commands are plausible and ignore requests that conflict with the vehicle's state. Some architectures add message authentication. The AUTOSAR Secure Onboard Communication approach, for example, attaches a cryptographic authentication code and a freshness value to selected messages, which lets the receiver reject forged or replayed frames. Adoption of message authentication differs between manufacturers and vehicle generations, so it should not be assumed for any particular car.

Diagnostic access to critical modules is restricted as well. Diagnostic protocols such as UDS include security access or authentication steps before an ECU will allow reprogramming, configuration changes, or actuator tests. Some functions are permitted only under specific conditions, such as when the vehicle is stationary. Functional safety engineering, guided by standards like ISO 26262, is a separate discipline from cybersecurity, but the two support each other. Fail-safe defaults and redundancy limit how much harm a single bad message can do.

Updates

A segmented network is only as trustworthy as the software running on its modules, so update control is the third layer. Many current ECUs use secure boot. Before running its firmware, the controller checks a cryptographic signature against a key it trusts, often stored in a hardware security module or a similar protected area. If someone has altered the code or signed it with the wrong key, the module refuses to run it or falls back to a known good image. This makes it harder to plant malicious software, even for someone who gains access to a network segment.

Over-the-air updates add another path that must be protected. In a typical flow, the telematics unit downloads a package and checks that it came from the manufacturer's backend. An update coordinator then distributes the package to target modules, often through the gateway. Each module can verify integrity and version again before installing, and version checks can block rollback to older, vulnerable software. Installation is commonly limited to safe conditions, such as the vehicle being parked with enough battery charge. Dealer updates through diagnostic tools usually require authenticated access as well.

Updates also allow security to change after production. Gateway filter rules, authentication keys, and module software can be revised when new weaknesses are found. In markets that have adopted UNECE Regulations R155 and R156, manufacturers seeking type approval must show that they have a cybersecurity management system and a software update management system. The ISO/SAE 21434 standard provides an engineering framework for the same goals. How these requirements apply to a given vehicle depends on its market and approval date.

Practical implications and limits

For owners and independent repairers, segmentation has visible effects. A plug-in device on the diagnostic port, such as an insurance tracker, a scan tool, or a performance monitor, may be able to read some data but be blocked from writing to or querying certain modules. Some manufacturers require registered, online-authorized diagnostic tools to unlock deeper functions, which can affect which shops can carry out programming or calibration. ECU tuning and other software modifications can conflict with signed firmware, and a later official update may overwrite or reject modified code. Before buying an aftermarket device or tool, check whether it is intended to support the specific vehicle, and how.

Segmentation reduces risk but does not remove it. Older vehicles may have flatter architectures with little filtering between buses. Someone with physical access to the wiring can sometimes connect beyond the gateway entirely. Protection also depends on factors an owner cannot inspect, including key management, backend security, and how long the manufacturer keeps releasing fixes. Owners can install offered software updates promptly, respond to recall and service campaigns, limit permanently connected third-party devices, and ask the dealer or check the owner's manual about update support for their vehicle.