A vehicle gateway should let the infotainment network send only the few messages it genuinely needs, at limited rates, and drop everything else. The 2015 Jeep Cherokee demonstration began in an infotainment system and reached steering and braking, which is the path a well designed gateway is meant to close. This post sets out principles, not a product recipe.
Why the gateway matters
In the Jeep case, researchers took control of a vehicle through the Uconnect infotainment system and could affect steering, braking, the engine and the transmission. The vulnerable component was meant for entertainment, yet it could reach safety functions.
The CAN bus that links many control units broadcasts every frame to every node, and in its standard form it has no sender authentication. If an entertainment unit is on the same bus as the brakes, a compromised entertainment unit can say anything the bus accepts. The gateway is where you decide what it may say.
Principles
- Default deny. Start from an empty allow list, and add messages one at a time with a written reason.
- Direction matters. Many messages should flow from driving networks toward the display and not the other way. Make the allowed direction explicit.
- Allow by identifier, then by content. Filter on message identifier first, then check that values are in range and state transitions make sense.
- Rate limit. Even an allowed message can be abused when sent a thousand times per second.
- Separate networks physically or logically. The fewer units that share a bus, the fewer that can speak for each other.
- Treat diagnostic access as a mode. Accept diagnostic or reprogramming messages only when the vehicle is in a state that expects them, and with proper authentication.
- Log drops. A burst of dropped messages from the entertainment network is a symptom of compromise.
What an allow list looks like
A realistic allow list for an infotainment unit might include:
- Reading vehicle speed to adjust volume or map behavior.
- Sending a small set of status messages that the display needs.
- Requesting a few comfort features through a narrow, validated interface.
It would not include writing to powertrain or braking identifiers, and it would not include reprogramming commands. Your list will differ, so build it from your own architecture and review it with the safety team.
Pitfalls
- The gateway is also software. It needs patching, and a flaw in it undoes the separation.
- Bypass paths. A diagnostic port, a second cellular modem or a direct link between units can skip the gateway.
- Safety interactions. A filter that blocks a legitimate safety message is its own hazard, so test with the safety team, not around them.
- Silent exceptions. Temporary rules for debugging often become permanent.
Testing
- Attempt to send each forbidden message from the infotainment side in a bench setup.
- Replay and flood allowed messages and check rate limits.
- Review every exception and record who approved it.
- Retest after every gateway software change.
Supply chain
Gateway firmware includes third-party code. Keep a per-release inventory so you can answer quickly when a component is disclosed. Safeguard can generate SBOMs and scan dependencies for software you build, which covers the inventory part of that question.
Quick check
Is a gateway enough on its own?
No. It limits what a compromised unit can reach. You still need to harden the units that connect to the outside, secure updates and protect diagnostic access.
Sources
- Chrysler recalls 1.4 million vehicles after Jeep Cherokee hack (Security Affairs)
- CAN bus (Wikipedia)
Last reviewed: 19 October 2026.