Automotive & Embedded Penetration Testing
Automotive and embedded penetration testing across Europe: CAN bus, ECUs, firmware and hardware tested to ISO 21434 and WP.29. Fixed quote, free retest.
Automotive and embedded penetration testing is hardware-level offensive work: we attack ECUs, the CAN bus, telematics units, infotainment and the firmware inside them the way a determined adversary with the physical device would. When a vulnerability can affect a moving vehicle or a deployed fleet, testing has to reach the silicon, not stop at the network.
An embedded device is a computer you cannot patch on a whim, often sitting in a hostile physical environment for a decade. In vehicles the stakes are higher still, because a flaw can cross from an entertainment feature to a safety-critical function if the internal separation is weak. We test the whole stack, from the radio interface down to the flash chip, and we do it against the standards regulators now require.
What automotive and embedded penetration testing covers
We treat the device as an attacker with hands on it would: extracting firmware, listening to and injecting on internal buses, abusing debug interfaces, and attacking the wireless surfaces that let an adversary reach the device without touching it. The goal is to find the paths that lead from an accessible interface to control of a function that matters.
How we test an automotive or embedded target
The work is a mix of hardware bench analysis and software reverse engineering, informed by threat modelling to ISO/SAE 21434. We start by understanding the device’s architecture and its trust boundaries, then attack the interfaces in order of how an adversary would actually reach them.
Threat analysis and risk assessment
ISO/SAE 21434 frames automotive security around a TARA, a threat analysis and risk assessment. We build one for the target so the testing effort concentrates on the assets and attack paths that carry real safety and security consequence, not evenly across every pin on the board.
Hardware analysis
On the bench we identify the components, locate debug and test points, and try to gain a foothold: dumping firmware from flash over SPI, opening a UART console, or reaching a live JTAG or SWD interface. A surprising number of production devices ship with debug access still enabled and readout protection never set.
Fault injection and side-channel
Where secure boot or a locked interface stands in the way, we assess resistance to hardware attacks such as voltage glitching and, where relevant, side-channel analysis against cryptographic operations. These are the techniques a serious attacker uses to defeat a lock the software assumes is unbreakable.
Firmware reverse engineering
With firmware in hand we analyse it: unpacking images with binwalk, disassembling with Ghidra, and hunting for hardcoded keys, backdoor accounts, unsafe update logic, and the classic memory-corruption bugs that embedded C is prone to. Firmware is where the device’s real secrets and its real weaknesses live.
In-vehicle and bus testing
For automotive targets we work on the CAN bus and Automotive Ethernet, capturing and replaying traffic, fuzzing UDS diagnostic services under ISO 14229, and testing whether a message from a low-trust domain such as infotainment can influence a higher-trust domain. Domain isolation is the property that keeps an entertainment bug from becoming a braking problem, and we test it directly.
Wireless and backend
We test the remote attack surface too: Bluetooth and BLE pairing and profiles, Wi-Fi, the cellular telematics path, RF key fobs, and the cloud backend and APIs that a connected vehicle or device talks to. A modern car is also a fleet of internet endpoints, and those get tested to web and API standards as well.
Vulnerabilities we commonly find
Embedded and automotive systems share a set of recurring weaknesses, most of them rooted in the assumption that physical access is hard and therefore does not need defending against.
Open debug interfaces and unprotected flash
JTAG, SWD or UART left enabled in production, and flash memory without readout protection, so the entire firmware and its secrets can be extracted on a bench in minutes. This is the most common foothold we find.
Hardcoded secrets and weak keys
Signing keys, API tokens and diagnostic passwords baked into firmware and shared across an entire product line, so extracting one device compromises them all. Embedded crypto also tends to lean on weak or predictable random number sources.
Missing or bypassable secure boot
Devices that will run unsigned firmware, or whose secure boot can be defeated with a glitch, letting an attacker install persistent malicious code that survives updates.
Weak internal isolation
In vehicles, a CAN architecture where a compromised infotainment or telematics unit can inject messages onto buses controlling more sensitive functions. This is the flaw that turns a convenience feature into a safety issue.
Insecure update mechanisms
Over-the-air or diagnostic update paths without proper signature checks or rollback protection, which let an attacker push malicious firmware or downgrade to a known-vulnerable version.
Tools and equipment
The work uses logic analysers and oscilloscopes for signal analysis, hardware tools such as the Bus Pirate and flash programmers for memory access, CAN interfaces and SocketCAN with tooling like can-utils for bus work, software-defined radio for RF, and Ghidra with binwalk for firmware reverse engineering. Fault-injection rigs are used where secure boot needs to be assessed. The equipment gets us onto the device; the findings come from an engineer who understands how these systems fail.
Want this tested on your own systems?
Free 20-minute scoping call, a fixed price with no hourly surprises, and a free retest once you fix what we find.
Standards and compliance
Automotive security is now regulated, not optional. ISO/SAE 21434 defines cybersecurity engineering across the vehicle lifecycle, and UNECE WP.29 regulation R155 requires a certified cybersecurity management system for vehicle type approval, with R156 covering software updates. Our testing and reporting are structured to feed the evidence these require, including the TARA and verification activities. For general embedded and IoT devices we work to the ETSI EN 303 645 baseline and OWASP IoT guidance, and align to ISO 27001 where it applies. We provide the attestation and evidence mapped to your target framework.
What you get
The deliverables are written for both your embedded engineers and the people answering to a regulator or type-approval authority.
- An executive summary framing the safety and security risk in terms leadership and auditors can act on.
- A technical report with each finding scored, the attack described in reproducible detail with the hardware setup used, and a concrete fix.
- The threat analysis and testing evidence structured to support ISO/SAE 21434 and WP.29 activities.
- Prioritised remediation, a call with the reviewing engineer, and a free retest after you fix.
- An attestation letter mapped to your compliance obligation where you need one.
How a remote attack on a vehicle chains together
The attacks that make headlines are not single bugs, they are chains, and understanding the chain is why we test end to end. It often begins at a wireless surface an attacker can reach without touching the car: the cellular telematics link, Bluetooth, or a companion app and its backend. A weakness there gets the attacker onto the telematics or infotainment unit.
Crossing from convenience to control
The dangerous step is the next one: moving from that low-trust unit onto the internal buses carrying messages to systems that affect how the car behaves. If the domains are properly separated, the attacker is stuck with an entertainment bug. If they are not, an infotainment compromise reaches far more than it should. Testing whether that boundary holds is the core safety question, and we probe it directly.
The backend multiplies the risk
Where a flaw sits in the connected-vehicle backend rather than the car, the impact scales, because one server talks to an entire fleet. A backend authorisation flaw that lets one account send commands to another owner’s vehicle is a fleet-wide problem, so we test those APIs with the same rigour as the hardware.
Testing safely, without bricking your hardware
Hardware testing carries real risk to the device, and we manage it deliberately. We work on sample units you provide rather than production stock, keep known-good firmware images so a device can be restored, and agree in advance which destructive techniques, such as fault injection that may damage a chip, are in scope. For in-vehicle work we prefer a bench setup or a dedicated test vehicle over anything a customer will drive. If a sample device is damaged during an authorised hardware attack, that is a result worth having on a test bench rather than a surprise discovered by an attacker in the field.
Pricing
The automotive embedded penetration testing cost depends on the number of components in scope, whether the work is firmware-only or full hardware bench analysis, and how much of the wireless and backend surface is included. Hardware testing takes time, and we scope it honestly.
| Engagement | What’s included | Timeline | Price |
|---|---|---|---|
| Single device / ECU | One embedded device or ECU, firmware extraction and analysis, debug-interface and basic hardware testing, report and free retest | 5–8 working days | from €4,000 |
| Device + wireless | Full hardware bench analysis, firmware reverse engineering, wireless surface (BLE, Wi-Fi, RF), update-mechanism review, exec + technical report | 8–12 working days | €6,000–€15,000 |
| Automotive system | Multiple ECUs, CAN and Automotive Ethernet, UDS diagnostics, domain-isolation testing, telematics backend, TARA aligned to ISO 21434 | 12–20 working days | €15,000–€40,000 |
| Compliance add-on | Evidence pack and attestation for ISO/SAE 21434 or UNECE WP.29 R155/R156 | with any tier | from €1,500 |
| Custom / whole vehicle | Full vehicle or a product platform of many devices, scoped to your needs | on scoping | custom |
Every engagement is fixed-price, quoted after a free 20-minute scoping call — no hourly surprises, and a retest is included. Get a fixed quote
FAQ
How much does automotive and embedded penetration testing cost?
Do you need physical devices to test?
Do you test to ISO 21434 and UNECE WP.29?
Can you extract and reverse engineer firmware?
Do you test keyless entry and relay attacks?
What about the connected-car backend and app?
What will you actually deliver?
Is a retest included after we fix?
Related services
Vehicle manufacturers and tier-one suppliers pursuing UNECE WP.29 type approval, teams building ECUs, telematics units or connected-vehicle platforms, and companies shipping embedded or IoT hardware that must be secure in the field. We are a European offensive-security team working with clients EU-wide and remotely.
Security you can prove
The same standard on every engagement, big or small.
Evidence, not opinions
Every finding ships with a reproduction and proof of concept — no vague "maybe vulnerable".
Humans over scanners
Certified engineers find the logic flaws and chained attacks automated tools walk straight past.
Fixed price, free retest
You know the cost up front, and verifying the fix is part of the deal — not a second invoice.
Ready to lock this down?
Free scoping call, fixed price, free retest. Tell us what you're running and we'll take it from there — usually within one business day.
Tell us what you're running
Scoping is free. We reply within one business day, and under 30 minutes for active incidents.