Penetration Testing
CAN has no built-in authentication, which is well known. The interesting findings are rarely about the bus itself — they are about what sits on it and how it was configured.
· AutoSec Security Research · 2 min read
Every introduction to automotive security notes that the CAN protocol provides no authentication or encryption. That is accurate, and it is also the least useful observation available, because it is true of every vehicle on the road and tells an engineering team nothing actionable.
Findings that change a design usually come from somewhere more specific: the behaviour of individual ECUs, the configuration of gateways and diagnostic services, and the assumptions embedded in how messages are handled.
Diagnostic protocols expose powerful functions by design: reading and writing memory, entering programming sessions, controlling actuators. The security question is not whether these exist but which of them are reachable, from where, and under what authentication.
Recurring issues include security access implementations with weak or shared secrets, services intended for the production line that remain reachable in the field, and gateway routing rules that are more permissive than the architecture documentation suggests.
Domain separation only holds if the gateway enforces it. Testing frequently shows a gap between the intended routing policy and the configuration actually deployed, particularly after feature changes late in development. Verifying the effective policy on real hardware is a different activity from reviewing the intended one on paper.
Receiver implementations are often written against well-formed traffic. Malformed frames, unexpected sequences, values outside the specified range, and unusual timing can produce behaviour the designer did not consider — from silent state corruption to a reset loop that removes a function from service.
Secure Onboard Communication addresses authenticity and freshness for protected messages, and it is the right control for safety-relevant signals. It does not address weak diagnostic access control, over-permissive gateway routing, or fragile receiver logic. Deploying SecOC does not remove the need to test the surrounding implementation.
Written by
Vehicle security testing and research
Practitioners focused on vehicle penetration testing, interface assessment, and applied automotive security research.
More from this authorSecure Updates
Most engineering organisations already update vehicle software safely. Far fewer can reconstruct, months later, exactly what was delivered to which vehicle and why it was considered safe.
· AutoSec Engineering Team · 1 min read
Read articleVSOC
An enterprise SOC watching vehicle telemetry without vehicle context produces alerts nobody can act on. The gap is domain knowledge, not tooling.
· AutoSec Engineering Team · 2 min read
Read articleCybersecurity Engineering
A threat analysis that nobody uses is expensive documentation. The difference between a useful TARA and a compliance artefact is usually method discipline, not effort.
· AutoSec Engineering Team · 2 min read
Read articleIf this applies to a programme you are working on, we are happy to talk it through.
